What is mod_pagespeed
Google recently released a chunk of code in the form of an Apache module. The idea is that you install it in your Apache server, it sits in between your application and the web browser and modifies the served requests to make the page load faster.
It does this by using combinations of filters, some are well known best practices, others are newer ideas. For example on filter simply minifies your JavaScript while another embeds small images in a page using data-uris. The changes these filters make range from low risk, to high risk. It should be noted that not all the filters will improve the page time some even making pages slower in some cases.
So what’s the issue?
The issue here really isn’t mod_pagespeed, but it’s the way people are viewing it. In my job as a Web Performance Engineer I have had several people recently say to me “let’s put mod_pagespeed on our web server to make it faster”. This is a break from normal attitudes, if someone were to to say “we should put our images into data-uris” then people would question the speed benefit, or the extra load on the server. For some reason when Google implement a page speed module people just assume that it will make their page faster, and that it will work in their environment. The truth is that Google really have no idea what the module will do to your page.
The second issue is that all these tweaks can usually be better implemented at the application level. If you minimize all your JavaScript as part of your build process then the web server will not have to do it for you. The same applies to data-uris. If they are simply part of the page then the browser doesn’t need to read in the extra image, uuencode it, then compress it. All that is quite a lot of work, which only really needs to be done once.
So what should I use mod_pagespeed for then?
You don’t always have access to the application code. If you are using third party software then before mod_pagespeed you may have had no control over the minification of CSS. This is where the module really shines. It gives you a layer between the application code and the web browser where you can apply all sorts of performance tuning.
The other advantage I can see is for looking for the best tunings to apply to your application quickly. You can setup mod_pagespeed and and run experimental tests with the filters on of and with a control to quickly figure out what rules you should apply in your application.
Thanks for the blog-post, Daniel. There are two points you made I want to comment on:
1. Converting images to data-urls is hard to do by hand because not all browsers support data-urls. In other cases the decision about whether that conversion is a win or not is dependent on the browser, the connection speed, and other dynamic aspects. These are very hard to change statically.
2. You raise a concern that javascript minification should not be done in the server. The way you phrased it implies that the minification must take place every time the page is served. This is not the case. mod_pagespeed caches the optimized versions of resources that it creates. As long as the origin javascript is not updated, mod_pagespeed will not need to recompute the optimization; it will serve the resources from cache.
However, you make a very good point that the best practices we’ve automated with mod_pagespeed are not optimized for a particular site. We recommend using http://webpagetest.org to measure the site speed with and without mod_pagespeed, and to help you tune the mod_pagespeed options. Be sure to run large numbers of iterations, both first & repeat view, because many sites exhibit a wide variance in performance. 10 is the maximum number you can do at once.
Also see Page Speed online, http://pagespeed.googlelabs.com/, which gives you very rapid feedback as to what can be improved on your site. Many of the recommendations it offers are done automatically by mod_pagespeed, some must still be done manually.