We all want our websites to load faster, but speeding things up can be tricky. There are numerous tried and true tricks we all use to keep page load times down, but once you’ve done a few rounds of optimization, you tend to hit a plateau where it’s tough to squeeze any more speed out of your code.
Most web developers are familiar with tools like Yahoo’s YSlow and Google’s Page Speed. If you haven’t ever used them, go install both right now — they’re available as add-ons for Firefox. Both tools are designed to help you speed up your site’s page load times by showing you exactly what’s slowing them down, and used in tandem, they can alert you to some optimizations you never knew existed.
I recently sat down and tried, as best I could, to do everything that YSlow and PageSpeed recommended and I managed to shave my page load time roughly in half. When I started, my homepage took between four and six seconds to load. Now, it loads in one to three seconds on average.
To compare load times I used both YSlow and PageSpeed, as well as WebPageTest. Those numbers aren’t exactly benchmarks, since there’s some speed variation depending on what’s loaded in the cache, but a performance increase of about 30-40 percent is what you can expect if you haven’t yet explored these methods.
Some of what YSlow and Page Speed will tell you should be obvious — limit your HTTP requests, minimize, compress and combine your JavaScript and CSS files, use CSS Sprites, put your script tags at the bottom of the page and compress your images.
However, some of the more obscure and less-used (judging by viewing source code around the web) techniques these tools point out can make a surprising difference.
Before we get to the “how to” part, keep in mind the old saying “premature optimization is the root of all evil.” What I did with YSlow and its ilk was the last bit of optimization I did. In other words, be sure you’ve taken care of the big problems before you try to stamp out the smaller ones.
That said, I was surprised by how much of a difference some very small changes made.
The Good
Long before I turned to YSlow, I optimized my backend code to minimize database hits, installed Memcached to further reduce the database load, and set up a separate domain to serve static files. The later change made a huge difference since the main instance of my site is running Apache and the static files are now served by a much lighter-weight, faster Nginx server.
The site I set out to test YSlow and Page Speed on is my travel blog, which is somewhat image-heavy. So, the first thing I did was run all my images through SmushIt, Yahoo’s lossless image compression tool that’s part of YSlow.
All of the images on the site were already compressed using Photoshop’s “Save for Web” exporter, but I still managed to shave an additional 2-5kb off my images without any loss of quality using SmushIt. When you’re loading ten or more images per page, that’s a significant savings.
In fact, I could compress my images quite a bit more if I were willing to make some trade-offs in image quality. I’m not in this case, but you might be able to. The best approach in my experience is to see what your overall image size is, run everything through SmushIt and, if you still aren’t happy with the results, go back to your image editor and see if you can compress things even more using lossy techniques.
The Bad
While I managed to squeeze down my images somewhat, for the most part I was already following the more obvious best practices — loading JavaScript last, using multiple domains and so on.
It wasn’t until I turned to my style sheets that I saw where I had really gone wrong.
Perhaps the most overlooked thing you can do to speed up your page is reduce the complexity of your style sheets. Wherever possible, use classes to group similar elements and make sure you take advantage of the cascade. If all your body text is going to be Georgia, define that rule once under the body tag rather than littering it throughout your style sheet.
Another thing you may notice Page Speed telling you to do is “Use efficient CSS selectors.” Browsers read CSS from right to left, so the more specific your selectors, the less time it takes the browser to figure out what to do with that element. The less specific the selector, the greater the number of nodes the browser needs to evaluate.
Consider this HTML, a fairly typical HTMl5 navigation menu:
<nav id="top">
<ul>
<li>
<a href="/" title="My homepage">Home</a>
</li>
<li>
<a href="/" title="My Blog">Blog</a>
</li>
<li>
<a href="/" title="My Photos">Photos</a>
</li>
</ul>
</nav>
Now suppose you want to style the actual link element. The most inefficient way to do this would be something like this:
nav#top ul li a { color: red; }
In order to figure out which a you’re talking about, the browser needs to traverse four tags. Let’s redo that with something much more efficient:
<h1>top a { color: red; }</h1>
Now there are just two tags to traverse. And note that we got rid of the nav selector with the ID, and the ID is already unique. There’s no need to add the tag as well.
If we wanted to be even more efficient, we could add a class called “red” to each of our a tags and simply do this:
.red {color: red;}
So how much does this gain you? In my case, re-writing my CSS — which had grown pretty sloppy over the years — dropped a full second from my page load time. That may not sound like much (and it isn’t if you have inefficient database queries or other, bigger problems), but when it comes to this stage of optimization, every little bit helps.
The Ugly
A few of YSlow and Page Speed’s suggestions aren’t possible in some cases, mine included. One big thing that could speed up my static content would be to use a CDN. Unfortunately CDN’s are expensive and outside the price range of small blogs like mine. Also, a shared server is cheaper than a dedicated server, but can be slower.
Other unfixable problems are due to my hosting setup. I can’t set the expires headers for my static files because my Nginx server is global for all shared hosts on that server. Luckily, with Nginx, the first load is pretty fast. The browser may not cache images and static files as aggressively as I’d like, but for now it works well enough. I could compile my own instance of Nginx, and thus set the expires headers myself, but I haven’t tried that yet.
Another problem that Google’s Page Speed tool likes to nag you about is using cookie-less domains for static images. In my case, I serve my static files from the subdomains media and images. Because my top-level domain needs cookies, the subdomains inherit them as well. This is why big sites like Yahoo use an entirely separate domain for static files (usually some subdomain of yimg.com in Yahoo’s case).
There are some other areas that didn’t apply in my case, but may be slowing down your site. One big culprit is third-party content. If you’re loading JavaScript from other sites — to add social networking or bookmarking buttons, for example — pay close attention to how fast those scripts load. They are notorious for slowing your page down.
Another easy way to speed up your pages is to make sure your CSS and JavaScript files are served using GZip compression. Good web hosts should offer a way to do this. If yours doesn’t, consider jumping ship for one that does.
As with any kind of optimization, there are trade-offs involved with nearly everything that YSlow and Page Speed will suggest. For example, to make your CSS selectors more efficient, you may be tempted to litter your HTML with IDs, which is a no-no if you’re trying to maintain good semantic code. Likewise, compressing images is all good and well, but turn them into a pixelated mess and you’ll turn people off no matter how fast your site is.
The secret to good optimization is to find a balance. Provide quality content and wrap it in well-written code, but also make sure what you create loads as fast as possible. Don’t sacrifice too much quality in the name of speed, and vice versa.
Illustration from “Physics for Entertainment” by Yakov Isidorovich Perelman from Archive.org
See Also:
Google’s Chrome web browser will soon gain hardware-accelerated graphics — the latest trend for web browsers that has already shown up in early builds of 
