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.
The page cache will return Grace responses under certain circumstances to ensure that cached resources are served promptly.
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 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.
- 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
400 Bad Request
HTTP status are cached for 2 minutes. - Responses with
404 Not Found
HTTP status are cached for 10 seconds. - Responses with
410 Gone
HTTP status are cached for 1 minute - Responses with
500 Internal Server Error
,502 Bad Gateway
, and504 Gateway Timeout
HTTP status are cached for 15 seconds. - All WordPress REST API responses are cached for 1 minute.
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.
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
. - 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
.
Automatic cache clearing
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 homepage
- The page for posts
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.
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
orhit
indicates that the response is from cache;MISS
ormiss
indicates it is not from cache;PASS
orpass
indicates that cache was bypassed and the response is from the origin.GRACE
, orgrace
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.
Last updated: August 03, 2023