I have been reading various Web application optimizing articles and many of them suggest to remove unused CSS rules. Currently, I have a page which has jQueryUI css, Bootstrap CSS, Datatables CSS and couple of more. All together they translate to about couple of thousands of rules ( my estimate ) and am quite sure I am using only 20-30%

I asked my friend in UK who has very high speed broadband, to check the page load time and he says, like for every other page on his connection this one too loaded in a second which is quite suggestive that rendering time seems insignificant to the page load time. How much improvement is expected in removing unused CSS rules? Is it really worth it?


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:

  1. Determine non-functional requirements specifying the expected performance for page rendering under strict conditions.

  2. Ask yourself if you have performance concerns, i.e. whether those non-functional requirements are not matched by the actual code.

  3. 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.

  4. 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 {

are both unreadable for developers and slow for browsers. Avoiding feature creep in the website and simplifying the styles to:

#sidePanel .top-submit:hover {

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;


.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.


I think there is an impact although fairly small in terms of page loading times. If for example you had developers who never follow best practices and don't try and keep CSS clean etc then the impact can start building up. Ultimately, if you have well structured, organised and clean CSS, the users experience is generally improved and they can navigate the site quicker.

In addition to removing unused CSS, another way to improve page loading times is to use minification of your CSS (and javascript): http://www.minifycss.com/, http://cssminifier.com/

Similar question: https://stackoverflow.com/questions/6669672/what-is-the-performance-impact-of-having-many-unused-css-selectors-rules

  • 1
    Would you consider optimizing CSS written by experienced developers like Bootstrap? – Shubham Jun 9 '13 at 11:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.