Skip to content

How-to Guides

Technical References

Caching /

Page cache

The first level of caching each request encounters is the Page Cache, powered by Varnish. On Go, this is a copy of the full page response that was generated by your site, and is served from our global network of edge locations (usually from memory). Often, this means that the majority of your site’s traffic can be served directly from the edge location closest to your visitors, without ever hitting a line of PHP, which means low-latency and very high performance.

Unchanged pages will remain in the edge cache for up to 30 minutes – but 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 VIP Go page cache behaves as follows:

  • Logged in users bypass the VIP Go page cache entirely
  • No-cache headers are respected, but should only be used after consulting VIP, use nocache_headers()
  • 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)

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.

Pro 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 minutes (more about the WordPress REST API)

Using the developer tools in your browser you can likely see some detail about your cache behaviour 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 ( eg.: /hello-world?a=1&b=1 as well as /hello-world?b=1&a=1 ) purged along with the main post.

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

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

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 geo-targetting your site content.

Last updated: November 19, 2020