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

• New Google Tools Help Speed Up Your Website
• Tips For Turning Your Sluggish Website Into a Speed Demon
• Site Optimization Tutorial

Woolly, the CSS sheep.

Cutting edge web technologies never come without a cost.

Sometimes it means limited browser support for emerging standards, and other times it means having to go back and rewrite your code when draft standards change.

When it comes to the still-in-progress CSS 3 spec, not only does browser support vary widely, but most browsers have implemented what are know as vendor-specific prefixes. The prefixes complicate things, and they require more work to drop them into your code, but they do serve a purpose.

For example, if you want rounded corners in CSS 3, you’d use border-radius to define them. But because border-radius is still being finalized, browsers only support their own versions of the rule. So, -moz-border-radius will target Firefox, -webkit-border-radius targets Safari and Chrome. For Opera, it’s -o-border-radius.

None of the special prefixes will validate, which is less than ideal. There’s a suggestion floating around that CSS validators should change their behavior regarding vendor prefixes by issuing a warning instead of an error. Regardless, if you want absolute standards conformance in your CSS code, you’ll need to stay away from vendor prefixes.

However, if you want to play with CSS 3′s new toys, you’ll see there are some very good reasons why vendor-specific prefixes exist, and why you should use them (for now) in addition to the actual proposed rules of CSS 3.

To stick with the border-radius example, consider what happens when you want to target just one corner of an object. The spec was in flux in when the WebKit project decided to use -webkit-border-top-right-radius and Mozilla went with -moz-border-radius-topright. Without the prefix, you’d have to deal with two different CSS rules, potentially forever, with one of them eventually being depricated, but still out there in older versions of that browser.

Both prefixes are technically “wrong” and that’s a good thing. Eventually, the final spec will be published and only one rule will be standardized, with all browsers implementing that rule. At that point, you can simply go into your code and delete all of your prefix rules. The vendor names make them easy to find and zap.

One thing you should definitely not do is target only one browser’s prefixes. As Apple’s disingenuous “HTML5″ showcase recently highlighted, optimizing for a single browser is never a good idea.

If the idea of vendor-specific prefixes strewn about your otherwise standard CSS makes you uneasy, there is another possibility — offloading all the prefixing stuff to JavaScript.

Developer Arron Gustafson has written a critical article for A List Apart where he derides vendor-specific prefixes and offers a JavaScript alternative for those who feel the same way he does.

Gustafson refers to vendor prefixes as “forking” CSS. While we agree with his point, the word “forking” is problematic if only because there is nothing wrong with forking code. In fact, it’s the norm in the open source world. (You are using Git or Mercurial right?). And vendor prefixes are not forks, they’re hacks — temporary ways to push the boundaries of the web while standards bodies catch up.

Terminology aside, Gustafson’s point is valid — ignoring standards and littering your CSS with browser-specific code are both bad ideas.

Gustafson’s little JavaScript library can help you avoid vendor prefixes in your CSS. But, impressive as the script is, all it really does is offload the prefixing to JavaScript. The approach has some downsides — it means additional page load times and it neglects users who have JavaScript disabled.

If you want to start using CSS 3′s features now, you’re not going to avoid vendor prefixing, but at least you can choose how to handle it. Whether that means using the prefixes in your stylesheet, putting your vendor-specific code into separate stylesheets, or using a JavaScript solution like Gustafson’s is up to you.

See Also:

• Apple’s HTML5 Showcase Less About Web Standards, More About Apple
• Where on the Web Is HTML5?
• Get Started With CSS 3