Default page cache responses

By default, the following responses are cached by the VIP page cache 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.
  • 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.
  • 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 responses to unauthenticated, non-error, read (GET / HEAD) requests to the WordPress REST API are cached for 1 minute. The TTL Manager plugin in VIP MU plugins sets the 1 minute caching rule for the WP REST API endpoint.

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
• 403 Forbidden
• 416 Range Not Satisfiable
• 429 Too Many Requests
• 431 Request Header Fields Too Large
• All 5xx responses

Uncacheable URLs

A URL will be marked as uncacheable for 10 seconds if:

• it has a TTL less than or equal to 0 AND a response status code less than 500
• OR it has a Set-Cookie header (set with setcookie() )
• OR it has a Cache-Control header with a private value
• OR it has a Vary header with a value of *.

Cache bypass

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

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