Google recently released mod_pagespeed under an Open Source license. The purpose of this module for the Apache webserver is to optimize content that is delivered by Apache to the end user. You may want to raise your voice at this point and claim that you are already using proper caching techniques on the server side and there is already mod_deflate out there, but mod_pagespeed can be used side by side with mod_deflate and mod_pagespeed is not just about compressing your content.

Further on, you might say that today’s servers are already so fast that it is simply not necessary to fight about milliseconds. Well, Google has apparently a different point of view on this subject and they decided to add a signal to their search algorithm that takes the page load time into account.

So, considering that Google wants you to optimize the speed of your site, what can you do to speed it up? Ironically, the first thing you may want to do is to get rid of Google Analytics. It slows down the page load time significantly and it’s of no good use anyway since Google has decided to allow end users to block the tracking of the Google Analytics code. So since your Google Analytics stats are most likely not accurate any longer and they slow down the page load time, why should you continue to use them? There is no reason to. If you want an accurate analysis, Open Web Analytics is a free alternative that really tracks what you want to keep track of.

Once you got rid of Google Analytics, you may also want to look into installing YSlow, a free tool from Yahoo! that suggests ways to improve a web site’s speed and the Firefox Page Speed extension. Do not confuse the page speed extension with mod_pagespeed!

So what does mod_pagespeed do? Here are two examples of what mod_pagespeed can optimize on the server side:

  • Caching
    The Apache module can set the HTTP response headers in a way that extends the expiry time of static content, such as CSS, images and JavaScript. Once a user accesses your website, his browser fetches the CSS stylesheets, media files and javascripts and stores them in the client side cache. Next time the user returns to the site, the pages will load faster because the browser will not need to reload that static content from the server, as it is read from local cache files.
  • Minimize Round Trip Times
    Each page may require that the browser performs a series of HTTP requests to the server, 1 request for each javascript, media file or css-file. So if you have 10 javascripts and 20 images, this would result on 30 requests. Particularly with CSS and javascript files,  it makes more sense to combine them into fewer streams, eradicating the need for dozens of requests to fetch one HTML page.

So while this module takes over some of the page optimization work, it does not help you with everything that is considered to be a good practice for page optimization nowadays. I assume future releases of the software will enhance the feature list.

The question I have for you as the reader of this blog however is: are you ready for it? Is the software you are using ready for mod_pagespeed? From my web hosting perspective I can tell you that we won’t jump on that ship for shared hosting customers for the following reasons:

1. This is a new software release. It will have bugs. Web hosts don’t like bugs and they do everything to squish them.

2. The module might do more harm than good as far as the server performance goes: what if the extension affects the CPU too much and it crashes servers?

3. The module has not been tested with the most common content management systems and it will probably never be tested. Will it work with Joomla, Drupal, WordPress? What if it breaks one of these or a third party component? Who will support it? (Yeah, I know the answer).

4. As Google itself points out: it might even bring up new security issues.

With all of this in mind: are you ready for it?