Page cache
The VIP Platform’s page cache is the first level of caching that each request encounters for both WordPress and Node.js environments.
VIP’s global network of edge cache server locations serves a copy of the full page response generated by a site (usually from memory). Most of a site’s traffic can be served from the edge location closest to the user making the request, without ever hitting a line of PHP. This caching strategy provides low latency and very high site performance.
Insights into the page cache hit rate for HTTP requests that are made to an environment can be reviewed in the Insights & Metrics panel of the VIP Dashboard.
Default cache responses
For WordPress and Node.js environments on the VIP Platform, the following responses are cached by default:
- Responses with an HTTP Status Code of
200 OK
, including WordPress posts, pages, archives, the home page, 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.
- These responses are sent with a response header of
- Redirects with a
301 Moved Permanently
HTTP status are cached for 30 minutes. - Responses with
302 Found
and307 Temporary Redirect
HTTP status are cached for 1 minute. - Responses with
404 Not Found
HTTP status are cached for 10 seconds. - Responses with
410 Gone
HTTP status are cached for 1 minute. - HTTP status code responses that are not cached:
400 Bad Request
416 Range Not Satisfiable
429 Too Many Requests
431 Request Header Fields Too Large
500 Internal Server Error
502 Bad Gateway
504 Gateway Timeout
Note
Because the rendered HTML for a request is cached for up to 30 minutes, the references to updated static asset 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.
Cache bypass or prevention
WordPress and Node.js environments on the VIP Platform allow the following default cache bypass behaviors in the page cache:
- The presence of certain cookies will cause the page cache to be bypassed.
- All requests sent with an HTTP
Authorization
header will bypass the cache. - Requests made to WordPress environments by logged-in users bypass the page cache entirely.
- Logged-in users, commenters, requests to modify state (such as POST requests), and requests for pages not actively cached at the edge will be routed to the WordPress site’s origin servers, which run the site’s code and database.
no-cache
headers are respected vianocache_headers()
. However, useno-cache
headers cautiously as they will result in a poor cache hit rate.- By default, responses with
401 Unauthorized
and431 Request Header Fields Too Large
HTTP status codes are not cached. - All requests made to an environment with Basic Authentication enabled will bypass the cache.
Automatic cache clearing for WordPress content
Updating or publishing a WordPress page or a post of any kind (built-in post or custom post type) will clear the following caches by default in the page cache:
- 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 home page
- The page for posts (if it is set)
- The RSS feed
When a term is created, updated, or deleted in WordPress, 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 entire page cache of the WordPress site.
All WordPress REST API responses are cached for 1 minute.
Customizing cache clearing behavior
The VIP Cache API can be leveraged to customize cache clearing behavior for WordPress and Node.js applications. Customization options include:
- Automatically purging the cache for a url or a custom API endpoint when a change is made in the WordPress Admin dashboard.
- Clearing the cache for a specific URL, post, or term.
- Filtering the URLs that are queued for cache clearance.
Understanding the cache behavior of a request
Using the developer tools in a browser, review more information about the cache behavior of a request in the following HTTP response headers:
- The
x-cache
HTTP response header provides the type of interaction the response had with the page cache. A value ofHIT
indicates that the response is from cache;MISS
indicates it is not from cache;PASS
indicates that cache was bypassed and the response is from the origin.GRACE
indicates that a stale cached response was served while the page cache fetches an updated response from the origin to serve to future requests. cache-control
displays themax-age
of the cache for this content.age
shows the age of any response which hit the cache.
Default behavior of some HTTP headers
- The
s-maxage
response directive is honored by the page cache. If aCache-Control
HTTP header contains ans-maxage
response directive, thes-maxage
value will take precedence overmax-age
. - A unique ID value is assigned to every incoming request to the edge and stored in the
X-Request-Id
HTTP header. This value is recorded and retrievable in the HTTP Request Log Shippingrequest_id
field for an environment. In PHP the HTTP header request ID value is retrievable with:$_SERVER['HTTP_X_REQUEST_ID']
- By design, incoming requests to the origin that use the HTTP
HEAD
method are transformed intoGET
requests by the page cache. As a result, the value of$_SERVER['REQUEST_METHOD']
for those requests will beGET
. For this reason, avoid logic at the origin that depends on detectingHEAD
requests. - Responses are automatically segmented into User-Agent class buckets:
desktop
,smart
,tablet
, anddumb
.
Last updated: January 29, 2024