Question

We’re being told that fewer HTTP requests per page load is a Good Thing. The extreme form of that for CSS would be to have a single, unique CSS file per page, with any shared site-wide styles duplicated in each file.

But there’s a trade off there. If you have separate shared global CSS files, they can be cached once when the front page is loaded and then re-used on multiple pages, thereby reducing the necessary size of the page-specific CSS files.

So which is better in real-world practice? Shorter CSS files through multiple discrete CSS files that are cacheable, or fewer HTTP requests through fewer-but-larger CSS files?

Answer 1

Your first port of call is using YSlow or Google Speed to figure out what is going slowest on your site. Sometimes a badly compressed (large) image or two can be slowing the entire thing down. You are told to reduce HTTP requests because each request has a setup cost associated with it but if taken to the extreme can lead to worse performance. In your case having a CSS file for each page is bad form as it means it is harder for browsers to cache.

Taking one method to the extreme is bad practice and you should attempt to approach this problem from a wide angle such as:

• Properly compress images or use CSS sprites (reduces HTTP requests)
• Implement proper web caching using Expres, ETag etc (so clients don’t have to rerequest everything)
• Optimise your CSS and Javascript files using YUI or another similar tool
• Improve your CSS / javascript code for performance. Certain CSS selectors can lead to the browser taking longer to render a page
• Replace images with pure CSS where possible i.e. background colors etc.
• Use GZip compression on any text output i.e. html, css, js

If in doubt, look at the source page for the Google home page. They optimise that page heavily and it will give you good clues on what to do.