I asked my friend in UK who has very high speed broadband, to check the page load time
This is not the right way to measure performance. It cannot be automated, it's not a precise metric, it cannot be reliably reproduced and is inherently subjective. The right way is to:
Determine non-functional requirements specifying the expected performance for page rendering under strict conditions.
Ask yourself if you have performance concerns, i.e. whether those non-functional requirements are not matched by the actual code.
If there is actually a problem with performance, run a profiler to determine the bottleneck. Most browsers have one, showing the details about what is really happening. If JavaScript processing takes 1 300 ms. and CSS processing - 25 ms., don't care about CSS right now.
If you've found, according to the benchmarks and the profiler, that the difference between the expected rendering time (specified in the requirements) and the actual tested time is due to CSS, then use several techniques to optimize your CSS. Google documentation is a good start.
Here's a test done on the home page of Programmers.SE. CSS selector profile took 59 ms. with following details:
Selector Total Matches Source
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
.widget_ad_rotator, .widget_adrotate_widgets, .widget_ads [...] 57.6% 0
html, body, div, span, applet, object, iframe, h1, h2, h3 [...] 11.9% 3862 all.css
a:-webkit-any-link 5.1% 913
:focus 3.4% 0
input[type=button], input[type=submit], input[type=reset] [...] 3.4% 4
div 3.4% 2101
.badge:hover 1.7% 0 all.css
a:visited 1.7% 913 all.css
As you can see, most performance loss comes from the fact that I'm using an add blocker in my browser. That sucks, since I don't want to block ads on Stack Exchange. Now that I whitelisted Stack Exchange, the CSS selector time went from 59 ms. down to 23 ms.
The second most expensive selector is a global one which takes on elements identified by their tag names. This is expensive given the number of matches, and there is probably nothing one can do to optimize that, without getting being too much hurt from browser inconsistencies.
The next four are related to Webkit, not the CSS written for the web page.
Starting from the seventh selector, the percentage is too low to care. The actual one, .badget:hover, is not used, but removing it on this page while it's used on other ones would create code difficult to maintain, and especially would represent a gain inferior to 100 microseconds.
From my experience (of a developer who works only on small to medium scale web apps, and not the apps which are accessed thousands of times per second), what you should take care of is the complexity of CSS. Selectors like:
body.en-us div#sidePanel.moveable div:first-child input[type=submit]:hover,
*.lang.en-us div#sidePanel.moveable div:first-child input[type=submit]:hover {
color:#59a;
}
are both unreadable for developers and slow for browsers. Avoiding feature creep in the website and simplifying the styles to:
#sidePanel .top-submit:hover {
color:#59a;
}
worth the effort. In the same way:
.style {
background-color: #000000;
background-image: url('im/fade.jpg');
background-repeat: repeat-x;
background-position: top left;
}
by:
.style {
background: #000 url(im/fade.jpg) repeat-x top;
}
is not too difficult, and largely simplifies the maintenance (see also Google CSS Style Guide).
But I wouldn't spend hours removing 20% of styles just because they are not used, in order to gain a few milliseconds. Especially when using LESS/Sass.
