Caching is the trade off of real-time updates for speed and efficiency.
It’s helpful to visualize the common definition of the word cache: a collection of items stored for future use. Then apply it to your website, where little bits of necessary code/data can be stored for reuse, rather than calling upon the entire system to generate them again.
The average host of the average website project will likely have default cache settings that serve the general purpose.
But it is helpful to understand how caching affects website performance from a macro level, as well as when you may need to use specific settings.
The two types of caching that affect websites are called server side and client side. In this guide we’ll focus on the server side settings that will deliver optimal functionality to your users.
Client side caching, on the other hand, relates to the user’s web browser. We’ll leave that aside for now. And for the purposes of clarity, we will not be discussing plugins.
Pure server setup only.
The Beautiful Simplicity Of Server Side Caching
Let’s get melodramatic for a minute:
You are racing against the clock every time someone clicks on a link to visit your client’s website. And this can mean real money is on the line — nobody is going to buy the product if they bounce off page, and that ad budget is going to get mighty expensive for the low conversions.
True, maybe the stakes aren’t quite so high for each of your clients.
But why not pursue an ideal, especially when it is systematic and reasonably low cost/low effort?
Enter caching.
A server side cache creates a static version of your WordPress data that can be served to clients.
It’s standard practice to cache data that is repeatedly used to avoid making calls to your database each time this information is required. This can mean the results of a common search, or the entire pages of a site so they don’t have to be generated for every single person that comes in the door.
Your server recognizes “hey, I just served this page/content/info to someone else”, and will serve the same thing to the next person that comes in the door. It saves subsequent visitors time, and saves your server resources.
Layers Of Server-Side Caching
So what gets cached?
Media files, stylesheets, scripts, content, html documents, and API calls to external systems should all be cached.
Most designers and agencies don’t need to worry too much about this (in terms of setting it up or tweaking it). It’s just good to have a general idea of how a host manages caching.
If something is resource-heavy then it’s the ideal candidate for caching on the server. You’re better off having it ready to serve to the next person that pulls up the site.
There are several layers of server-side caching to be aware of:
Database Cache
Saves the results of the database in order to return the results faster the next time.
Object Cache
A caching class that saves a copy of complex queries and stores results in a database table.
Bytecode/Opcode Cache
Saves the result of PHP code compilation to bytecode, instead of compiling on every new request.
Page Cache
Saves a static HTML version of a page instead of querying the database. Can circumvent all the above caches.
CDN Cache
Stores website files on a proxy server, where they can be quickly accessed by users from a nearby location. Functionally similar to the page cache, but geographically distributed.
For the purposes of your average WordPress site, we recommend not worrying about much beyond the Page Cache.
To get an idea of how a request (to view a page) might travel through the various layers, check out this flow:
CDN/Page Cache > Application Server > Bytecode Cache > Database/Object Cache
When a request comes in, the front side cache (CDN or Page) looks at the request variables and says “can I serve something from the cache for this, or is the Time To Load expired?”
If the time has expired, then it looks to the Application Server. The App Server then says “I need to execute such and such PHP code… but is this code already compiled?”, and for that it looks in the Bytecode Cache.
If the code is not compiled, it has to do that. But it may need something from the database, so then it looks in the Object and Database cache to see if that code is already saved, and if not it must run the full course of all layers.
It sounds worse than it is; for most queries that go beyond the Page cache, it will take longer to read the explanation above than it will for your website to return a result.
WordPress Caching Without A Plugin
There are many ways to customize the server-side caching in WordPress without using a plugin.
Here are a few:
TTL Settings
The TTL is basically saying “has it been longer than this since I last checked the DNS records?”
If so, it will query the database for fresh information.
This is one very simple way for a host to optimize for websites with vastly different traffic.
In general, a low TTL setting is great for sites with extremely high traffic (but this of course involves a higher query load).
A high TTL setting is great for sites with low traffic (aka the vast majority of the web).
Apache/Nginx Headers
This allows developers to tweak HTTP caching. It can affect both the client requests and the server responses.
Apache and Nginx are two popular web servers. Apache used to be the most commonly used, but it is losing ground and the Nginx market share is growing.
It’s beyond the scope of this article, but if you want to read more then check out this post for a comparison between the two:
https://www.hostingadvice.com/how-to/nginx-vs-apache/
Content Delivery Network
Content gets saved to several servers around the world. Whenever a user makes a request to view the content, it is served from the server located closest to them.
There is a lot of hoopla around using a CDN (or a plugin that utilizes a CDN) to save a few precious nanoseconds of load time. However, it is overkill for a website that serves a specific location (eg. a local business), since the vast majority of users will be from one area only.
Automatic Cache Management And The Dynamic Debate
Server-side caching is not the catch-all answer.
Consider a website with data that is always changing, and the client needs the most current information. Updated status indicators, social sites, forums, etc.
Providing cached data is going to interfere with the primary purpose of these types of sites.
Although it may save you resources in making calls to a database, it won’t win you any fans from your visitors. If your visitor has their own shopping cart or profile, for instance, you generally shouldn’t cache that info.
In short, the more dynamic your website and the more unique the data that is being served, the less server side caching can be used.
Each site and each use case is different, and will always depend on the content (and its frequency) being served.
You could cache certain elements of a page (object caching), and serve dynamic content on other parts of the page. Or, if certain pages don’t change frequently (or ever), you could use full-page caching to serve that page up blazingly fast.
This is interesting in theory, but if you’re using robust managed WordPress hosting (like WidePath), you don’t usually have to fiddle with any of the elements we’ve mentioned in this article. We take care of it for you and use settings that make sense for most visitors.
But if your site gets a lot of traffic or has highly dynamic content, you will need to examine some of the elements we’ve mentioned above.he entire process will fail and you won't be able to get any certificate at all. So make sure you correct all the red X problems before you click 'Generate Certificate'.