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

By default, all requests made with HEAD or GET HTTP request methods are cached.

The following responses are cached by default for WordPress and Node.js environments:

• Responses with an HTTP Status Code of 200 OK, including WordPress posts, pages, archives, the home page, /graphql, etc., are cached at the edge cache server locations for 30 minutes by default.
  • For browser cache control purposes these responses are sent with a cache-control HTTP response header of max-age=300, must-revalidate by default.
  • Changes made to WordPress site content will automatically notify the edge caches of the new data and trigger a purge of cached versions of that content. The next incoming request for that content will be sent to origin and the response will be served then stored in cache.
  • A stale response could be served by the page cache up to 12 hours for a cached object outside of a resource’s set max-age while the page cache fetches an updated response from the origin to serve for future requests.
• Redirects with a 301 Moved Permanently HTTP status are cached for 30 minutes.
• Responses with 302 Found and 307 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.
• All WordPress REST API responses are cached for 1 minute via code in the mu-plugins.

HTTP status code responses that are not cached

The following responses are not cached by default for WordPress and Node.js environments:

• 206 Partial Content
• 400 Bad Request
• 416 Range Not Satisfiable
• 429 Too Many Requests
• 431 Request Header Fields Too Large
• All 5xx responses

Cache bypass or prevention

The following types of requests made to a WordPress and Node.js environment will bypass the page cache by default:

• All requests sent with an HTTP Authorization header.
• All requests made with POST, PUT, or DELETE HTTP request methods.
• All requests made to an environment with Basic Authentication enabled.
• All requests made to WordPress environments by logged-in users.
• All requests made by a user with a PHP session.

Additional cache bypass behavior:

• The presence of certain cookies will cause the page cache to be bypassed.
• no-cache headers are respected via nocache_headers(). However, use no-cache headers cautiously as they will result in a poor cache hit rate.
• Responses with 401 Unauthorized and  431 Request Header Fields Too Large HTTP status codes are not cached.

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.

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.

Customizing cache clearing behavior

Custom NGINX rules cannot be added to modify cache clearing behavior for a WordPress or Node.js application. Instead, the VIP Cache API should be leveraged to customize cache clearing behavior.

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.

x-cache HTTP response headers

The x-cache HTTP response header provides information about the type of interaction that a response had with the page cache. Browser developer tools can be used to identify the x-cache HTTP response header for a specific request.

x-cache HTTP response headers that are returned by the page cache:

REVALIDATED indicates that the cache revalidated content with if-modified-since or if-none-match and the origin responded with a 304 Not Modified HTTP status.

HIT indicates that the response is from cache.

MISS indicates that the requested content was not found in cache and the response is from origin.

BYPASS indicates that cache was bypassed and the response is from the origin.

EXPIRED indicates that the cache has expired. Fresh content was fetched from the origin and served to the client.

STALE indicates that a stale cached response was served while the page cache fetches an updated response from the origin to serve to future requests.

UPDATING indicates that the cache is still in the process of updating stale content with a response from origin.

Default behavior of some HTTP headers

• The s-maxage response directive is honored by the page cache. If a Cache-Control HTTP header contains an s-maxage response directive, the s-maxage value will take precedence over max-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 Shipping request_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 into GET requests by the page cache. As a result, the value of $_SERVER['REQUEST_METHOD'] for those requests will be GET. For this reason, avoid logic at the origin that depends on detecting HEAD requests.
• Responses are automatically segmented into User-Agent class buckets: desktop, smart, tablet, and dumb.