JoysSite StuffTechy

Testing Out WordPress Caching Plugins

Speed optimisation is a focus at work for the company sites, but it’s not something I’ve spent that much time on for this site.

When better than a sleepy weekend morning to crack out the caching plugins for WordPress and have a bash!

Yesterday I installed W3 Total Cache and managed to break my site shortly after, by fiddling about with files due to a couple of error messages that were present.

However, this morning, I’ve had a bit more luck. I also decided to test a combination of WP Super Cache and DB Cache Reloaded Fix as someone suggested they were worthwhile. I’ve run some speed tests via webpagetest.org with location set to London, speed DSL and 5 tests of first view only.

Standard site (before caching plugins installed): load time 6.4 seconds, first byte 0.9 seconds, requests 19 (stats).

W3 Total Cache installed: load time 4.3 seconds, first byte 0.5 seconds, requests 12 (stats).

WP Super Cache/DB Cache Reloaded Fix installed: load time: 6.4 seconds, first byte 0.6 seconds, requests 19 (stats).

Setup

I warmed the cache before all tests by ensuring that the homepage was visited from a clean browser.

W3 Total Cache

Slightly more complex than Super Cache. Other than default, I checked:

Page Cache: Enable, Disk: Enhanced
Minify: Enable, Auto, Disk
Database Cache: Enable, Disk
Object Cache: Enable, Disk
Browser Cache: Enable, Disk
Miscellaneous: Optimize disk enhanced page and minify caching for NFS (as my server uses a network based file system)
Page Cache General: Cache home page, Cache requests only for domain.com hostname, Don’t cache pages for logged in users.
Browser Cache General: Set expires header, set cache control header, set entity tag (eTag).

WP Super Cache

Pretty much default config settings. On the easy settings page, the following options were checked:

Turn on caching
Use PHP to serve cache files.
Compress pages so they’re served more quickly to visitors.
Don’t cache pages for known users.
Cache rebuild. Serve a supercache file to anonymous users while a new file is being generated.
Mobile devide support.
Extra homepage checks.

DB Cache Reloaded Fix

Check the enable box and it’s good to go.

Disabling Plugins

Looking over the waterfall of assets of the speed test with W3 enabled, it’s fairly apparent that a couple of calls to Google APIs/js are causing a fair bit of delay. I have a plugin for Google Analytics, and another for social sharing links, both of which make calls to Google APIs or js files. Disabling both plugins gives the following result.

W3 Total Cache with Google plugins disabled: load time 3.1 seconds, first byte 0.5 seconds, requests 7 (stats).

This is significantly quicker than with these plugins enabled, so as a site owner, you need to decide whether tracking and social sharing is worth the extra delay.

CloudFlare

I’ve just set up CloudFlare for the site, but need to wait for the change of name servers to propagate before testing. Will update in due course.

Conclusions

I’m no performance expert, but by installing W3 Total Cache, I’ve reduced my load time by about 30% on a rudimentary test. It’s definitely noticeably quicker from my browser, and the only downside I’ve found so far is that my header images no longer rotate. They are different per page, but are set when they are first cached.

My server is US based and I was running the tests from London, so using a CDN (which W3 supports) would almost certainly help.

However, a significant performance gain of another ~30% was achieved by disabling plugins which make calls to external APIs and js files, but requires a greater sacrifice.

Leave a Reply

Your email address will not be published. Required fields are marked *