Edge cache

The Content Delivery Network (CDN) cache stores full copies of HTML pages as well as static resources at multiple geographically distributed servers. When a user requests a page, the CDN serves the content from the closest server, thereby reducing latency and improving load times.

Crucially, requests captured by the Edge cache (or CDN cache) do not hit the origin instance, in this case, the WordPress instance. This feature of edge caching is highly effective in minimizing the impact of traffic spikes, as it significantly reduces the load on the origin server. Given this caching behavior, it is important for developers to create websites that do not expose dynamic data that changes in short time periods or differs for various visitors. Instead, these dynamic elements should be loaded asynchronously through AJAX calls, which by definition are not cached by the CDN. This approach enables the website to maintain dynamic functionality while still benefiting from the performance enhancements of CDN caching. By storing content closer to users, CDNs provide faster response times and lower bandwidth consumption. This design, combined with smart development practices for dynamic content, can lead to significantly improved website performance and user experience.

Edge caching strategy is designed to differentiate two primary group of assets: website resources and media library.

• Website resources – the group contains caching rules for full pages, as well as static JavaScript and CSS files exposed by backend and frontend frameworks, its plugins, and themes.
• Media library – the uploaded assets group focuses on all assets uploaded through the WordPress media library, which are exposed under the wp-content/uploads directory.

Cache time to live

WordPress caching rules ensure content is efficiently stored and delivered. By default, full pages are stored at the edge for 1 hours and for 1 hours in the browser. Although browser cache cannot be invalidated, our system, will invalidate existing cache at the edge in the event of deployment or content changes. This ensures that users are served the most up-to-date content without compromising performance. Static assets delivered by WordPress, its plugins and themes are cached for 365 days. By default, WordPress automatically handles versions of its dependencies using ver parameter.

Files uploaded by WordPress administrators and editors are cached for 365 days in both the edge and browser layers. To maintain cache efficiency and ensure the latest assets are served, these files should be versioned using a unique parameter or by changing the filename. In other words, it is suggested to re-upload a file to a library rather update its contents.

Full page cache can be disabled in the environment Cache settings. Static assets and media cache are enforced.

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. Explanation of Cache-Control rules can be find in Mozilla Developer Center.

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 exclusions

In some cases, the Edge cache is bypassed, which is required for the correct functioning of the website. Following cases won't be cached:

• The request is a method other than GET.
• The response has a status of 206 Partial Content.
• The response contains the header Vary: *.

Below is a list of excluded paths:

List of excluded requests: