Skip to content

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 of 200.
  • 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, or 410

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 the max-age TTL and the STALE 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:

  • maxage
  • 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: June 26, 2024

Relevant to

  • Node.js
  • WordPress