Google Pagespeed and WordPress

28. April 2015 - wordpress

Pagespeed (PS) doesn’t need to be explained. It’s a metaphor for: If you’re too slow, you won’t show up (at least in Googles search results for mobile surfers). But how complicated and time consuming is it to get a high PS score? In the past days I had the chance to fiddle around with a fairly new, simple, and pretty unimportant website of a friend of mine. It’s a classic WordPress site with header and footer and plugins and Google fonts.

Apart from that it’s responsive, thanks to the YAML framework, mobile friendly according to Google webmaster tools, and it gains 100/100 user experience from PS.

And 50/100 for the rest. Google says, 85/100 is high-performance. Why not reach for high-performance?

Looking for plugins

That’s the classical WordPress approach. Leave the website as it is and find a good plugin. However, I had a very confusing experience with plugins. When PS complained about missing server caching, nonexistent data compression and absent minification of resources, I tried out several plugins. Some simply didn’t work or showed an odd behavior: The first PS session rocketed the site to 80, the subsequent sessions degraded it to my well known 50 points from 100 or even below.

Compression and caching by the provider

Caching plugins make significant changes to your htaccess file, which made me feel uncomfortable. Hence, I stopped using caching plugins, followed the recommendations of my provider, and came up with this htaccess solution:

# BEGIN strato
# Caching einrichten
FileETag MTime Size
ExpiresActive OnExpiresDefault "access plus 1 months"
ExpiresByType text/css "access plus 1 months"
ExpiresByType application/javascript "access plus 1 months"
ExpiresByType application/x-javascript "access plus 1 months"
ExpiresByType image/gif "access plus 1 months"
ExpiresByType image/jpeg "access plus 1 months"
ExpiresByType image/jpg "access plus 1 months"
ExpiresByType image/png "access plus 1 months"
ExpiresByType image/x-icon "access plus 1 months"
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
# END strato

Retrospectively, this htaccess modification should be your last step to optimize your website for PS, because you always have to undo them after the subsequent changes to see the effect.

This step improved my score: 57 points from 100

Render-blocking javascript and css

This PS section listed all my css files and all my js files as render-blocking. I started with the css. Typically, a YAML css is like the following style.css:

@import url("http://fonts.googleapis.com/css?family=Droid+Serif");
@import url("http://fonts.googleapis.com/css?family=Droid+Sans:700");
/* framework core */
@import url(yaml/core/base.css);
/* screen layout */
@import url("css/hlist.css");
@import url("css/gray-theme.css");
..

All the css @imports were replaced by the original css files, and in a second step by their minified versions, which PS offers to download. The two font @imports were combined into one and then replaced by a link in the site’s header:

<link href='http://fonts.googleapis.com/css?family=Droid+Serif|Droid+Sans:700' rel='stylesheet' type='text/css'/>

The result: 61 Points, four remaining render-blocking css files (style.css, google fonts, and two others, which came with one of my ajax based contact-form plugins) As I didn’t want to give up this plugin, I decided that the css optimization was good enough now.

Remaining: The javascript.

On my test website, I had jQuery and a lot of jQuery-UI scripts included with a plugin. First, I put all of them in the footer of the site, however, I didn’t get a better score. Then I used the wp-deferred-javascripts plugin. This eliminated all the “render-blocking javascripts” messages but didn’t improve the score, too.

Use images with higher compression

In terms of image compression, PS gives preference to its own compression standards. Therefore, I replaced nearly all images by the compressed samples from the PS download. In my opinion, these images are a bit too much compressed. Anyhow, my result was now 72 from 100 points. That should do for this website.

Conclusion

To achieve a 72 score cost me more than a workday. That means for me: recalculate the price-tags for a “simple” website. And what happens, if a customer wants a higher score? Then I would have to analyze the website in more detail and restructure css and js to speed up the rendering of the above-the-fold parts; all of which I skipped in this case. The good news is: Google accepts that the internet too has only limited resources. We should pay more attention to our css and images and the way our sites are rendered. And is it really necessary to pile up a stack of javascript only to just show a neat jQuery-UI dialogbox with a contact form?