Page cache

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

Default behavior

Requests that are cached

• Responses with an HTTP Status Code of 200, including WordPress posts, pages, archives, the homepage, etc, are cached at the edge cache server locations for up to 30 minutes. These responses are sent with a response header of cache-control: max-age=300, must-revalidate for browser cache control purposes. Changes made 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.
• Enqueued JS and CSS files are concatenated by VIP and cached for 15 days (this cache is busted when resource versions are updated).
• 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.
• All WordPress REST API responses are cached for 1 minute (more about the WordPress REST API).
• 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.
• s-maxage cache-control headers are honored by the page cache, and if present will take precedence over max-age.
• The page cache will return Grace responses under certain circumstances.
• Responses are automatically segmented into User-Agent class buckets: desktop, smart, tablet, and dumb.

Requests that bypass the cache

• Logged in users bypass the page cache entirely.
• Logged in users, 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 the site’s code and database.

• The page cache will be bypassed by the presence of certain cookies.
• no-cache headers are respected via nocache_headers() with exceptions of status codes 302, 307, 404, 410, 431, and >=500. Be aware that the use of no-cache headers will result in a poor cache hit rate.

Query parameters

The page cache considers the whole URL, including GET parameters (e.g. ?a=1&b=1 is different from ?b=1&a=1 and each variant is 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.

Review details about cache behavior

Using the developer tools in a browser, details about the cache behavior can be reviewed in the following HTTP response headers:

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

Cache control

VIP’s cache clearance API can be leveraged to:

• Set the maximum cache age
• Filter the URLs being queued for clearance
• Clear the cache for a specific URL, or for a post or term.