Page cache

The first level of caching each request encounters is the Page Cache, powered by Varnish. 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 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 302, 307, 404, 410, 431, 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.

• 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:

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