Our Cloud’s CDN is a global network of edge cache servers, each used to store content closest to an end user. If appropriate, origin servers may serve as an edge server for sites hosted in another location.

Each edge data center has a load balancer that accepts the request and then determines if it needs to route the traffic to the origin data center or, if edge cache is enabled, serve the content directly from the edge. If an uncached request is made, edge servers connect the user directly to our origin servers as needed, reducing hops.

Edge Cache Benefits

Edge Cache provides performance improvements, especially in regards to a site’s Time to First Byte (TTFB), by serving page and static cache directly from the closest server available to a site’s visitors. This cache is served from WP Cloud’s four origin data centers, and over 24 edge data centers, giving sites a total of 27 Point of Presence (PoP) locations that are continuously expanding.

• Improved performance: Edge Cache can significantly improve the performance of a site by reducing the distance that requests have to travel. This can lead to faster page load times and improved TTFB, which can improve user experience, reduce bounce rates, and improve a site’s Core Web Vitals.
• Reduced resource utilization: Edge Cache can also reduce the load on a site’s origin server. Requests that are cached on our edge servers do not need to be fetched from a site’s origin server. This can help to improve the overall performance of your site and reduce resource utilization.
• Increased availability: Edge Cache can also increase the availability of a site via graceful failover. Requests can be served from the edge servers even if a site is experiencing an issue. This can help to ensure that your site is available to users, even with issues such as plugin and theme conflicts.
• Compatibility: Like Batcache, Edge Cache is compatible with dynamic requests that follow WordPress’ best practices, ensuring cached pages are not served when an uncached response is necessary. This includes compatibility with eCommerce solutions such as WooCommerce and ensures that checkout flows and cart requests are not cached.

Checking the Status of Edge Cache

After enabling Edge Cache, it can take time, and multiple site visits, for Edge Cache to built and be served.

You can monitor the status of Edge Cache by checking for the x-ac response header in your browser’s developer tools, via the shell command curl -LI https://your-example-domain/, and other methods.

Note that Batcache and Edge Cache will be disabled for your web browser’s session if you are currently logged into the backend, WP-Admin, of your site.

Here are some examples of these headers:

1234	x-ac: 3.vie _atomic_dca HITx-ac: 2.den _atomic_dfw BYPASSx-ac: 1.ewr _atomic_dca MISSx-ac: 1.atl _atomic_dca STALE

The value of the x-ac header can be HIT, STALE, EXPIRED, UPDATING, MISS, or BYPASS.

• HIT: The page was served from Edge Cache.
• STALE: Stale and expired cache detected. Using stale while revalidate functionality serves what can be served from cache while fresh cache is built and served on subsequent requests.
• EXPIRED: Response found in the cache but has passed the cache TTL. The response is returned then the item is removed from the cache.
• UPDATING: A request is currently updating the cached asset from the site’s origin server via a held lock to prevent multiple ‘misses’ for the same request.
• MISS: There was not an Edge Cache hit. This may be due to something disabling or preventing Batcache from working. Or, the page may not have had enough recent visits to populate the cache on the specific edge server the visitor connected to.
• BYPASS: Edge Cache is not enabled OR the request is being made by an administrator logged into the site’s WP-Admin.

If the x-ac header’s value is HIT, STALE, EXPIRED, UPDATING, or MISS, this indicates that Edge Cache is enabled.

If the header shows BYPASS, this means that Edge Cache is disabled or the request is being made by an administrator logged into the site’s WP-Admin.