Before officially establishing the Web Performance Lab, we did some early performance optimizations of LoadStorm.com. One of those was to install a WordPress plugin called W3 Total Cache (W3TC), which is a plugin designed to enable all kinds of server-side and client-side caching. Two of the features we enabled are types of server caching, and they were “page caching” and “cache preload”.

Page caching allows for web pages to be stored in the server’s RAM for faster access times. Cache preloading pre-fills the server cache using an XML sitemap and periodically loads pages into it automatically. For more information regarding web performance optimization caching strategies, we have provided detailed instruction on various forms of caching.

Both features were enabled during the benchmark tests. In order to test how much those two features boosted performance, we’d need to turn them back off again. So this may seem backwards, but we needed to proceed with the experiment from existing state of our site. By turning the caching off, we will see the decrease in performance. If all goes as expected, the load times we get from these tests should be slower than the benchmark since we are disabling optimizations.

How To Implement

If you’ve installed W3TC into your WordPress site, you probably already have these enabled. To enable or disable page caching or cache preloading through W3TC, it’s simply a matter of flipping a couple of switches on the WordPress dashboard.

You can find detailed instructions on how to enable page caching and cache preload from W3TC in this article or this video.

Results

First let’s look at disabling page caching altogether.

Page Caching On/Off

With page caching enabled (on the benchmark), we can see that total load time dropped by 46%, nearly cutting it in half. Instead of loading pages from disk memory, the server is loading them from its internal cache on RAM, making retrieval times much faster.

Okay, now let’s look at what disabling cache preload does…

Cache Preload On/Off

Umm…well that was interesting. Disabling cache preload actually reduced load time by 14%. We expected Cache Preload to have a positive effect on performance, but it had the opposite result. It’s still unclear why this happened.

Cache preload only affects the very first person to access the page. Doing multiple tests back to back (like we did) without emptying the cache in-between should give similar results to not having cache preload enabled at all. If page caching already has all of the pages in memory, then cache preload wouldn’t have any additional resources to put in memory; thus, no improvement and no decrease on performance.

Since W3TC requires page caching to be enabled in order for cache preload to work, they must not have a complementary effect. Perhaps there is a coding conflict that introduces additional overhead in processing cache preload – enough to reduce performance by 14%. Perhaps cache preload kept putting the wrong pages into the cache since it refreshes the page cache every 900 seconds. (We were only accessing 3 pages out of the hundreds on our website.)

After hours of research on the W3TC plug-in, I still have no answers to this unexpected outcome. No one else has documented cache preload causing lower performance.

Bottom Line

Undeniably, having W3 Total Cache installed on our website tremendously improved performance. Out of all the optimizations we tested for this first project, enabling page caching clearly had the greatest impact on performance. W3TC Page Caching cut the load times in half. Put another way, it doubled the site’s speed for delivering pages.

Enabling cache preload, however, seemingly had a negative impact on performance. We will be following up on this with a better setup later on. More work for the Web Performance Lab – more data for us to analyze.

Facebooktwitterredditpinterestlinkedinmail