In addition to the PageSpeed Insights test, Google also offers the so-called Google PageSpeed Module. A setup that automatically optimizes websites according to Google's specifications. In our test, however, the module had exactly the opposite effect: it mercilessly ate up the performance of our sites . A field report.

Most site operators are familiar with it: the Google PageSpeed Insights test. It reliably reveals optimization potentials of the tested websites and at the same time shows how to optimize the optimize your own site can. Thus, it is often one of the first places to go for performance optimization.

The tips and hints with which Google PageSpeed Insights initially leaves the user relatively alone are automatically implemented by the Google PageSpeed Module. If you install it on the web server, the program not only uncovers optimization potential, but also implements the improvements directly.

Especially in light of the fact that Google recently made the loading time an official ranking criterion, the possibility of automatically optimizing site seems more than attractive. The module thus becomes a supposed secret weapon of performance optimization. And of course it was also very tempting for us.

Therefore, we tested it extensively a good year ago and at the request of several customers. Our conclusion: For us as host the module makes no sense.

Project killer complexity

To make a long story short: The complexity of the combination of WordPress and the PageSpeed Module's multiple filtering options made it impossible for us to implement. Mind you, it's not the module's overly complex operation that's to blame, but the sheer number of configuration options. The module itself can be operated quite comfortably and intuitively.

The Page Speed Module offers two filter sets predefined by Google: The so-called core filters and the Optimize for Bandwidth Filters. The Core Filters are a set of rules that the Google PageSpeed team has put together and that they believe are safe to apply to most sites . However, there is no guarantee of this. New filters are always being added to the Core set, which continuously makes the optimized sites faster - at least in theory.

The Core Filterset is always up-to-date, but also quite unstable. In practice, this means that you should check the stability and loading time of site after updates. Otherwise there is a risk of a page crash.

The Optimize for Bandwidth filters offer more running stability and can be used for even more different page types as a standard filter set.

In our test, we mainly used the more stable filter set to better anticipate the modular structure of WordPress . Nevertheless: If the PageSpeed Module was set correctly for one site , it crashed the layout or paralyzed important functions, such as the shopping cart, for the other site .

In addition to these standard sets, each user can create their own configuration - depending on what and how much has already been optimized. For example, CSS documents can be compressed via the filters (Google then automatically deletes white space and comments in the stylesheets). The cache times of individual resources can also be set or images can be bundled into sprites.

It is exactly this abundance of setting options that makes the PageSpeed Module impractical from the hoster's point of view.

Optimization via HTML - live and via cache

But how exactly does the Google PageSpeed Module work? In principle, the same or very similar optimization measures are implemented as recommended by Google PageSpeed Insights . The optimization steps are performed either via a cache or live. For this, the PageSpeed Module pulls the HTML code of the site and looks for optimization potentials, which it then implements.

The implementation of the optimization measures via the cache is the more complex solution. Because here you have to set which optimizations should run via the web server and its cache and which should be performed by the module itself. As a result, the implementation of the optimization measures must actually be set individually for each page configuration.

The live version, on the other hand, requires an enormous amount of RAM and processor power. Thus, the optimization itself eats up so much performance that the sites loads significantly slower. The live optimization is therefore suitable either for very powerful servers or sites with only a few visitors.

Almost endless possibilities

From a purely mathematical point of view, the 50 existing filters result in a very, very large number of possible combinations (a number with 15 zeros). This is of course fundamentally an advantage, because you can configure the PageSpeed Module as you need it for your own website. For us, however, this abundance of combinations was the project killer.

Individual sites can be optimised quite excellently via the module - if you know how. Because there is only one set of requirements here. As host , however, we have to consider a whole host of different WordPress configurations. And this is the crux of the matter: Because the module's setting would have to be so general that all existing sites would be covered by it, as well as the bulk of potentially new sites .

This leaves only a very small number of possible filters. However, these in turn then only have minimal influence on the page load time.

This is exactly what happened in our test. And even more: Partially, the sites even became slower due to the use of the module.

The Page Speed Module has eaten our performance

The PageSpeed module requires a relatively large amount of power. With our BOXES, this can lead to the module eating up more performance than it can gain through optimization. This is because the website content is compressed, but the compression in turn requires computing power. Thus, the overall loading time of site can suffer from the optimization. This is exactly what happened to us in some cases, especially when the sites was tested under load.

Image optimization is easier and better with plugins

This imbalance is especially noticeable in image optimization: in our test, the compression results by WordPress plugins were not only better, but they also ran more stable and used only a fraction of the power.

Although Google's image optimization is not bad in principle, we noticed in our test that images previously optimized by the PageSpeed module were subsequently still rated as worthy of optimization by the PageSpeed test. These paradoxical statements are unfortunately typical for Google PageSpeed Insights.

Conclusion: Our hosting is the wrong use case for the Google PagesSpeed Module

So the two project killers for the implementation of a central configuration of the Google PageSpeed Module were the diversity of the sites hosted by us in combination with the performance hunger of the module. Therefore, an implementation on our Nginx webserver does not make sense at the moment.

For individual projects with the appropriate computing power, however, the PageSpeed Module certainly remains an option.

What is your experience with Google's PageSpeed module? Or do you have any questions about using the module? Write us a comment or contact us directly via the support chat on raidboxes.com.