Don't bother using CSS optimization to speed up a web site

Technologies: CSS 2+, CSS optimizer, Drupal 5+ (optional)

CSS optimization (a.k.a. minimization, cleaning, or tidying) removes white-space and comments, merges similar selectors, removes redundant properties, and cleans up a CSS file to make it more compact. The optimized file is smaller and faster to send to a site visitor. This article uses the CSS Tidy optimizer and measures the improvement first for CSS from 30 popular web sites, and second for CSS from 30 site themes for the Drupal content management system. Unfortunately, in all cases the improvement is small and will not have a noticeable impact on page load times.

This article is part of a series on Essential steps to speed up a Drupal web site. The discussion here, however, applies equally well to any type of web site, not just one that uses Drupal.

How to optimize CSS

The larger the CSS file, the longer it takes to send to your site's visitors when they first arrive. In principal, you can speed up page load times by reducing the size of your CSS file. There are several things that you can do:

  • Remove bytes that don't need to be there:
    • Remove indentation, blank lines, comments, and spaces.
    • Remove the semi-colon on the last property in a selector.
    • Concatenate short lines to remove unnecessary line breaks.

  • Use shorter forms of CSS syntax:
    • Reduce colors to shorter values (e.g. replace "#FF0000" with "#F00" or "red").
    • Reduce font sizes to shorter values (e.g. replace "0.50em" with ".5em").
    • Use CSS shorthands (e.g. replace "border-left", "border-right", etc. with "border").

  • Merge similar or redundant selectors and properties:
    • Combine selectors that share the same properties.
    • Drop properties that have been overridden.

Indentation, comments, blank lines, and long-form colors, fonts, and properties, are usually in the CSS to make the file easier to read by the site's designers. Since these make no difference to a site visitor or their web browser, removing them will make the file smaller and faster to send.

Redundant CSS selectors and properties are the natural result of two common design practices:

  • Define a CSS class for each page element and set their properties independently.

    This practice makes it easy to change one page element's properties without affecting the others. But when multiple page elements share the same fonts, colors, borders, etc., this adds redundant property settings to the CSS.

    For instance, say there are two types of teaser <div>. Both have the same font size and padding, but different font colors:

    div.teaser1 { font-size: 110%; padding: 10 15; color: #005; }
    div.teaser2 { font-size: 110%; padding: 10 15; color: #050; }
    

    CSS optimization can recognize that two selectors share several properties and change the CSS to set those properties just once:

    div.teaser1, div.teaser2 { font-size: 110%; padding: 10 15; }
    div.teaser1 { color: #005; }
    div.teaser2 { color: #050; }
    
  • Define default properties for many CSS classes up front, then override them later.

    This practice often uses a master CSS file that sets safe defaults, then adds another CSS file to override those defaults for a site theme, or for a portion of a site. The overridden default property values are redundant.

    For instance, say a CSS file sets a few defaults up front, then later overrides them like this:

    h1 { font-size: 150%; color: black; margin-bottom: 1em; }
    ...later...
    h1 { font-size: 120%; color: #005; border: 1px solid #CCC; }
    

    CSS optimization can recognize that properties have been overridden and set them just once to the final values:

    h1 { font-size: 120% color: #005; border: 1px solid #CCC; margin-bottom: 1em; }
    

CSS optimizers

Hand-editing CSS to make it more optimal is tedious. Instead, use a CSS optimizer application. Here's a few of the many available:

All of these tools will do about the same thing. Most of them are available as web forms into which you paste your CSS and click "Submit" to get the optimized version. Blumentals' CSS Toolbox is a Windows application. Michael Bianco's CSS Optimizer is a Mac or Linux application. And Robson's CSS Compressor and CSS Tidy are downloadable PHP code that you can use offline or embed in your own web form.

CSS Tidy is one of the most widely used CSS optimizers, its free, it works on Windows, Mac OS X, and Linux, and it is under constant development by the Open Source community. So, CSS Tidy is what I'll use for the tests below.

Using CSS optimizers

Whichever optimizer you use, save your original CSS files first. Optimized files are much harder to read and edit. Each time you need to update your site's design, edit the originals and re-optimize.

Many CSS optimizers have a lot of options you can set. The most effective optimization is always white-space removal. Merging selectors and removing redundant properties helps some, and using shorthand CSS syntax does a tiny bit more.

Always test your site with the new CSS files before going live. This is particularly necessary if your CSS uses browser-specific hacks with special comments and odd syntax (see CSS Hacks and IE7). CSS optimizers may remove your hacks and break your web site for those browsers.

How well does it work?

To test CSS optimization, I downloaded the CSS files for 30 representative web sites, and ran CSS Tidy. I did the same for 30 different site themes installed in a sample web site using the Drupal content management system. (see the Appendix for more about how I tested)

For each group of tests below, the first table shows before and after file sizes for uncompressed CSS, and the second for compressed CSS. Since all production web sites should deliver compressed CSS, the second table's results are more relevant.

30 popular web sites

First up are the CSS files loaded for the home pages of 30 web sites selected from Alexa's global ranking of the 500 most popular web sites, plus a few other sites of interest.

Google, Yahoo!, and Windows Live are notably abscent here because they each embed CSS into their home page's HTML instead of using separate files. That's a good performance trick when CSS is already small and well-optimized.

Popular web sites
Uncompressed CSS
Site Original Optimized Saved Percent  
AListApart 12,067 8,801 3,266 27%
AOL 84,826 70,565 14,261 17%
AT&T 25,045 20,429 4,616 18%
About 47,969 46,440 1,529 3%
Adobe 44,423 30,761 13,662 31%
Amazon 26,875 17,107 9,768 36%
Apple 24,835 20,651 4,184 17%
Ask 10,597 8,222 2,375 22%
BBC 49,069 44,991 4,078 8%
CNET 45,622 33,331 12,291 27%
CNN 144,217 105,287 38,930 27%
Dell 97,346 74,215 23,131 24%
Digg 52,572 37,516 15,056 29%
ESPN 33,892 22,859 11,033 33%
Facebook 66,895 56,090 10,805 16%
Gamespot 232,129 185,874 46,255 20%
IBM 138,347 107,664 30,683 22%
IMDB 16,709 11,810 4,899 29%
Microsoft 17,872 15,501 2,371 13%
Mozilla 29,067 20,863 8,204 28%
Myspace 28,216 22,611 5,605 20%
NYTimes 75,264 51,896 23,368 31%
Slashdot 3,9076 34,494 4,582 12%
Sourceforge 65,152 52,638 12,514 19%
Weather 71,827 51,603 20,224 28%
Whitehouse 19,911 12,598 7,313 37%
Wikipedia 33,065 20,371 12,694 38%
YouTube 102,210 73,121 29,089 28%
ZDNet 37,195 31,099 6,096 16%
eBay 14,986 12,958 2,028 14%
Average 56,243 43,412 12,830 23%  
Popular web sites
Compressed CSS
Site Original Optimized Saved Percent  
AListApart 3,259 2,622 637 20%
AOL 18,732 17,444 1,288 7%
AT&T 5,267 4,383 884 17%
About 11,471 10,901 570 5%
Adobe 10,226 7,816 2,410 24%
Amazon 4,579 3,679 900 20%
Apple 4,934 4,335 599 12%
Ask 2,673 2,154 519 19%
BBC 10,145 9,513 632 6%
CNET 9,642 7,427 2,215 23%
CNN 20,667 16,276 4,391 21%
Dell 15,526 13,058 2,468 16%
Digg 10,300 8,346 1,954 19%
ESPN 6,809 4,716 2,093 31%
Facebook 12,711 11,613 1,098 9%
Gamespot 35,248 29,238 6,010 17%
IBM 19,468 16,268 3,200 16%
IMDB 3,415 2,754 661 19%
Microsoft 3,879 3,632 247 6%
Mozilla 6,274 4,666 1,608 26%
Myspace 7,089 5,701 1,388 20%
NYTimes 14,531 9,586 4,945 34%
Slashdot 8,273 7,339 934 11%
Sourceforge 13,348 11,076 2,272 17%
Weather 13,831 10,226 3,605 26%
Whitehouse 3,499 2,657 842 24%
Wikipedia 8,607 5,208 3,399 39%
YouTube 16,947 14,918 2,029 12%
ZDNet 8,312 6,980 1,332 16%
eBay 3,277 2,970 307 9%
Average 10,431 8,583 1,848 18%  

Clearly CSS optimization does reduce the CSS file size. Even very well-authored sites like AListApart and Slashdot saved a bit.

30 Drupal site themes

Next, here are the CSS files for Drupal and each of 30 standard themes. These are some of the most popular themes for Drupal. Garland is the default Drupal theme.

Drupal themes
Uncompressed CSS
Theme Original Optimized Saved Percent  
Aberdeen 28,617 19,251 9,366 33%
Acta 25,810 16,983 8,827 34%
AdmireGray 24,181 17,439 6,742 28%
Aeon5 19,861 13,732 6,129 31%
Amadou 27,002 17,795 9,207 34%
Andreas09 20,062 13,467 6,595 33%
AntiqueModern 28,022 18,201 9,821 35%
ArcMateria 23,757 14,629 9,128 38%
Austere 23,636 16,232 7,404 31%
Blix 33,288 20,358 12,930 39%
BlueBreeze 30,662 20,565 10,097 33%
BlueMarine 20,682 13,844 6,838 33%
BrushedSteel 26,490 15,999 10,491 40%
Chameleon 18,858 12,356 6,502 34%
Darsch 21,232 14,138 7,094 33%
Fancy 38,457 25,248 13,209 34%
Gagarin 23,001 15,832 7,169 31%
Garamond 25,672 17,741 7,931 31%
Garland 34,097 21,724 12,373 36%
GlossyBlue 27,744 17,058 10,686 39%
iTheme 35,357 24,109 11,248 32%
Kubrick 24,062 15,297 8,765 36%
NewsPortal 20,316 13,485 6,831 34%
Ocadia 21,054 14,062 6,992 33%
Pleroma 25,835 18,934 6,901 27%
PushButton 27,362 19,003 8,359 31%
Slash 21,472 14,296 7,176 33%
StylizedBeauty 24,123 16,444 7,679 32%
Twilight 37,951 21,005 16,946 45%
Zen 28,497 18,042 10,455 37%
Average 26,239 17,242 8,996 34%  
Drupal themes
Compressed CSS
Theme Original Optimized Saved Percent  
Aberdeen 6,710 5,052 1,658 25%
Acta 6,377 4,575 1,802 28%
AdmireGray 6,127 4,696 1,431 23%
Aeon5 5,088 3,861 1,227 24%
Amadou 6,716 4,815 1,901 28%
Andreas09 5,277 3,804 1,473 28%
AntiqueModern 6,668 4,778 1,890 28%
ArcMateria 5,569 3,964 1,605 29%
Austere 6,007 4,463 1,544 26%
Blix 7,456 5,232 2,224 30%
BlueBreeze 7,434 5,448 1,986 27%
BlueMarine 5,175 3,803 1,372 27%
BrushedSteel 6,272 4,234 2,038 32%
Chameleon 4,782 3,534 1,248 26%
Darsch 5,341 3,938 1,403 26%
Fancy 7,726 5,504 2,222 29%
Gagarin 5,703 4,255 1,448 25%
Garamond 6,251 4,678 1,573 25%
Garland 7,794 5,459 2,335 30%
GlossyBlue 6,574 4,607 1,967 30%
iTheme 8,038 5,948 2,090 26%
Kubrick 6,510 4,312 2,198 34%
NewsPortal 4,779 3,651 1,128 24%
Ocadia 5,347 3,833 1,514 28%
Pleroma 6,473 5,120 1,353 21%
PushButton 6,317 4,818 1,499 24%
Slash 5,124 3,852 1,272 25%
StylizedBeauty 5,861 4,384 1,477 25%
Twilight 8,042 5,335 2,707 34%
Zen 7,423 4,933 2,490 34%
Average 6,299 4,563 1,736 27%  

Again, clearly CSS optimization does reduce the file size a bit, even for lean themes like Chameleon.

Comments

The average compressed CSS file size savings for all of these tests was about 1.8 Kbytes. Let's put this into perspective:

  • If we look at a total page size, including HTML, images, Flash, JavaScript, and CSS, then a typical corporate or retailer home page is about 200 Kbytes. The 1.8 Kbytes saved by CSS optimization reduces the page size by under 1%. CSS optimization will not noticeably improve server load and bandwidth use.
  • If we look at web sites served over commercial Internet connections to broadband users, then the user's cable modem/DSL download speed limits performance. At a typical speed of 1 Mbyte/second, that 1.8 Kbytes saved would have taken just 0.0018 seconds to send. CSS optimization will not noticeably improve user page load times.
  • If we look at small business or home web sites served from a broadband connection, then the site's cable modem/DSL upload speed limits performance. At a typical upload speed of 100 Kbytes/second, that 1.8 Kbytes saved would have taken 0.018 seconds to send. Again, CSS optimization will not noticeably improve user page load times.
  • If we look at 3G phone users, then the 3G cell phone network's download speed limits performance. There are several different 3G speeds offered today. Using a low-end 1.4 Mbits/sec, or 175 Kbytes/sec, that 1.8 Kbytes saved would have taken 0.01 seconds to send. Once again, CSS optimization will not noticeably improve user page load times.
  • If we look at dial-up users, then the user's modem speed severely limits performance. For a 56K/ISDN modem and an optimistic 6 Kbytes/second, that 1.8 Kbytes saved would have taken 0.3 seconds to send. By itself this is just barely noticeable, but this improvement is lost within the 30 seconds it takes to send a typical 200 Kbytes home page over a dial-up modem. The leanest of the tested web sites used about 50 Kbytes for the home page. That would still take over 8 seconds to send to a dial-up user and a 0.3 second improvement won't be noticed. CSS optimization will not noticeably improve user page load times.

Amongst those that study user interaction, the rule of thumb is that a difference of less than 1/10-th of a second is not noticeable. At broadband download speeds, you'd have to reduce file sizes by about 120 Kbytes to save 1/10-th of a second. Since the largest compressed CSS file tested here is smaller than that at 35 Kbytes, nothing we do with CSS Tidy or any other CSS optimizing tool is going to have a noticeable impact on broadband page load times.

Conclusions

CSS optimization seems like a good idea at first. It feels good to get 20-30% size reductions by creating a more compact CSS file. But in the real-world context of a full web page and today's connection speeds, the few kilobytes saved from CSS optimization is not worth the effort.

If you want to speed up page load times, consider removing just one file from the site design. One icon. One image bullet. One background image. One rounded corner border. One single-pixel tracking "bug". Removing one file from the page saves the browser's time needed to send a request to a web server and wait for the file to come back. Today, this takes about 1/10-th of second for nearby sites and around 3/10-ths of a second for overseas sites. Compare that to the 2/100-ths of a second savings found from CSS optimization. For broadband users, dropping one file from the page design is 50 times more effective than CSS optimization.

So, if you need to speed up your web site, don't bother with CSS optimization. There are better places to focus your attention.

Appendix: How I tested

Popular web site tests were done by loading each site's home page and copying the downloaded CSS files. Each site's files were concatenated and run through CSS Tidy.

Drupal tests were done using CSS files from Drupal 5.2 configured to include the Aggregator, Block, Book, Color, Comment, CCK, and Forum modules. Each of these modules included their own CSS files. Drupal itself added its CSS files for Drupal defaults, the system, nodes, searching, help, locales, and user info. The CCK module was configured to include Field Groups, Image fields, and Link fields. These files were concatenated with the CSS files for each of 30 standard Drupal themes and run through CSS Tidy. Drupal's built-in CSS file aggregation and white-space removal was not used. If it had been, the CSS optimization savings would have been far less.

CSS Tidy 1.2 was used with the "highest_compression" template (no spaces or blank lines between anything). Comments and white space were removed, colors, fonts, and properties were reduced to simpler forms, backslashes and the last property's semi-colon were removed, and selectors merged.

Further reading

Related articles at NadeauSoftware.com

Web articles

Comments

Flawed arguments

I have to disagree with the general sentiment expressed in this article, and (to a lesser extent) the one about HTML tidying.

Firstly, even a 0.5% improvement in performance can matter if you put it together with other 0.5% improvements. Certainly a series of 5% improvements compounded on one another will make a noticeable difference, especially if they apply to every page on your site. Similarly, an inattention to performance in one area may make little difference, but errors elsewhere will compound it.

Secondly, the size of your files determines in part their cacheability. Smaller files are likely to be kept cached longer; larger ones may not be cached at all. In particular, the iPhone only caches files which have an *uncompressed* size of 25kb. This makes minification useful even if little is gained over compressing the original.

Thirdly, although the plaintext files may be relatively small compared to your images and other media, they are of vital importance because they have to be loaded before the browser knows about the other files. Files are not downloaded serially, but in parallel. Indeed, many transfers may take place at any one time, but they will only take place if the web page has been read to that point. This affects both the HTML and CSS and JS files which refer to other files.

Fourthly, these large image files may well be repeated throughout your site, and therefore should be cached (especially if you have specified caching on them). That means the effective size of the page is greatly decreased - and the relative gain of compression/minification is likewise increased.

Lastly, and most importantly, you make flawed assumptions about the way in which files are transferred from the server to the client. TCP/IP's receive window and its slow start algorithm makes the performance implications of larger pages more important than you think.

In any conversation between two hosts, each receiver has a window of bytes beyond which the sender will not send information until they have received an acknowledgment of receipt, for fear of network congestion. A typical receive windows might be around 16kb, although they can often be much smaller. If the file (gzipped or otherwise) is small enough to fit into that window, then it will be sent in a stream of packets by the server. If it is not, then the server will wait to send packets until the return acknowledgment comes back from the client. This at least double the latency, because messages have to go back and forth more than once.

The size of this window is increased with time. However, it can take a very long time to get up to "full" speed - longer than most website connections last. And this full speed is never the advertised bandwidth of the medium. In some cases, it can be a lot less. Think also about the various mobile clients that are out there now, and the speed of the networks that they are on.

Do not assume the effect of a reduction in size by dividing file size by time. Instead, get Wireshark and measure what actually happens when you (for example) refresh the page, force a refresh, clear cache and load the site again, and surf around the site. You will get far more accurate results.

Re: Flawed arguments

Thanks for your detailed comments! You raise several interesting points which I'd like to respond to below, in the same order as your comments.

First, regarding compounded improvements and errors:

Agreed. Inattention to performance can leave you vulnerable to unnoticed errors that compound. If you have the time and financial support, by all means go for every 0.5% improvement you can get. Otherwise, prioritize and do the most effective optimizations first. For most cases, CSS and HTML optimizations are less effective than better image compression, CSS image sprites, or adjusting a design to use fewer images.

Second, regarding file size and cacheability:

Different products use different cache replacement policies. Some are based on file age, while others consider file size or usage frequency (such as the iPhone's LRU algorithm). However, tuning for any one of these policies is a fragile optimization that may work for one product, but not another. These optimizations are usually not worth the time unless you have specific knowledge about the product your visitors are using.

If you are authoring just for the iPhone, then its file size and count limits are important to know (see Yahoo!'s iPhone Cacheability article). But a bigger issue is the slow download speed and high latency of cell phones. A normal 250 kB web page that loads fine on a PC or Mac could take a minute or more on a cell phone, and few mobile visitors will be happy with that. Instead of using CSS optimization to squeeze a big CSS file under the iPhone's 25 kB/file limit, create a mobile-specific page design (as Yahoo! did). A simpler, leaner page layout that's easier to read on a small screen will give you a smaller CSS file anyway, plus happier visitors. Always optimize for the user experience, not the technology.

Third, regarding loading of HTML and CSS files first:

As you say, HTML and CSS are bottlenecks when loading a web page (see Yahoo!'s Best Practices for Speeding up your Web Site). They must be loaded first before other files can be loaded in parallel (two at a time per host in HTTP/1.1, and see Yahoo!'s Maximizing Parallel Downloads in the Carpool Lane). Optimizing HTML and CSS will get the browser past this bottleneck sooner. But, for most sites the bulk of the download time is for everything after the CSS. I spot-checked a few representative web sites over a cable modem. For Yahoo.com, downloading the CSS takes just 3% of the total page load time. For Apple.com, it's 4%. NewYorkTimes.com uses 7% for CSS, CNet.com 9%, and both Microsoft.com and Amazon.com use 10% of their page load time for CSS.

However, about 50% of that CSS file load time is due to network latency (about 1/10th of second, depending upon visitor-to-server distance, and measurable using ping or SpeedTest.net). Making a CSS file smaller won't reduce the latency at all. So, at best, CSS optimization is working to reduce 50% of 10% of the total page load time. That's just 5%. Now, if you reduce the CSS file size and load time by 30% of that 5%, you've really cut the total page load time by under 2%.

A better place to focus your attention is on the 90% of the load time used by the rest of the page. Most of that is images. Removing or combining a few images will do far more to improve the page load time than optimizing the CSS file.

Fourth, regarding the relative value of text and image optimization:

Since CSS is cached as well, it is no more or less important than cached images. HTML, however, is usually marked by the server as non-cacheable. So, you're right: once a browser's cache is primed with a site's static content, HTML becomes a bigger part of each subsequent page load and HTML optimization becomes more important. But it still isn't important enough to be worth the time. As I explain in the companion article on HTML white-space removal, HTML optimization for a set of fairly large and representative web pages yielded a meager 0.5% size reduction, or less. For a 50 kB HTML file, that's just 250 bytes and it'll have no noticeable impact on page load time.

Additionally, most visitors arrive at web sites via a search engine link that drops them somewhere in the middle of the site. Visitors look at the page, quickly decide if it is what they want, and maybe leave. Only if they like what they see do they click to another page. For these pop-in-and-out visitors, their cache won't have any of the site's files yet. They'll have to wait for everything to download, whether HTML, CSS, or images. To make their experience faster, optimize the stuff that takes the most time on a fresh page load. And that's usually the images, not the CSS or HTML.

Fifth, regarding TCP/IP receive windows:

Agreed. The underlying network mechanism can be relevant. However, this is entirely out of your control and will vary depending upon ISPs, network routes, and current network congestion. Focusing too much on any of this makes for fragile optimizations.

Sixth, regarding proper benchmarking:

Agreed, the right way to do benchmarking is to time everything under real-world conditions. I do, but I only publish the results if there is a consistent noticeable result. For CSS and HTML optimizations, my benchmarks found that normal network jitter due to changing amounts of congestion was much larger than any gain from the optimizations.

Also, benchmarking isn't always enough. Web visitors come from all over the world, from all sorts of computers with different browsers, OSes, network connections, ISPs, and network routes. All of this variation makes deciding on a representative benchmark configuration very hard. Picking wrong can give you misleading results.

So, in addition to a few carefully chosen benchmark conditions, pay attention to the fundamentals of page loading:

  • Most visitors arrive at a site without any of its files in their browser cache. Optimizing for the cache size won't help them at all on the first visit. But first impressions of a site come from that first visit.
  • Most of the page load time is due to network latency for the page's files, not downloading each file's bytes. Making files smaller won't help as much as loading fewer files.
  • Most pages have one or two CSS files, but dozens of images. Chances are you can't reduce the number of CSS files much, but page design changes can significantly reduce the number of images.

And thus the conclusion of this article: Don't bother using CSS optimization to speed up a web site. Your time is better spent elsewhere.

I really cant agree with the

I really cant agree with the premise of this article.

We run a site with 100k pageviews per hour, 85% new visitors (high traffic news). We cannot use Drupals css aggregation/compression system because we use private download. Manually aggregating and compressing the files is our only recourse, if we did not do that our bandwidth would be through the roof.

Sorry, but to say "never" is going to far, some sites simply must do this.

Re: I really cant agree with the

The point of this and all optimization articles is to consider an optimization in context, not in isolation. CSS optimization does make CSS files smaller. But the size reduction is tiny in the larger context of an entire page download, and of repeated page downloads as a visitor moves through your site. Typical sites have a single master CSS file that is downloaded once. But decorative images and ads often change from section to section in a site, and from page to page with different ads each time. The cost of all those repeated downloads of images far exceeds the download cost of the single CSS file. If you're going to optimize, focus on the big repeated costs (like images) and not the one-time small costs (like CSS).

Also, please note again that the main cost in downloading a web page is latency, not bandwidth. You can shrink your files a few bytes here and there all you want, and you will have almost no impact. But drop one image and your benchmarks will show an improvement.

Let me show you the math again. A typical round-trip latency to get a file from across the country is 100ms. On a typical 10Mbit cable modem, 100ms is enough time to download 100 Kbytes. So, there's your trade-off. To improve the download time by 100ms, you can either optimize by cutting a huge 100 Kbytes from your page size, or you can remove one decorative image. Of course it is a little more complicated than that due to parallel downloads, CDNs, intermediate caches, etc. But that's the idea. It takes a BIG change in page size to make that a better optimization than making a LITTLE change to a page design to use one fewer images. And the few Kbytes saved by CSS optimization is definitely not a big enough change to make it worth the effort.

I love this

This is the third post I read on your blog and I can't go before I say thanks.

I sought to optimize my Drupal site because it take up to 7 seconds for Google to crawl each page, and that's too much pageload time. I read your tips on Drupal Page Cache and Block Cache. I found all those integrated in Drupal 6 now.

Here I come this CSS optimization and I really admire you. Not only did you spend the time and professional project management skill into the analysis, you gave it all out so free and open-minded.

Yes, CSS optimization is good. Each CSS coder should know how to optimize it without even using the software mentioned above.

I come upon too many theme, be it for Drupal or Wordpress, regardless of how beatiful their design is, the theme performance sucks.

Not only they never optimize the CSS, with tons of redundent attributes, many redundant class declarations. More importantly, they never optimize their images.

Can you beleive I come upon some very simple header background that's.... 100Kb? Imagine I optimize it to PNG-8 for just 20Kb. And the on that's 20Kb I could down it to 5Kb. So yucky they are in term of performance. Just reduce the filesize of those one image is equal to optimizing few CSS files.

Well, time is not much so this is it for now. Will discuss more in the future.

By for now, and thanks again for great sharing.

Generally I do not post on

Generally I do not post on blogs, but I would like to say that this blog really forced me to do so! Thanks, really nice blog.
implant mammaire

Bless you mate! Great tips

Man.. your site is full of awesome tips to improving my sites. With your tips and cloudflare my sites are really fast on loadtime. After a while i noticed a boost in google rank too. (That's means that google love fast sites. You're doing a great job for us :* Cheers!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

Nadeau software consulting
Nadeau software consulting