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.

• 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 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, and 504 Gateway Timeout HTTP status are cached for 15 seconds.
• All WordPress REST API responses are cached for 1 minute.

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.

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.
• 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.

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 of HIT or hit indicates that the response is from cache; MISS or miss indicates it is not from cache; PASS or pass indicates that cache was bypassed and the response is from the origin. GRACE, or 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.