mod_pagespeed, streaking through a living room near you. Image: Kevin Dooley/Flickr.

After nearly two years of testing and improving, Google is removing the beta label and releasing mod_pagespeed 1.0. The mod_pagespeed tool is Google’s open source effort to speed up websites running on the popular Apache web server. Pagespeed automatically optimizes pages and their resources, making websites load faster.

No one likes waiting for a websites to load. It doesn’t seem like fractions of a second would matter, but survey after survey tells the same story: On the web it’s instant gratification or we’re gone. Not only do your visitors dislike waiting on pages, Google dislikes sending people to pages they’re going to have to wait on and it penalizes slow-loading sites accordingly.

If you’d like to get mod_pagespeed up and running on your own server, head over to the mod_pagespeed site, which has downloads and detailed installation instructions. Google’s Ilya Grigorik also has a nice overview of how to automate web performance with mod_pagespeed on his blog.

Despite the beta label that’s been attached to it for two years, Google says that over 120,000 websites are already using mod_pagespeed, including big-name web hosting companies like Dreamhost and content delivery networks like EdgeCast.

Google’s mod_pagespeed is part of the company’s PageSpeed Optimization Libraries, a set of tools for web developers to test and improve page load times. Other tools include the PageSpeed Service, which essentially does all the hard work of optimizing your pages for you, and PageSpeed Insights, an analytics tool that offers suggestions on how you can improve your site’s load times.

Page Speed’s rewriter is done before the unoptimized version even starts loading images. Image: Screenshot/Webmonkey

Google has added yet another trick to the company’s Page Speed web optimization service — a page rewriter that turbocharges your site by making sure that your visible, above-the-fold content loads before anything else.

Google started on its web optimization quest with the Page Speed browser extension, then it moved the Page Speed tool online with an API and then created the Page Speed Service to handle some of the tricky bits of web optimization for you. Now the Page Speed service has another trick for users.

Page Speed’s new rewriter, which Google refers to as “Cache and Prioritize Visible Content,” works by optimizing three main things on your site — all of which are standard best practices for speeding up a website, but are often hard for smaller sites to pull off. First off the Page Speed rewriter isolates those parts of the page that can’t be cached (logged in user info for example) and caches the rest of the page.

The next step is, as the name implies, to “prioritize visible content rendering.” The Google blog is a little unclear on how this works, saying only that the rewriter “automatically determines and prioritizes the content that is above the fold of the browser, so that it doesn’t have to compete with the rest of the page.”

The third part of Page Speed’s optimization is to defer the loading of any JavaScript until the visible content is loaded.

At the moment the Page Speed Service is invite-only, but if you’d like to request access, head on over to the sign-up page and drop your e-mail and URL in the form.

While you’re waiting for access, if you want to see what Page Speed’s rewriter might be able to do for your site, you can head over to Web Page Test, which now has a profile for the Page Speed rewriter. I ran my personal site (a very simple, static HTML site served by Nginx) through it and found that, as you can see in the image above, the rewriter considerably improved the first load time of images (pretty much the only thing that takes any time to load on my site).

Google still wants to make your website load faster. The company started on its web optimization quest with the Page Speed browser extension, then it moved the Page Speed tool online with an API and now Google is offering up the Page Speed Service.

Google’s new Page Speed Service is invite-only at the moment, but if you’d like to request access, head on over to the sign up page and drop your e-mail and URL in the form.

Google’s new Page Speed Service is one part optimization tool and one part content distribution network (CDN). Google essentially grabs your website, caches it and serves it from the company’s extensive network of servers around the world. The best part about Page Speed is its simplicity — all you need to do is point your DNS to Google’s servers. After that Google handles the rest and you don’t need to worry about minifying your JavaScript, compressing images, caching, gzipping, or any other web performance best practices.

For your site’s visitors everything works just as it always has, the page load times are just shorter. At least that’s the theory. In reality, how much the Page Speed Service will speed up your site varies considerably depending on how well optimized your website is to begin with.

The Google Code blog reports that, on average, pages served from Page Speed are between twenty and sixty percent faster. If you’re curious to see how Google’s Page Speed service stacks up against your current setup, you can compare load times through WebPageTest. I ran my site through the test and the Google optimized version was roughly 40 percent faster, though judging by the screenshots it didn’t quite render properly.

The rendering problems may have been WebPageTest’s fault, though the Page Speed Service documentation seems to indicate that not every page is going to render properly. The Page Speed Service offers a tool to blacklist any specific pages you don’t want Page Speed to serve up because it doesn’t render them properly.

It’s also worth bearing in mind that, while a 40 percent speed boost did shave over half a second off my site’s page load times, most of the performance gain came from Page Speed’s heavily cached CDN. If your site is already well-optimized, but lacks a (somewhat expensive) CDN, Google Page Speed isn’t going to help you out any more than existing services like Amazon’s CloudFront or any other CDN.

The Page Speed docs explain some more in-depth methods of testing your website using various browser proxy add-ons so you can perform your own, more thorough speed tests before you commit to using the Page Speed Service.

For now the Page Speed Service is free, but don’t expect that to last. Eventually, when Page Speed opens up to everyone, Google plans to start charging for it. For now the company isn’t committing to actual prices, saying only that Page Speed will be “competitive.” Presumably that means something in the ballpark of Amazon’s S3, CloudFront and similar services.

See Also:

• Speed Up Your Site With Google Analytics New Page Speed Tools
• Speed Up Your WordPress Site With Google’s New Page Speed API
• Google Page Speed Now Works in any Web Browser
• How to Speed Up Your Site With YSlow and Page Speed

Google’s Page Speed testing tool, which recently went from a browser add-on to a web-based tool, now sports a new API. The Page Speed Online API allows outside applications to send URLs to Page Speed and get back a list of things the site developer can do to speed up the page in question.

If you’d like to try it, head over to the new documentation page and request an API key. Sample apps include using the Page Speed Online API to display suggestions for speeding up sites or even combining the API with the Google Charts API to show a visual breakdown of the page’s resources.

For a more practical example of how the Page Speed Online API can help out your site, check out the latest version of the W3 Total Cache plugin for WordPress. If you’re not already using W3 Total Cache in your WordPress installation, we highly recommend you install it, especially now that the plugin taps into the Page Speed API. W3 Total Cache now sends your pages to the Page Speed Online API and then offers Page Speed suggestions, right in the WordPress dashboard.

See Also:

• Speed Up Your Site With Google Analytics New Page Speed Tools
• Google Page Speed Now Works in any Web Browser
• Yahoo’s YSlow Page Speed Tool Now Available for Chrome

One of the most useful browser extensions for web development is coming to Chrome.

Google is working on a Chrome version of its Page Speed add-on. Page Speed is an essential tool for testing sites in Firefox. It breaks down all the stuff on your page and shows you how long everything is taking to download, execute and render. It’s also fully open source and it has its own SDK.

Matthew D. Steele, one of the key engineers at Google responsible for Page Speed, has confirmed that a Chrome version is “already in the works,” and will be ready within a couple of months.

Page Speed currently runs inside of Firebug on Firefox, and there is already Firebug Lite for Chrome. There’s no word yet on whether Page Speed will remain dependent on Firebug (Lite) once it moves into Chrome, or if it will be a stand-alone add-on, but we’ll find out more details soon. In the meantime, if you have an answer to that mystery, let us know in the comments.

If you are curious about using Page Speed to speed up your website, check out Scott’s recent post on using Page Speed and YSlow together.

See Also:

• Chrome 6 Arrives, Just in Time for Cake
• How to Speed Up Your Site With YSlow and Page Speed
• Apple Updates Safari, Turns on Extensions

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