This post is the ninth in a series called “Pagely Answers”, which seeks to provide in-depth answers to questions that are hard to handle with a simple FAQ.
We cache HTML content wherever possible because it’s an order of magnitude fast (500ms vs 10ms) and a couple orders of magnitude more scalable (50 concurrent users verus 100k). We only cache GET requests. We don’t cache any requests that set a cookie. We know about standard WordPress cookies and don’t cache them if you are logged in, or have a WooCommerce item in your cart as an example.
Caching works by building a cache key, every request that matches that key gets the same page, so if you are using information not in that key to change your output then it will not work properly. On VPS plans and above we can create custom cache keys and rules for you. The cache key is HTTP or HTTPS, domain, request URI, and normalized user agent (mobile, desktop, tablet, or RSS bot).
As an example of how we don’t cache requests that set a cookie:
We remove utm_* attributes from the query string when building cache keys. So running an AdWords campaign doesn’t hurt performance.
In terms of purging, when you update a page or post in WordPress, our plugin makes a request to the cache servers asking them to purge that page, the homepage of the site, and /feed/* as well. The way cache purging works is that there can be a delay on that purging.
NOTE: The key takeaway here and something that gets misunderstood a lot is that if the proper information isn’t present in the cache key (but is present somewhere else) then you will not get the results you want. You must put the proper information in the cache key to change your output. If you need custom cache keys and rules created then we are happy to do so for VPS and above.