Origin cache

Origin caching stores a full copy of an HTML page at the origin server for a medium period of time. This cache serves as a fallback for the CDN cache, ensuring that if a requested page is not available in the CDN cache, the origin cache can quickly deliver the content. Origin caching reduces the load on the origin server by minimizing redundant requests, ultimately improving overall website performance.

The origin cache is specifically designed to handle traffic peaks and reduce short-period overloads on the origin server. By storing full copies of HTML pages at the origin server for a brief period, the origin cache can quickly deliver content to users during periods of high demand, easing the load on the server.

During traffic spikes, the origin cache serves as a crucial buffer between the origin server and the incoming requests. By caching content for a long period, the origin cache ensures that the server does not need to process redundant requests for the same resources, allowing it to handle higher traffic volumes more efficiently.

This caching strategy is particularly valuable for protecting server performance during sudden traffic surges, such as during a product launch or a viral content event. By leveraging origin caching to handle traffic peaks, we can maintain a high level of website performance and user experience, even during periods of intense demand.

The default caching behavior for origin cache is tailored to efficiently handle WordPress-generated pages that require PHP processing. By caching these dynamic HTML pages at the origin server for a 24-hours period with refresh after each content change, we strike a balance between maintaining up-to-date content and alleviating server load.

This caching strategy ensures that the origin server does not need to repeatedly process the same PHP requests for every user during the 24-hour window, improving server performance and reducing response times. At the same time, the relatively brief cache duration ensures that any changes made to the WordPress content will be reflected to users within a reasonable time frame.

By employing this default caching behavior for origin cache, we optimize the performance of WordPress-generated pages while maintaining a high level of content freshness for users.

Origin cache can be disabled in the environment Cache settings. Cache is automatically flushed after each change in the WordPress dashboard area.

Customizing cache behavior

The default CDN cache settings can be overridden by specifying custom Cache-Control headers in server responses. These give you more control over caching behavior for specific resources.

Cache-Control: public, max-age=86400

This header indicates that the resource is public and can be cached by both the browser and any intermediate caches (e.g., CDN). The max-age directive specifies that the resource is considered fresh for 86,400 seconds (24 hours) from the time it is requested. After this time, the cache will need to revalidate or fetch a new version of the resource.

Cache-Control: private, no-store, no-cache, must-revalidate

This header indicates that the resource is private and should not be stored in any shared cache (e.g., CDN). The no-store and no-cache directives instruct the browser not to store a cached version of the resource, while the must-revalidate directive requires the cache to validate the freshness of the resource with the server before serving it. This header is useful for sensitive or rapidly changing content that should not be cached.

Cache Control in action

The example below allows you to block caching in all levels for single book CPT posts.

/**
 * Cache `book` CTP single page on Edge.
 */
function sitebox_books_cache_rule(): void {
    if (\is_singular('book')) {
        // https://developer.wordpress.org/reference/functions/nocache_headers/
        \nocache_headers();
    }
}
\add_action('template_redirect', 'sitebox_books_cache_rule');

The example below allows you to block caching in all levels for single people CPT posts with dynamic category.

/**
 * Cache `people` CTP single page on Edge.
 */
function sitebox_people_cache_rule(): void {
    if (\is_singular('people') && \in_category('dynamic')) {
        \header('Cache-Control: private, no-store, no-cache, must-revalidate');
    }
}
\add_action('template_redirect', 'sitebox_people_cache_rule');

Cache busting

Cache busting is a technique used to force browsers and intermediate caches to fetch a new version of a resource, even if a cached version is still considered fresh. One common method of cache busting involves appending a unique parameter to the resource's URL, effectively changing its address and forcing the cache to retrieve the updated content.

By adding a URL parameter with a unique value, such as a version number or a timestamp, you can ensure that caches treat the resource as new and bypass the cached version. This approach is particularly useful for static assets like JavaScript and CSS files, which may have long cache durations but need to be updated when changes are made.

Example of cache busting

https://example.com/styles/main.css?ver=1.2.3

In this example, the version number (1.2.3) is appended as a URL parameter (?ver=1.2.3). When the file is updated, the version number can be incremented, forcing the cache to fetch the new version.

By using cache busting techniques like URL parameters, you can maintain control over resource updates, ensuring that users receive the latest content without compromising the performance benefits of caching.

Cache exclusions

In some cases, the Edge cache is bypassed, which is required for the correct functioning of the website.

Below is a list of excluded paths:

List of excluded requests: