Category Archives: Web Performance

WordPress and nginx infinite loop when using a reverse proxy

I have recently given my server setup a bit of an upgrade moving from an oldish version of lighttpd to nginx 1.6 compiled with the google pagespeed module. I wrote about the speed benefits in a seperate post.

When I was upgrading I had both servers setup side by side with nginx running on port 82 and setup a quick lighttpd reverse proxy from lighttpd to nginx so that I could keep all my sites up whilst experimenting with nginx config. When forwarding from lighttpd to nginx at a wordpress install it seemed to get itself into an infinite loop redirecting over and over to the homepage.  The problem could be tracked down to the redirect_canonical() function in wp-includes/canonical.php.

The check to see if we were on the canonical version of the url was failing and redirecting to itself.  I believe it was because the port in PHPs’ $_SERVER variable were different so the url did not match and WordPress would continue redirecting to the url forever. A quick fix was to remove the redirect_canonical filter with the following filter:

remove_filter('template_redirect', 'redirect_canonical');


The more permanent solution for me which may not be appropriate for everyone was to have all traffic go directly to nginx and remove the reverse proxy after I had finished testing other areas of the site. Using the filter above amy end up with you having multiple versions of the same page indexed by google if you have several versions of the same page setup for translations etc.

How to score 100/100 with google PageSpeed insights tool

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.

Bad mobile score 56 / 100
Bad mobile score 56 / 100

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.

Insights - new theme UX 93 / 100
Good mobile score 93 / 100

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. 97.5% desktop visitorsThe 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.


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 shows 23 requests, 636kb transfer and 3.26 seconds load time.

Slow firebug Net tab
Slow firebug Net tab

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

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.


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; deny all; }
location /ngx_pagespeed_global_statistics { allow; deny all; }
location /ngx_pagespeed_message { allow; deny all; }
location /pagespeed_console { allow; deny all; }
location /pagespeed_admin { allow; 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 "" "";

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 Screen Shot 2014-06-14 at 22.48.37

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.