Google PageSpeed Insights is an excellent way to get a quick overview of your website's optimization potential. Today I'll show you how to use this potential and increase your PageSpeed Score. However, you should not slavishly follow the Google results. Because the PageSpeed error messages are not always useful.
Some time ago, our colleague Caspar Hübinger found very clear words for his Google PageSpeed Insights result in one of his blog posts. And he not only criticizes the tool, but also the use of the tool itself. Because if you don't know how to interpret and fix the individual optimization suggestions, you can quickly get lost in the nonsensical hunt for a 100 rating. But that would be unwise. Because utopian Google PageSpeed scores are usually a waste of time. Optimizing the loading time is more important.
Fully responsive, loads in 500 ms, and Google's shiny shittool tells me my mobile performance is "fair", bc of render-fucking-blockhead CSS.
Caspar Hübinger(Glueckpress)
Today I'll show you how to interpret the most important error messages from Google PageSpeed Insights and optimize your website accordingly.
But before I show you how to interpret the individual error messages and fix the errors, I would first like to explain how to use Google PageSpeed Insights correctly. We have already seen that some people are very focused on their PageSpeed score without keeping an eye on the loading time of their website.
If you are not interested in this section, simply skip it and learn directly how to fix the "Compress CSS" error message.
Google PageSpeed error messages are not always correct and important
You should never rely solely on the results or error messages from Google PageSpeed Insights. This is because the Google tool does not measure the most important parameter of your website: page load time. To measure this correctly, I recommend Webpagetest.org.
You can only make meaningful statements about the success of the optimization if you have the page load time in mind right from the start when optimizing your website. After all, the goal of any optimization should always be an improved user experience. In the case of performance optimization, this is of course the page load time and the perceived page load time.
NOTE!
Always measure the page load time first before optimizing the performance of your website. This is the only way to assess how successful the optimization was.
Faster page load times and smaller page sizes are always an advantage for the user experience. People's patience and attention spans continue to decrease(as this study by Microsoft shows) - this is particularly important for e-commerce - and more and more traffic is coming from mobile devices. As early as 2016, 56% of Germans regularly accessed the internet via smartphones or tablets. Connection speeds and data volumes are not always unlimited here. Lean, fast websites are therefore appropriate.
However, Google PageSpeed only provides information about the optimization potential of your website and allows only a few conclusions to be drawn about the user experience. The low informative value of Google PageSpeed error messages is reinforced by the fact that the tool cannot be immobilized in certain areas, or only with considerable additional effort.
For example, the reference to browser caching will always appear when external resources - including Google's own services - are integrated. However, these resources cannot be covered by your website's browser caching. The error message therefore has no relevance to the user experience of your website, but is produced by the logic of the tool itself. In the worst case, however, the message is interpreted as if no browser caching is active at all.
So don't focus primarily on the Google score, but on the loading time. This is the only really important factor.
But what about my Google ranking?
The example of the message with the missing browser caching makes it clear why you should not be put off by a supposedly poor PageSpeed result.
If you have integrated Google Maps or Google Analytics on your website, for example, these will generate the following error message:
The same applies to other third-party services. For example, our support chat.
Every time we therefore test our website with PageSpeed Insights, this point is chalked up. This means that we know that this factor always negatively distorts our results and therefore simply ignore it.
For the SEO of your website, this means that the loading time and user experience are much more important for the Google ranking than the specific PageSpeed score.
Because if you optimize the loading time of your website, you will automatically work on many of the areas that are important for Google. Improving the loading time and the Google PageSpeed score are therefore linked to a certain extent.
In my opinion, however, you shouldn't lose yourself in the hunt for a 100 rating.
But now to the optimization steps!
Error message 1: Compress CSS
In our experience, this is one of the most off-putting error messages from Google PageSpeed Insights.
Meaning: This error message indicates that the CSS files of your website can still be compressed (or, in the case above, that this has already been done successfully). Such a reduction reduces the number of characters in the documents. This reduces the file size. Comments, spaces and formatting, for example, are deleted.
Implementation: Even if this may seem daunting, the implementation is very simple. In this case, there are basically two possible solutions: If you are proficient in CSS, you can manually reduce the number of CSS files and use a shorthand notation when creating them. You can also reduce the CSS files yourself using online tools such as the CSS Minifier.
Of course, there is also the convenient solution of using CSS minification plugins in WordPress. Some plugins do an all-round job and can compress and optimize not only CSS, but also JavaScript and HTML.
Further information
You can find a detailed explanation of the ways in which you can reduce HTML, CSS and JavaScript in WordPress in this article.
With HTTP/2, merging CSS does not necessarily make sense
The Minify plugins just mentioned are widely used. This is because they are convenient and handle the compression and merging of CSS (and much more) fully automatically. Combining CSS files also made a lot of sense until recently. This has now changed: since the HTTP/2 standard was introduced, browsers are able to load several files from the web server at the same time.
This means that the data no longer necessarily has to be combined, as several data packets can be exchanged simultaneously with HTTP/2. HTTP/2 must have been set up by the hoster, for example, and can only be used with an SSL certificate.
So before you decide on a plugin with several dozen functions and configuration options, think carefully about whether you need it at all. Especially if you are confident that you can optimize CSS yourself.
This is because an additional plugin can make your website slower under certain circumstances. Especially if the other functions of the all-rounder plugins cannot develop their full potential.
Error message 2: Remove resources that are blocking rendering
This message also causes many people to break out in a sweat, as it is not so easy to implement and is also one of Google PageSpeed's eternal points of criticism.
Meaning: A website is set up in a specific order. This loading sequence can be optimized. PageSpeed almost always complains that CSS files block this optimal loading order. This also applies to websites that are already very well optimized(as the case of Caspar Hübinger shows). Nevertheless, the hint can be very valuable for load time optimization. In principle, this hint tells you that JavaScript or CSS code that is important for an element to be loaded - for example a background color - is not yet available at the time the element is loaded. As a result, it will not be displayed until the corresponding CSS command has been loaded. Although this does not increase the loading time of your website, it does affect the user experience, as the website feels like it takes longer to load.
Implementation: A common solution is to implement a rule of thumb: CSS in the header. This means that you move CSS code from the main part of the HTML document, the "body", to the beginning of the document, the "head", and integrate it there as "style".
This example makes it clear what I mean. The code snippet below defines a background color for a blog. The "style" element is loaded in the "head" of the HTML document. This way, the page background does not load at the end of the document and create an unsightly color jump or even block rendering.
<head>
<style type="text/css" id="custom-background-css">
body.custom-background { background-color: #f5faff; }
</style>
</head>
You can implement this optimization measure in two ways: You can touch the code yourself and move the CSS codes into the header, or you can let a plugin do the work.
The Autoptimize plugin, for example, takes an all-round approach: You select the options for all CSS files that are not excluded from the process.
The excerpt from the plugin options shows: Even the plugin variant cannot be implemented without a basic understanding of the process. So you also need to familiarize yourself with the plugins.
"*" indicates required fields
Error message 3: Coding images efficiently
PageSpeed Insights also often complains about this point. However, this case is almost always quick and easy to implement and usually brings tangible loading time benefits.
Significance: Many people underestimate the role of image size for the loading time of their website. Yet images are very often one of the biggest brakes on loading time. Even if only small amounts of data are saved with individual images, the total volume saved can add up to a considerable amount of data.
Because an image is rarely just one image. WordPress automatically generates several thumbnails of the image when it is uploaded. So if you don't use the originals on your homepage, but smaller versions of them, i.e. thumbnails or featured images, then these should of course also be optimized. One image quickly becomes several files, which also result in a multiple data load.
Implementation: In principle, you have two options for optimizing your images. You can either optimize the images before uploading or after or during the upload. You can do the former using online or offline tools and the latter using WordPress image optimization plugins.
If you can reasonably integrate compression into your workflow, it makes sense to optimize the images before uploading them. There are online tools for this, such as Kraken.io, or you can reduce the quality and therefore the file size of your images offline, for example directly in Photoshop. This saves you the extra plugin and keeps your website lean.
The more convenient solution here is of course a plugin. Plugins such as Optimus or Smush not only optimize the main image, but also all variations of it. Smush is also able to subsequently optimize all your existing images.
Among other things, the plugins work with so-called "lossless compression". This means that although the file size of the images is reduced, their visible quality is not diminished.
Error message 4: Activate text compression
This error message from Google PageSpeed can be fixed very quickly and can significantly reduce the loading time of your website.
Meaning: You have already reduced the size of your website's images and CSS as much as possible. That's good! But that's not all. Because now you can use another compression mechanism. You probably know this process from downloading large data packages: You usually have these in zipped, i.e. compressed, form. This makes the data smaller and the download faster. However, the data packages still have to be unzipped after downloading. Exactly the same thing happens when a page is loaded: The web server delivers the data packets in compressed form and the web server unpacks them. This makes the data transfer faster and reduces the page loading time.
Implementation: Either the data compression is already set on the server side, or you have to activate it yourself. With Raidboxes you don't have to worry about anything. Because we have the particularly strong Brotli compression active by default.
With the following entry in your .htaccess you can also activate the so-called GZIP compression manually. Provided you have an Apache web server.
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>
Error message 5: Provide static content with an efficient cache policy
In my opinion, the reference to browser caching is by far the most annoying in Google PageSpeed Insights. This is because you can only set up browser caching for your own resources. Browser caching is not possible for external resources.
Meaning: Browser caching means that the browser saves a static version of your website and no longer has to request it from the web server on a repeat visit, as the website is already loaded.
Implementation: Either your host has already activated browser caching on the server side, or you can set it by manipulating the .htaccess file (don't forget: this setting only works on Apache web servers). The example code below, for example, sets the browser cache to one month, i.e. the static version of your website is stored in the visitor's browser for one month.
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 60 seconds"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
</IfModule>
The same applies here: If you are a Raidboxes customer, browser caching is already active by default.
My 2 Cents: Everything is nothing without a cache
Good, now you've optimized the images on your website, reduced CSS, compressed it and put it in the right order, and got your visitors' browsers to cache the website. All these measures will shorten the loading time of your website.
Significance: Without a proper cache, however, you are wasting a lot of this potential. Caching is and remains by far the most important performance factor. A cache temporarily stores the content of your WordPress website and ensures that the entire website does not have to be reloaded every time. Instead, a static, i.e. already rendered version of your website is delivered from a cache. This bypasses the slow PHP and database in particular.
Implementation: Again, either your host has already set up a server-side cache or you are using a caching plugin. There are some very powerful plugins that cache large parts of your website and lead to a significant reduction in loading time for recurring website visits.
The high potency of caching plugins is also their greatest weakness. It is quite possible that a caching plugin will initially make your website slower for first-time visitors. This is because the more complicated your blog or website is, the more complicated and extensive the cache engine that caches your blog needs to be. This is particularly relevant for stores.
If you run a comparatively simple website, minimalist solutions can be better than caching all-rounders. One of these lean plugins is Cache Enabler, for example.
You should note that caching plugins usually also reduce and summarize CSS or JavaScript. You should therefore check whether your caching plugin makes the plugins for CSS optimization superfluous.
If you use server-side caching, it is advisable to deactivate the caching functions of plugins such as Autoptimize, or to test whether these bring any further performance benefits at all.
Conclusion: achieve a lot with just a few plugins
You've already noticed while reading this: there are plugins for optimizing CSS, images and the loading order that do a lot of the work for you. But not all of the work. Caching plugins also quickly deliver a noticeable effect, but are sometimes very extensive and offer many configuration options and sometimes redundant functions.
Be sure to take a closer look at the plugins you use. Only if you know what happens when you use certain functions can you optimize in a meaningful way. Overloading the website with optimization plugins tends to be of little use.
And you should make sure to measure your success correctly when optimizing. Regardless of whether you optimize manually or via a plugin. Use PageSpeed Insights as a first point of reference to identify the weak points of your website. Then measure the loading time of your website before optimization. Only after this initial assessment does it really make sense to optimize your website step by step. Because only if you know the loading time before optimization and after each optimization step can you determine what the individual optimization measures have achieved.
Hi Martin,
You're absolutely right that our website still needs a lot of optimization. Due to our website relaunch and our multilingual plugin, we unfortunately have some 404s and other errors that Google rightly rates poorly. But we are working on it 😁
VG from Münster
Leefke