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 ofcache-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
and410
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 overmax-age
.- The page cache will return Grace responses under certain circumstances.
- Responses are automatically segmented into User-Agent class buckets:
desktop
,smart
,tablet
, anddumb
.
Note
Because the rendered HTML for a request is cached for up to 30 minutes, the references to updated JS and CSS files could be up to 30 minutes out of date. The version number on an enqueued asset must be updated to prompt VIP to use the new concatenated versions when JS or CSS has been edited.
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 vianocache_headers()
. The use ofno-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
), orgrace
.cache-control
shows themax-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.
Last updated: March 24, 2023