Like every other blogging and CMS platform out there, WordPress can consume a lot of resources. It reads from and writes to a disk, uses some memory (PHP) and reads and writes from a database. If you don’t use anything to cache database objects or web pages, it can get pretty slow depending on how many and what plugins you install. If you’re on shared hosting, you probably can’t do anything outside of what some WordPress plugins will allow you to do.
Regardless of what you’re capable of doing, you should test the results with a website like WebPageTest every step of the way. To be fair to yourself, you should take into account any external advertising services you’re using, like Google AdSense.
Cache WordPress Objects
In July of 2013, I wrote “The MySQL Query Cache is Unnecessary with WordPress Websites“. Of course, I qualified that statement. However… if you use something like my W3 Total Cache Primer using only a full-page caching plugin, you could end up consuming more resources than you would otherwise expect.
WordPress uses non-persistent database object caching (see Class Reference/WP Object Cache) by default. It only stores that data during each page load. It saves on database calls, but only for the current page. To store the data persistently, for multiple pages, you need a persistent object caching application. W3 Total Cache includes it, but you can use a separate plugin if you wish. I’m using the XCache Object Cache Backend plugin and it works very well.
If you’re on shared hosting, object caching probably isn’t available. You can use database caching instead and it will save on database calls, but it’s unlikely to speed anything up. Either way, the data is being pulled from disk and not from memory.
What I did was to have it combine and cache only the files in the head, ignoring the files after the content. What I ended up with was two external files in the head. Some older browsers only fetch two resources in parallel and most only fetch up to four. Fewer HTTP requests will obviously speed up page loads.
Cache with a Content Delivery Network (CDN)
It makes no sense to use a CDN until you start getting a lot of web traffic and I’m not talking about web robots (usually just called “bots”). If you use a statistics plugin that shows page loads by humans only, you should be able to tell when that happens. A CDN takes care of static assets and can lower latency in some areas, but it really depends on where your server is located. This is another option that probably isn’t available with shared hosting.
There are services like CloudFlare and Incapsula which do a bit more than just deliver content, but that doesn’t mean you should use them. If you’re making money with your website, a service like MaxCDN is very affordable. I’m not using a CDN at all now and I still get good page load speeds from most places in the United States (my target audience).
Cache Full Pages
You can use almost any full-page caching plugin, but my W3 Total Cache Primer will only work with W3 Total Cache’s page enhanced mode (because the file names match the slugs). I’m sure it could be modified to work with any full-page caching plugin if you can find out how the cache files are saved and do the proper conversions.
I’m not going to tell you which one is the best, at least not now. It’s something you need to research and test on your own. WordPress checks for “advanced-cache.php” on every non-cached page load (in wp-settings.php), so you have enough information to create your own if what already exists doesn’t do what you want it to do.
Control what Web Browsers Cache
Controlling what web browsers cache can be done by setting the expires headers with the web server. W3 Total Cache includes that ability. I’m not aware of any other WordPress plugin that does.
If you have access to your web server’s configuration files, you can do it manually. If the headers are set properly, the web server will send a status code instead of resources. This alone can make a WordPress website seem faster and more responsive when a visitor moves from page to page (but only after the first page view).
My Own Test Results
I’m running with Google AdSense ads being displayed, so my website isn’t as fast as it could be. The first view on a 700-word article averages 2.5 seconds and the repeat view averages 1.3 seconds. It starts rendering, however, in less than a second for both views. I guarantee you no one reads that fast.
Could it be faster? Yes, slightly. Does it really matter? For some place like Amazon or eBay, sure, but not on a website like mine.
Fast page load speed is a side effect of efficient caching and minimizing things that visitors don’t care about, at least on a dynamic platform like WordPress.