Skip to content

Backgrounds

How-to Guides

Technical References

Caching /

Page cache

VIP’s page cache is the first level of caching each request encounters, powered by Varnish. A copy of the full page response that was generated by a site is copied and is served from VIP’s global network of edge locations (usually from memory). This enables the majority of a site’s traffic to be served directly from the edge location closest to a the user making the request, without ever hitting a line of PHP. This provides low-latency and very high site performance.

Unchanged pages will remain in the edge cache for up to 30 minutes. Changes to the site content will automatically notify the edge caches of the new data and trigger a refresh, which means the site content is never stale.

Logged in visitors, commenters, requests to modify state (such as POST requests), and requests for pages that are not actively cached at the edge will be routed to the site’s origin servers, which are running your site’s code and database.

By default, your page cache behaves as follows:

  • Logged in users bypass the page cache entirely.
  • No-cache headers are respected via nocache_headers() with exceptions of status codes 302307404410431, and >=500. Note that using these headers will result in poor cache hit rate.
  • Responses with an HTTP Status Code of 200, including WordPress posts, pages, archives, the homepage, etc, are cached for 30 minutes; these responses are sent with a response header of cache-control: max-age=300, must-revalidate for browser cache control purposes.
  • Enqueued JS and CSS is concatenated by VIP Go and cached for 15 days (this cache is busted when resources change).
  • Other static assets, including non-enqueued JS and CSS, are cached for up to one year. Take care when referencing these assets directly and consider implementing your own cache busting query string to avoid issues.

Note

The HTML is cached for 30 minutes, so the references to the new JS/CSS files could be up to 30 minutes out of date.

Tip

Remember to change the version number on the enqueued asset when JS or CSS has been edited, to prompt VIP Go to use the new concatenated versions.

  • Other responses are cached for 1 minute or less.
  • Redirects with a 302 HTTP status are cached for 1 minute, redirects with a 301 HTTP status are cached for 30 minutes.
  • All WordPress REST API responses are cached for 1 minute (more about the WordPress REST API).

Using the developer tools in your browser you can likely see some detail about your cache behavior in the following HTTP response headers:

  • x-cache shows you whether the response was from cache (hit), not from cache (miss), bypassed the cache (pass), or grace (see below)
  • cache-control shows the max-age of the cache for this content
  • age shows the age of any response which hit the cache

The page cache considers the whole URL, including GET parameters (e.g. ?a=1&b=1 is different from ?b=1&a=1 and both are cached separately). When purging a URL, all variants of the GET parameters are purged at the same time. This means that a post with slug hello-world will have all variants (e.g., /hello-world?a=1&b=1 as well as /hello-world?b=1&a=1 ) purged along with the main post.

Additionally, a list of query parameters that are filtered at Varnish exists. This parameter list currently includes: hpt, eref, iref, fbid, fb_xd_bust, fb_xd_fragment, npt, iid, icid, ncid, snapid, _, fb_ref, fb_source, omcamp, affiliate, migAgencyId, migSource, migTrackDataExt, migRandom, gclid, migTrackFmtExt, linkId, _ga, hootPostID, pretty, gref, __lsa, ia_share_url, fbclid, mod, wsrlui.

In these scenarios, the specific query parameters and their values are ignored and the remaining URL is checked for in the page cache before potentially passing to the application at the origin.

For example:

  • www.example.com/?fbclid=100 is rewritten by Varnish as a request to www.example.com/ when searching for existing cached entries.
  • www.example.com/?hpt=foo&bar=baz is rewritten to www.example.com/?bar=baz.
  • Query strings with a value and no name, such as www.example.com/?=foo are also filtered to reflect www.example.com/.

Automatic Clearing

When a page or a post of any kind (built-in post or custom post type) is published, the following caches are cleared by default:

  • The single post/page URL
  • The comments feed URL for that post/page
  • The term archive URL for all terms associated with the post
  • The term archive feed URL for all terms associated with the post
  • The homepage
  • The page for posts

When a term is created, updated, or deleted, the following caches are cleared by default:

  • The term archive URL for all terms associated with the post
  • The term archive feed URL for all terms associated with the post

Switching a theme will purge the site’s entire cache.

Cache Control

Cache control can be written into your theme, plugin, or client MU plugin. We provide an API to filter the URLs being queued for clearance, to clear the cache for a specific URL, or for a post or term, see our documentation on the Cache API.

Page cache will also be bypassed by the presence of certain cookies.

The page cache will return Grace Responses under certain circumstances.

You may also be interested in geotargeting your site content.

Last updated: January 09, 2022