A few days ago I came up with a few goals for this site as I have been a little lazy letting the content become fairly stale. I have preached many times to clients and people around of the importance of high quality content in modern SEO in 2014, so, I thought it was time to practice what I preach a little and see what kind of differences I could make to my own site. So as a software developer I thought the easiest problems to fix with this site first would be the technical performance. A good metric for measuring the technical performance of a site is googles PageSpeed Insights tool.  It takes multiple factors into account mostly around the two topics:

• User Experience
• Page Speed (Ranked separately for desktop and mobile)

User Experience

Before I started trying to improve my ranking I was using a wordpress theme that was a few years out of date. It wasn’t responsive so didn’t perform well on mobile at all.

So an easy first step was to update the design. I went with the default wordpress twenty fourteen theme as it performs well on all platforms.

Ok, so that was easy. It has some suggestions for increasing the tap areas on the category and tag links but as this is a free off the shelf wordpress theme I am not too interested in that (for the time being). Interestingly my google analytics stats showed that before I changed this theme my visitors were 97% desktop and the remaining 3% mobile / tablet. The main factor for this is undoubtedly that the content is mainly discovered my developers looking for WordPress plugins, but maybe I am being penalised by google for not having a mobile friendly site. I will keep an eye on these numbers in the coming months to see if they improve.

Speed

Next the trickier area of speed comes in to play.  The PageSpeed insights tool focuses on mostly front end speed improvements, such as removing removing render blocking javascript and optimising delivery of assets. This can be done in many ways such as minifying / inlining / combining assets so that the users browser makes as few requests as possible using the least amount of bandwidth.  A relatively small amount of weight is given to actual server response time. With the main focus on getting the user to a point they can browse your page in the quickest time possible.

Since January 1st 2014 the average page load time has been around 6.98 seconds (slow) and average page load time 2.70 seconds.  A quick first load test with firebug on the homepage of www.mattyl.co.uk shows 23 requests, 636kb transfer and 3.26 seconds load time.

The PageSpeed Insights tool didn’t score too much higher either with a mobile speed score of 64/100 

The problems

From a speed point of view there are many issues ranging from the modular nature of WordPress with each plugin adding more CSS or javascript requests to the head and the lazy nature in which I upload screenshots – not converting to jpeg or optimising etc. None of my css / javascript was compressed or combined + most of my javascript was not loaded asynchronously.

Solution

Rather than fixing all of these problems by modifying the websites core code I chose instead to use the PageSpeed Module for nginx. It is basically a set of filters that run at the web server level after your web backend has finished generating the markup. It will optimise the markup to web best practices as well as optomising the delivering of assets for bandwith savings and speed. For example it can rescale images to a size requested by the markup via height / width tags, preforming a lossless compression, delivering WEBP images to browsers that support them. It can also combine javascript files and make them non-blocking + minify. The main advantage being this is all a process that can run entirely separately from your development flow meaning you can still upload unminified css to you web server and not have to worry about manually combining files together for speed.

To Install I had to recompile nginx with the page speed module (Instructions here). There are filters for each of the different options and match fairly closely to the issues that the PageSpeed Insights tool will give you.  The complete list of filters are all documented but the config below is what worked for me to achieve a 100% speed ranking with the PageSpeed Insights tool. I added this config to a pagespeed.conf file and I include it for each virtualhost on my web server

pagespeed on;
# Needs to exist and be writable by nginx.
pagespeed FileCachePath /var/ngx_pagespeed_cache;

location ~ "^/pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }
location /ngx_pagespeed_statistics { allow 127.0.0.1; deny all; }
location /ngx_pagespeed_global_statistics { allow 127.0.0.1; deny all; }
location /ngx_pagespeed_message { allow 127.0.0.1; deny all; }
location /pagespeed_console { allow 127.0.0.1; deny all; }
location /pagespeed_admin { allow 127.0.0.1; deny all; }

# Ensure requests for pagespeed optimized resources go to the pagespeed handler
# and no extraneous headers get set.
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
add_header "" "";
}
h

#EXTRA NON-DEFAULT PAGE SPEED CONFIG
pagespeed EnableFilters combine_css,move_css_above_scripts,defer_javascript,lazyload_images;
pagespeed EnableFilters rewrite_images;
pagespeed EnableFilters prioritize_critical_css;

pagespeed EnableFilters rewrite_javascript;
pagespeed UseExperimentalJsMinifier on;
pagespeed EnableFilters inline_google_font_css;
pagespeed EnableFilters insert_dns_prefetch;
pagespeed EnableFilters combine_javascript;

The tool runs in the background so not every rule will be satisfied on the first page load with the new config turned on. Some processes such as the recompression of images and fetching / inlining of css scripts will only be served to the browser once the external process has completed. It would be a bit of an anti-pattern for a page speed module to make a request slower whilst it finishes its compression.

With all of those filters I was able to achieve a page speed rating of 100/100 for bot mobile and desktop 

The module runs as a cpu bounded process so it should not overload your server. This makes it not play terribly well with some caching tools as they can cache too early before the page or all assets has been fully optimised. There are experimental features for configuring a downstream cache with varnish but I have not yet implemented this.

Hopefully this will help if you are struggling to make sense of or make some of the improvements suggested by the the PageSpeed Insights tool. The nginx module certainly took a lot of the manual pain away fro me in reaching my speed goals. I will update in a few weeks time when I have more user data via google analytics if the changes have made a significant affect to real world users.