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?