Cache-control headers
The cache-control
HTTP header provides an instructional value for controlling the caching of requests and responses in an end-user’s browser.
Default cache-control
response header values set by VIP’s page cache:
cache-control: max-age=300, must-revalidate
(5 minutes) for most responses with an HTTP Status Code of200
.cache-control: max-age=31536000
(1 year) for static asset files.-
cache-control: private, no-store
for resources that have VIP Cache personalization enabled. cache-control: no-cache, must-revalidate, max-age=0, no-store
when a request has bypassed the cache (X-Cache: BYPASS
) and the response is from the origin.
Limitations
The value of the cache-control
response header for a resource cannot be set to a custom value for:
- Files that are stored in the VIP File System.
- Responses with status codes
301
,302
,307
,404
, or410
.
Best practices
Caution
Do not set max-age
to less than 1 minute for heavily trafficked resource types.
- Routes for site endpoints that rarely change should be set to a higher
max-age
value, which can improve the cache hit rate. - There is no upper limit to the value set for
max-age
, but increasing this value is only beneficial within a limited range. By default, cached page content is evicted from the cache according to themax-age
TTL and theSTALE
response, which is set to 12 hours for content that is unable to be refreshed. - The page cache also relies on a Least Recently Used (LRU) strategy which will apply if the page cache is low in memory. As a result, setting
max-age
to a value beyond a certain range (e.g. > 24 hours) can result in content that is requested less often to occupy valuable space in the page cache, which can lead to more frequent page cache evictions.
Modify the cache-control
response header value
In most cases, the cache-control
header value for WordPress and Node.js applications can be set to custom response directives, including:
max-age
s-maxage
no-cache
no-store
private
stale-while-revalidate
On VIP, the private
, no-cache
, and no-store
directives have identical behavior and simply bypass the VIP edge cache.
The max-age
or s-maxage
response header values can be modified in order to customize the duration of caching for static assets that are served by the origin application web server. If a cache-control
HTTP header is set to a s-maxage
response directive, the s-maxage
value will take precedence over max-age
.
In this WordPress code example, max-age
is set to a custom value for feeds. Note that the example includes an is_user_logged_in()
check. This ensures that the cache Time To Live (TTL) headers are not set for logged-in users, as this would trigger browser caching for them.
add_action( 'wp', 'my_cache_maxage' );
/**
* Hooks the wp action to insert some cache control
* max-age headers.
*
* @param Object wp The WP object, passed by reference
* @return void
*/
function my_cache_maxage( $wp ) {
if ( is_feed() ) {
// Set the max age for feeds to 10 minutes.
if ( ! is_user_logged_in() ) {
header( 'Cache-Control: max-age=' . ( 10 * MINUTE_IN_SECONDS ) );
}
}
}
In this Node.js code example, max-age
is set to a custom value for an Express.js route.
const express = require( 'express' );
const app = express();
app.get( '/', function ( req, res ) {
res
.set( 'cache-control', 'max-age=3600' )
.send( 'This response will be cached for 1 hour (3600 seconds)' );
});
Last updated: September 17, 2024