Skip to content

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.
  • 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.
  • 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 via nocache_headers(). However, use no-cache headers cautiously as they will result in a poor cache hit rate.
  • By default, responses with 401 Unauthorized and  431 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 of HIT 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 the max-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 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.

Last updated: January 29, 2024

Relevant to

  • Node.js
  • WordPress