Page cache

The VIP Platform’s page cache is powered by Varnish and is the first level of caching that each request encounters on both WordPress environments and Node.js environments.

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.

Requests that are cached

Default caching behavior for WordPress environments and Node.js environments on the VIP Platform:

• By default, 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 site content will automatically notify the edge caches of the new data and trigger a refresh, which means the site content is never stale.

• Redirects with a 302 HTTP status are cached for 1 minute.
• Redirects with a 301 HTTP status are cached for 30 minutes.
• Responses with 307 and 410 HTTP status are cached for 1 minute.
• Responses with 404 HTTP status are cached for 10 seconds.
• Enqueued JS and CSS files are concatenated by VIP and cached for 15 days. This cache is busted when resource versions are updated.
• Non-enqueued static assets are cached for up to 1 year, including JS, CSS, images, and other media files (e.g., .manifest, .xml, .webm, .webp, .svg, .ico). Use caution when referencing these assets directly and consider implementing custom cache-busting query strings to avoid issues.
• All WordPress REST API responses are cached for 1 minute.
• Other responses are cached for 1 minute or less.
• 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

Default cache bypass behavior for WordPress environments and Node.js environments on the VIP Platform:

• Responses with 431 and >=500 HTTP status bypass cache.
• The page cache will be bypassed by the presence of certain cookies.
• All requests sent with an HTTP Authorization header will bypass cache.
• Requests to WordPress environments made by users logged in to that environment 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 a WordPress site’s origin servers, which are running the site’s code and database.
• no-cache headers are respected via nocache_headers(). The use of no-cache headers will result in a poor cache hit rate and should be used with caution.

Requests that use the HTTP HEAD method

By design, incoming requests to origin that use the HTTP HEAD method are transformed into GET requests by Varnish. As a result, the value of $_SERVER['REQUEST_METHOD'] for those requests will be GET. For this reason, logic at origin that depends on detecting HEAD requests should be avoided.

Automatic clearing

When a page or a post of any kind (built-in post or custom post type) is published or updated, 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.