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:
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.
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:
Page Speed (Ranked separately for desktop and mobile)
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.
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
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
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.