Edge Cache

Pressable provides Edge Cache across all plans, a free performance feature that allows your WordPress sites to leverage our global network of edge servers to deliver page and static asset cache.

Benefits of Edge Cache

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

• Improved performance: Edge Cache can significantly improve the performance of your 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 your site’s Core Web Vitals.
• Reduced resource utilization: Edge Cache can also reduce the load on your site’s origin server. Requests that are cached on our edge servers do not need to be fetched from your 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 your site via graceful failover. Requests can be served from the edge servers even if your site is experiencing an issue. This can help to ensure that your site is available to users, even while 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.

One important point to note is that traffic that hits a site’s Edge Cache is not currently recorded in the standard web server logs.

Enabling and Disabling Edge Cache

Enabling & Disabling via the MyPressable Control Panel

To enable Edge Cache on your site, visit the MyPressable Control Panel and Settings for a specific site. From there, click on the Performance tab and locate the Edge Cache section:

Enabling & Disabling via the WP Admin

Edge Cache can now also be enabled/disabled directly from the WP Admin of a Pressable site, under Settings > Edge Cache:

Purging / Flushing Edge Cache

Currently, Edge Cache is automatically flushed on a site when the following actions are taken:

• Post Status Change: Published, Unpublished, Edited
• Comment Status Change: Added, Approved, Unapproved, Deleted, Marked as Spam
• Attachment Deleted
• Theme Switched
• Changes saved in Theme Customizer
• Editing Site Templates in the Block Editor

At this time, Edge Cache is purged for the entire site, not just the page/post, etc. that triggered a matching action.

You can view more by inspecting the code here: /srv/wordpress/mu-plugins/edge-cache/edge-cache.php

Clearing via the MyPressable Control Panel

To purge, or flush, Edge Cache, visit the MyPressable Control Panel and access Settings for a specific site. From there, click on the Performance tab and locate the Edge Cache section.

Clicking the Purge Edge Cache button will clear the current cache from our edge servers. Note that performance will be affected while cache rebuilds and it is recommended to use this tool sparingly.

Clearing via the WP Admin

Edge Cache can now also be cleared directly from the WP Admin of a Pressable site, under Settings > Edge Cache:

How Edge Cache Works with Batcache Page Caching

Pressable leverages Batcache for general page caching. The Edge Cache respects the Batcache Time To Live (TTL) configuration. Therefore, extending the Batcache cache will result in the Edge Cache serving cached content for longer periods. However, it’s essential to note that each edge server operates independently. This means that different locations may have different caches.

Assets Stored by Edge Cache

Edge Cache stores both full page caches and a wide variety of static assets to ensure faster delivery. Static assets cached at the edge include:

• CSS files (.css)
• JavaScript files (.js)
• Images:
  • JPEG (.jpg, .jpeg)
  • PNG (.png)
  • GIF (.gif)
  • WebP (.webp)
  • AVIF (.avif)
  • SVG (.svg)
• Fonts:
  • EOT (.eot)
  • TTF (.ttf)
  • WOFF / WOFF2 (.woff, .woff2)
  • OTF (.otf)
• Video and Audio:
  • MP3 (.mp3)
  • MP4 (.mp4)
  • WebM (.webm)
  • MOV (.mov)
• PDF documents (.pdf)
• Special optimised assets:
  • PageOptimize minified static content (/_static/)
  • Jetpack Boost minified static content (/_jb_static/)

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.

Here are some examples of these headers:

x-ac: 3.vie _atomic_dca HIT x-ac: 2.den _atomic_dfw BYPASS x-ac: 1.ewr _atomic_dca MISS x-ac: 1.atl _atomic_dfw 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.

Common Caching Issues

Configurations or issues that disable or break Batcache will also affect Edge Caching.

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.

The following are examples that will prevent optimal caching or may break caching altogether.

Cookies

Certain plugins may attempt to set cookies on each page load, especially those that leverage server-side cookies. This will prevent Batcache and Edge Cache from storing and serving cache.

• PHPSESSID server-side cookie AKA the “session cookie”, leverages PHP to store session IDs on the server side. Initiated via the session_start() function.
• Other set-cookie implementations that attempt to set a cookie on every request. Initiated via the setcookie() function.
• Cookies that begin with wp_ or wordpress_ will also break caching.

Custom Cache Headers

Plugins and custom code may attempt to modify cache response headers. The following examples, when set, will prevent caching.

• pragma: no-cache
• cache-control: no-cache
• cache-control: max-age=0

Other Functions & Snippets

The following are additional examples of code that can prevent Batcache and Edge Cache from working as expected.

• batcache_cancel()
• $batcache->max_age = 0;
• $batcache['max_age'] = 0;
• session_start()
• nocache
• nocache_headers()
• x-cache
• wp_cache_flush()

Pressable API & Managing Sites in Bulk

The Edge Cache controls are also available via the Pressable API and can be used to enable, disable, and purge sites in bulk or via a custom control panel.

Defensive Mode

While the Pressable platform provides DDoS mitigations, Edge Cache’s Defensive Mode offers an additional on-demand layer of protection.

Utilizing proof-of-work, Defensive mode issues a challenge to browsers visiting the site, mitigating spam bot and DDoS attack requests. Legitimate users will briefly see a challenge page while their browser completes the work before accessing the site.

To use Defensive mode, Edge Cache must first be enabled on the site. Time supports minutes, hours, and days with a minimum of 30 minutes and a maximum of 7 days. When enabled on a site, site visitors will see this:

Enabling Defensive Mode via My.Pressable.com Dashboard

Edge Cache Defensive Mode can be enabled in the My.Pressable.com Dashboard within the individual site’s settings by going to Sites > Select Site > Performance:

We provide different time periods for enablement as dropdown options. When selected and enabled, you’ll see a message showing how long Defensive Mode is enabled until, along with the ability to disable it.

Here’s an example:

Enabling Defensive Mode via WP-CLI

Defensive Mode can also be enabled via WP-CLI:

wp edge-cache defensive_mode --time=<time>

Examples:

• Enable for 35 minutes: wp edge-cache defensive_mode --time=35m
• Enable for 2 hours: wp edge-cache defensive_mode --time=2h
• Enable for 3 days: wp edge-cache defensive_mode --time=3d

Enabling Defensive Mode via API

Defensive Mode can be enabled via the API. There is also an associated webhook.

More on Caching at Pressable

For more information about caching and Pressable.com’s specific caching strategies, please refer to the following documentation:

• Modifying Cache Times with Batcache
• How Does Batcache Page Caching Work?
• Caching Types Available at Pressable

---

Frequently Asked Questions

Will there be an additional charge for Edge Cache functionality?

Pressable’s Edge Cache feature is free and included with all Pressable plans.

Does Edge Cache replace other Pressable caching?

Edge Cache works alongside Pressable’s other layers of caching, but also replaces the need for the Legacy CDN. Since Edge Cache serves both static assets and full pages directly from our global edge servers, the same infrastructure as a CDN, it effectively performs the role of a CDN while extending page caching to the edge. On well-cached sites, this usually eliminates the need for any additional CDN. Using a third-party CDN on top of Edge Cache (including Jetpack CDN or others) can actually add unnecessary external HTTP requests and reduce performance. For that reason, we recommend relying on Edge Cache alone unless you have tested thoroughly and confirmed no performance decrease.

Why can’t I see edge-cached requests in my web server logs?

Traffic that is served from our edge servers is not currently logged in the standard web server logs.

How can I extend how long Edge Cache is stored and served?

Edge Cache respects your site’s Batcache page caching Time To Live (TTL) configuration. Extending the Batcache cache will result in the Edge Cache serving cached content for longer periods.

Why aren’t my pages being served by cache?

If you are logged out of your site and believe Edge Cache isn’t working, this may indicate that a plugin or code snippet is leveraging cookies, cache headers, or other functions that are preventing the page(s) from being cached.

Or, it could mean that there haven’t been enough visits to the specific page to have it stored in the cache.

If issues persist, it may be necessary to perform an audit of the active plugins, check for code snippets, and explore a conflict test.