Tiny WordPress Insights

Full Page Caching Options for WP Blogs

Caching ecosystem around WordPress grows constantly with newer caching plugins coming up every year. In order to arrive at the best solution for caching, one needs to understand how everything fits together in a cache. There are multiple caching layers available. When a user sends a request to a particular page in a domain, for example home page of this domain, the reply doesn’t come fresh from the site. If it needs fresh data, it has to be prepared from scratch by this site. That in turn would take a lot of time to prepare and then send it to the user’s browser. The visitors would have closed the website and would have turned to another site, if the request doesn’t arrive within a second (in most cases). In order to achieve this 1-second milestone, the sites incorporate different caching layers to serve the request.

Broadly, there are two categories of caching…

Micro Cache

Let me give a quick introduction and examples of micro caching before explaining things with full page cache. Micro caching, as the name suggests, happens at some parts of the site / page.

Examples of Micro Caching

Gravatar Cache: This site uses a plugin to cache the gravatars that is being displayed besides every commenter on this blog.

Transients: While transients can be utilised in multiple ways, it is primarily used to reduce the number of calls to the database by caching some repeated queries (actually their results). In multiple sites, it is always used to reduce the API calls to a particular providers, such as Twitter. Most API calls have rate limiting. That’s why it is important to cache the result of an API call and then keep using it for some time before looking for the updated data.

There are multiple other areas where micro caching techniques can be utilised.

Full Page Caching

Full page caching can be done at various levels.

Network Level Full Page Caching

Fastly and Cloudflare are the best examples of having the full page caching at the network level even before a request reaches the actual server (called origin server) where a site resides. Both use their point of presence in multiple locations around the world. When a user requests a page of a site for the first time, the request goes to the actual server via Fastly or Cloudflare and then the request is served to the end-user. It may look unnecessary overhead. However, what happens after the first request is served is where the magic is. After the request is served, the PoP (Point of Presence) would cache the response in its own cache for a period determined by multiple methods. For example, if the origin server sends s-maxage cache header of 1 day, all subsequent requests to the same page would be answered by the PoP server for the next 24 hours, rather than the origin server.

Server Level Caching

Server level caching is done by the origin server, usually by the web server.

Of course, there are other options (such as Squid) that can be utilised as full page caching engines too. However, the above three are easy to implement and are some of the popular choices.

Application Level Caching

Don’t be fooled by the term, application. It is nothing but WordPress here. Within WordPress ecosystem, here are some of the popular full page caching engines…

I hope this has given you an idea about the full page caching solutions available for your site. Irrespective of what you choose, just choose anyone. Any of the above can make your site blazing fast. At least, it will solve the popular issue called Server Response Time.

Exit mobile version