I put a site together over the course of a long weekend to test a variety of new tools and as I wanted to get a better understanding of Nginx, W3 Cache and WordPress. How they worked together and as a little testing ground to see the on page search engine optimisations and speed improvements that went with testing and tweaking these three together. As opposed to relying on Cloudflare Apache and W3 Total Cache
I also wanted to test the speed improvements of hosting all image files off-site in a AWS S3 bucket and prevent the hot linking of these resources by spammers. Whilst I did accomplish this, I was disappointed and surprised to find that it increased page load time. Perhaps using the AWS CDN and not just the S3 buckets might improve this but due to time constraints, I did not test this.
A little bit ironically, given my above statement about spammers, I did create all of the posts using a great tool called WP All Import which allows you to import a large amount of data directly into WordPress without worrying about corrupting database tables. But more on that a bit later.
The site is hosted on a Digital Ocean droplet located in Singapore. I have found these virtual private servers to be very reliable and easy to work with. Although other companies have equally good reputations and the process could be further simplified by using a service such as ServerPilot. You get great bang for your buck and in a matter of minutes you can deploy a LAMP stack or whatever you want to test and just as easily destroy the build and start again.
As mentioned above, the main aim of this little project was just to test several different technologies working together and to see just what are the benefits of deploying sites on Nginx. I also wanted to become more familiar with Amazon Web Services and in particular the S3 buckets. I am aware that you can host html sites on S3. If I have time, I would also like to test AWS CloudFront as an alternative to Cloudflare. But as this is a short search engine optimisation project on an otherwise rainy Dublin City weekend, I suspect this will have to wait.
Cloudflare is great but I often get a really long TTFB, or ‘time to first byte’, when using it. According to them in this blog post it’s not something to worry about but I wonder if that’s true. This is an argument that has been raging for some time and here is the original post that sparked my interest in it a few years ago.
The photos were mostly taken in Dublin over the last number of years. There may be a few from some other parts of Ireland. The post titles were auto generated using a bit of python and three sentence structures. There are only 4 pieces of long form content on the site, three category pages for each major city and this page. No more content is planned. Although I do plan to schedule out another 75 photo posts over the next year.
The site is now offline but I was pleased at the insights gained from the little project.
All of the images have been geo-tagged with co-ordinates from Dublin city and been marked up with some additional meta data. At this point, I did not give the images alt tags as the aim is not to rank for anything but to make the site relevant to Ireland and to a particular area.
I have not done anything to force the indexing of the site. A couple of page submissions to Google Webmasters Tools to get the crawlers in. I used the Google Schema Validator to check the sites schema. I did include more services for pinging when a new post is published. The list can be copy and pasted from below and inserted into WordPress via Settings -> Writing -> “Update Service”
All the posts, use the underlying WP theme for cross linking within their silo. I used simple logic to create a last 5 posts widget. This widget is not visible to the user by default but is very clear to googlebot. The silos are based on the 3 main cities in Ireland. The tags feature of the theme kills this by interlinking categories via tag and not does not limit the linked resource by category.
The main aim of this site was to see how much Nginx and various caching options would speed up the page load time. But I also wanted to become more familiar with WP Import All as it would be useful in a range of different future projects.
WP Import All is a WordPress plugin that presents itself as a magical tool that can import and map data into your site in a range of ways. I have only played with importing CSV and XML files but it does these pretty well with a few caveats.
Csv files use standard UTF-8 encoding and any foreign characters that are copied or saved into the CSV file will cause the import to fail. There is no indication of this in the log file and this issue caused me some head scratching.
The second issue arises when trying to map a your imported data to a custom field created with advanced custom fields or ,I suspect, any hard coded fields. Out of the box the program doesn’t allow this. A work around for this was loading in a plugin which works with the custom fields in a different way.
I wanted to build the site using the BuSo Lighting theme from buildersociety.com but due to time constraints, this will have to wait. After taking a quick look at what was available, I choose a theme called Moon which is reasonably lightweight. One of the main points of this test is to improve the site speed so, were I to use the buildersociety’s theme, it might be difficult to improve on their optimizations.
I recently spent some time working with a very popular theme called BeTheme which by all accounts is very beautiful but the issue is that the time it takes to remove all the bloat and @import linked CSS files from it, could be spent taking a bare bones theme and skinning it to what you want.
I tried to keep the install as light as possible. I added Table of Contents Plus which only loads on this page, Simple 301s to help creating the silo structure, Yoast SEO and a security plugin. In addition to this I added the required plugins to make WordPress play nice with Amazon S3 as you can see below.
I installed the following plugins.
I set up an AWS S3 bucket with a similar label to the domain name and configured a ‘user’ with the required rights to access and altered the bucket contents as suggested by the Delicious Brains team. This was all very simple but I avoided activating the plugin until later as I wanted to see the improvements alongside the other tweaks.
There are a range of different services to help test your website speed and to test your site under heavy use. Most of the linked services have a free plan in their service. Whilst this website was tested using all the services. I won’t include screenshots from them all. I prefer the way the information is presented by webpagetest.org and this is sufficient.
Image compression should be the first thing you look at when optimizing a site for speed. All image files should be edited to the correct size before being uploaded to your site. Most people use Photoshop and it’s export for web function. But their compression just does not cut it anymore. And you can see further gains from using kraken.io.
I won’t go over the differences between the different services as Matt Cromwell did a great job a little while back. Just to mention that the caveat with Kraken is that WordPress generates various thumbnails for use on different pages and on different devices. All these images must be optimized too. In my tests Kraken consistently beat the other services in terms of size vs quality compression but it’s a paid service and it’s not worth it for this little project.
As mentioned in Matt Cromwell’s post a free alternative is ewww which can be run once or set-up on a cron job. One other viable option is Yahoo’s old WP-smush-it plugin which has undergone a recent upgrade that allows it to work with much larger files.
There is no point in loading all the content until the user actually needs it. With lazy loading you defer loading large image files or other media until the user gets to it. With WordPress there are numerous options to choose from.
Here is one;
Rocket LL is an extremely light weight plugin that only loads images as the user gets to them, thus saving server bandwidth and increasing pageload time.
There are plugins and scripts that allow you to selectively load plugins/widgets per page but that would be overkill for this little test.
Stop Losing Customers to Your CompetitionStart
CSS render blocking happens when your CSS files don’t load concurrently. Numerous WordPress themes are built to appeal to a wide variety of people and not built for fast loading times. The stylesheets are often chained together so that one CSS file will launch others by using an @import call.
These should be removed and your style sheets should be combined into one for faster rendering times. I have minified and removed the CSS render blocking from this theme but it was pretty clean anyway.
You can of course minify the code too and I am using W3 Total Cache for this.
I inserted the following into my functions.php file to remove a useless jscript feature for emojis that was introduced in WP 4.2
This offers a slight improvement in speed.
remove_action( ‘wp_head’, ‘print_emoji_detection_script’, 7 );remove_action( ‘wp_print_styles’, ‘print_emoji_styles’ );
The site is hosted on a Digital Ocean ‘droplet’ and uses an open source Cpanel alternative that runs Nginx in proxy mode to Apache.
I switched Nginx of for the initial tests and whilst the name servers used are Cloudfront. There is no caching happening.
Whilst I don’t think this will speed the site up it is good practice. This small change does improve the site pagespeed score. Sometimes public proxies serve the wrong type of header. This small server side change allows proxies to cache both compressed and regular versions of the resource.
Numerous posts have been written about the best settings for but the majority of these are for Apache and not Nginx. It’s a good idea to remember that the simpler your setup is the better. Nginx takes care of a lot of things and outside of installing Memcache the default settings are pretty good.
I did not install Memcache on this box so I am using Disk Caching as the default.
After some testing these are the settings that have given the best return.
John Dugan did a good job over here of how to reference W3’s auto-generated config file. So I won’t go over it again.
I was slightly disappointed that I could get the initial page view below 2 seconds. Hosting images on the AWS S3 buckets in fact increased load time by about half a second. As I mentioned earlier, perhaps using the AWS CDN would alleviate this but I did not have the time and will perhaps revisit this in the future.
This is the default Blazemaster stress with 20 UVs for 15 mins. The server responded admirably.
The second loader.io test simulated 100 users per second over 1 minute which is the same as about 860,000 page views per day.
The first test was much less intense and fired 15 users/requests at the site per second. Initial response time was disappointing here and warrants a bit of investigation.
There is a marked improvement when using Nginx in conjunction with W3 Total Cache and CloudFlare. For most people it will not be worth the setup time and configuration. The difference between a basic setup with CloudFlare and ‘out of the box’ W3 total cache settings is good enough for most sites.
Whilst this was very interesting for me and I learnt quite a lot about Nginx in the process, I can’t say that I would recommend others take a the same amount of time and test a different/complex set-up.
Does Google prefer faster sites? Yes.
Is this a feasible option for small business owners? No.
Will you see a difference in rankings due to having a faster site? Yes, but…
…that same time could be used improving other areas of a site to see the same improvement.
The decision wholly depends on the size of your site, the number of pages you are serving to users per day and your goals.