Your website’s visitors hate to wait for pages to load — on the desktop or on mobile devices. Pages that are slow to load can have them scurrying to a competitor’s site. You’re also worried about the impact of website performance on search results.

At Kinsta, we take speed seriously, and we’re always looking to make our customers’ sites faster.

The addition of Kinsta Edge Caching to our Managed WordPress Hosting plans in December of 2022 added new tools to help customers get their website pages to browsers faster.

Measuring time to first byte (TTFB), we saw an average response time across all testing of 207 milliseconds with edge caching enabled, versus 402.59 milliseconds without edge caching. That’s a drop of nearly 49%. But some of the real-world websites in our testing performed much better than that, with TTFB performances nearly 80% faster with edge caching. We’ll dig deeper into those numbers below.

Let’s take a look at how your WordPress website’s performance can improve when more of its content is “on the edge.”

What Is Edge Caching?

Edge caching combines traditional caching methods and edge computing infrastructure to store data as close to the user as possible. It’s a content delivery approach that reduces network latency by sending data from a data center or CDN closer to the user’s location.

Here’s a more advanced way to put it.

Many of our WordPress hosting customers are already taking advantage of our integration with Cloudflare and its edge servers through the Kinsta CDN. This content distribution network places a site’s static assets — like images, fonts, and files containing CSS and JavaScript — in 260+ locations on Cloudflare’s network around the world. That means those assets are available closer to the physical location of your website’s visitors. Shorter hauls for those assets result in lower latency.

But where does Edge Caching fit into all this?

Well, Edge Caching the HTML of WordPress pages is a lot like managing the assets in the CDN. A difference is that managing a cache of files like images — which rarely change — is relatively simple. It’s more difficult to manage content that is initially generated dynamically by WordPress, cached as static content, and then regenerated anytime content is edited.

How Does Content Get Cached on the Edge?

Edge caches are populated by requests for your site’s pages by browsers. If a page is not already cached, the request is passed to your origin WordPress site, where the page might be in the local cache or might be generated again by WordPress. The page is stored in the edge cache on the way back to the browser. Future requests on the same path will benefit from the cache until it is cleared.

This is also how mobile caches are populated. If the request for a page comes from a mobile device, the content is saved to a mobile cache. (The mobile cache does not distinguish between, say, iOS and Android devices. Requests from tablets are grouped with desktop content.)

WordPress Local Cache and Edge Cache

Kinsta provides a plugin-free approach to local WordPress caching on your site’s own server. Kinsta’s take on Edge Caching maintains that simplicity: the same steps you have been taking to clear your local cache will now also keep an edge cache in sync.

In addition, the MyKinsta dashboard includes functionality to clear the edge cache — and just the edge cache — directly.

New with Edge Caching is the ability to enable a cache for mobile devices. If your website generates unique markup for mobile devices, you can cache that HTML separately from content for desktop devices..

Is Kinsta Edge Caching the Same as Cloudflare’s APO?

Kinsta Edge Caching shares the same powerful network of edge servers used by Cloudflare’s Automatic Platform Optimization (APO) service. APO is also designed to deliver edge caching to WordPress sites.

Here’s what sets Kinsta Edge Caching apart:

  • No extra fees. (Edge Caching is free with all Managed WordPress Hosting plans).
  • No need for a cache-management plugin.
  • Seamless integration with the MyKinsta dashboard.
  • One platform to manage CDN and Edge Caching.

Putting Kinsta Edge Caching to the Test

Before officially releasing the feature, we invited some of our customers to try a Beta version of the new Edge Caching service to gather feedback. The real-world websites of our Beta testers around the globe provided the perfect environment for speed-testing the technology.

From the Google data center known as us-central1 in Council Bluffs, Iowa, our team’s automated tools polled the websites of the Beta testers and recorded response times for three caching scenarios:

  1. When a page was delivered from the cache of a Cloudflare edge server.
  2. When a page was not found on a Cloudflare edge server and was pulled from the “local” cache of the origin server.
  3. When there was no cached page at all and WordPress had to launch PHP scripts and fire off database queries to build the page dynamically.

The primary focus was the difference in response times for local and edge caches.

We measured response times in two ways:

  1. Time to first byte — the gap between a request for a page and the arrival of the first byte of data.
  2. Time to download an entire HTML page.

Measuring TTFB focuses on latency in the network between a web server and a browser since it’s largely independent of the amount of data transferred to complete a page. Timing the transfer of a full page is a useful measure that reflects the real-world task of delivering HTML to browsers.

Edge Caching by the Numbers

After hundreds of tests targeting WordPress sites in data centers around the world, we found that, on average, Kinsta Edge Caching reduced by more than 50% the time required to deliver full pages to browsers.

Take a look:

Chart showing improvements in TTFB and page-delivery speed thanks to Edge Caching.
TTFB: 402.59 ms (local cache), 207 ms (edge). Full page: 490.99 ms (local cache), 223.98 ms (edge).

Based on our tests, Edge Caching cut TTFB an average of nearly 48.6%, and the time to transfer complete pages dropped by almost 54.4%

Exceeding an 80% Improvement Over Long Distances

While the averages of all the speed testing were impressive, that view can hide important data — particularly for those who target a global audience.

Our testing found some dramatic performance improvements when Edge Caching narrowed the gap between browsers and more-distant origin servers.

For example, Edge Caching slashed TTFB by 83.6% and page-transfer times by 85.6% between our Iowa test location and Google’s asia-southeast1 data center in Singapore:

Chart showing Edge Caching performance for Jurong West data center.
TTFB: 672.01 ms (local cache), 110.05 ms (edge). Full page: 901.1 ms (local cache), 129.79 ms (edge).

Connecting to WordPress sites in the Sydney australia-southeast1 data center, TTFB fell by nearly 73.6%, and page-transfer times dropped by 77.3%.

Chart showing Edge Caching performance for Sydney data center.
TTFB: 898.26 ms (local cache), 237.21 ms (edge). Full page: 1,130.48 ms (local cache), 256.95 ms (edge).

We saw similar numbers out of the australia-southeast2 data center in Melbourne. The WordPress sites of Kinsta customers there saw Edge Caching trim TTFB an average of 77.8% and page transfer by nearly 82.7%:

Chart showing Edge Caching performance for Melbourne data center.
TTFB: 607.37 ms (local cache), 134.63 ms (edge). Full page: 812.46 ms (local cache), 140.62 ms (edge).

Connecting to sites hosted in the europe-north1 data center at Hamina, Finland, TTFB fell nearly 41.7%, and page-transfer times fell more than 56.3%.

Chart showing Edge Caching performance for the Hamina data center.
TTFB: 579.81 ms (local cache), 338.17 ms (edge). Full page: 822.21 ms (local cache), 358.89 ms (edge).

For sites hosted in St. Ghislain, Belgium, at the europe-west1 data center, TTFB and page-transfer times dropped 69%.

Chart showing Edge Caching performance for the Ghislain data center.
TTFB: 464.64 ms (local cache), 143.13 ms (edge). Full page: 464.92 ms (local cache), 143.38 ms (edge).

Websites tested at the europe-west2 data center in London, UK, showed TTFB dropping by 58%, and page-transfer times down 60.8%.

Chart showing Edge Caching performance for the London data center.
TTFB: 372.4 ms (local cache), 156.17 ms (edge). Full page: 458.18 ms (local cache), 179.34 ms (edge).

At the europe-west3 data center in Frankfurt, Germany, TTFB dropped almost 64% and page-transfer times fell 67.5%.

Chart showing Edge Caching performance for the Frankfurt data center.
TTFB: 409.27 ms (local cache), 147.42 ms (edge). Full page: 507.52 ms (local cache), 164.98 ms (edge).

Connecting to sites hosted in the europe-west4 data center at Eemshaven, Netherlands TTFB fell nearly 56%, and page-transfer times dropped 63.6%.

Chart showing Edge Caching performance for the Eemshaven data center.
TTFB: 394.49 ms (local cache), 173.76 ms (edge). Full page: 538.84 ms (local cache), 195.82 ms (edge).

During testing of sites at the northamerica-northeast1 data center in Montreal, Canada, TTFB dropped by just over 10%, and page-transfer times were down just over 16.2%.

Chart showing Edge Caching performance for the Montreal data center.
TTFB: 325.3 ms (local cache), 292.28 ms (edge). Full page: 351.1 ms (local cache), 294.15 ms (edge).

At the us-east5 data center in Columbus, Ohio, TTFB and page-transfer times were cut by almost 59%.

Chart showing Edge Caching performance for the Columbus data center.
TTFB: 326.69 ms (local cache), 133.97 ms (edge). Full page: 341.15 ms (local cache), 140.5 ms (edge).

At the us-west4 data center in Las Vegas, Nevada, in the US, TTFB dropped just over 54.7% and page-transfer time dropped almost 57.3%.

Chart showing Edge Caching performance for the Las Vegas data center.
TTFB: 366.73 ms (local cache), 165.88 ms (edge). Full page: 413.39 ms (local cache), 176.63 ms (edge).

But it’s not just Kinsta who is putting Edge Caching to the test.

Brian Jackson, co-founder of the forgemedia digital agency, timed TTFB and the complete rendering of WordPress pages in a browser after Edge Caching. He also looked at largest contentful paint (LCP), the point at which enough of a page’s main content has been rendered that a user might perceive it as useable. He posted his findings on Twitter:

Screenshot of a tweet from Brian Jackson.
Twitter/Brian Jackson. (View on Twitter.)

Simon Harper, of SRH Design, tested Kinsta Edge Caching by looking at TTFB and LCP as well as first contentful paint (FCP), which is the initial appearance of any content on a screen, even if it is not the page’s primary content. He also reported via Twitter:

Screenshot of a tweet from Simon Harper.
Twitter/Simon Harper. (View on Twitter.)

The structure of web pages and linked assets like JavaScript, CSS, and images can impact FCP and LCP, but it all begins with the delivery of a page’s HTML to a browser.

Getting Started With Kinsta Edge Caching

Edge Caching is enabled by default when you create a WordPress website in the MyKinsta dashboard. That means you don’t have to lift a finger to take advantage of the Edge Caching speed boost.

Beginning in January 2023, Kinsta will automatically enable Edge Caching on existing sites that are compatible with the service. If you want Edge Caching working for your existing site right away, you can enable it now like this:

  • Select WordPress Sites on the left-hand navigation.
  • Select the name of a site for which you want Edge Caching enabled.
  • Select Edge Caching.
  • Click on the Enable Edge Caching button.
Screenshot: Enabling Edge Caching in MyKinsta.
Enabling Edge Caching in the MyKinsta dashboard.

Cache Your Mobile Content on the Edge

If your website detects mobile browsers and generates pages with markup unique to those devices, you can enable a mobile cache separate from the content for desktop users.

Enable mobile caching in MyKinsta like this:

  • Select WordPress Sites on the left-hand navigation.
  • Select the name of a site for which Edge Caching is enabled.
  • Select Edge Caching.
  • Click the Enable Mobile Cache button
Screenshot: Enabling mobile cache in MyKinsta.
Enabling Edge Caching for mobile devices.

You don’t need to enable mobile caching if your website design supports both desktop and mobile browsers with the same responsive HTML/CSS markup.

Managing Your Cached Content

Kinsta Edge Caching is designed to work seamlessly with the cache-management tools most of our customers are already using on their WordPress websites. You can also target content in the edge cache directly in MyKinsta here:

  • Select WordPress Sites on the left-hand navigation.
  • Select the name of a site for which Edge Caching is enabled.
  • Select Edge Caching.
Screenshot: Clearing caches in MyKinsta.
Clearing the edge caches in the MyKinsta dashboard.

To clear all of your site’s pages from the global edge cache, click the Clear Cache button.

If you need to clear only specific pages or paths, paste a target URL in the Clear URL Cache field and click the Clear URL Cache button. Clear the cache for all content on a specific path by checking the option to Clear cache of every subdirectory under the specified URL.

Opting Out of Edge Caching

If you know Edge Caching isn’t going to be a fit for your website, you can opt out before we begin enabling the service for most existing sites in January of 2023.

In MyKinsta:

  • Select WordPress Sites on the left-hand navigation.
  • Select the name of your WordPress site.
  • Select Edge Caching.
  • Enable the “I want to opt-out…” toggle.
Screenshot: Opting out of Edge Caching in MyKinsta.
Opting out of Edge Caching using the MyKinsta dashboard.

If Edge Caching is already enabled for a website, you’ll find a Disable button in the upper-right corner of the page:

Screenshot: Disabling Edge Caching in MyKinsta.
Disabling Edge Caching

Quick Questions About Edge Caching

You might be wondering…

Is Edge Caching Free on All Plans?

Yes. Edge Caching is enabled by default on all live sites created within the MyKinsta dashboard. Edge Caching is also available on staging sites within Premium accounts.

Does Edge Caching Improve the Performance of the Mobile Version of My Website?

You can enable a mobile-specific cache for websites that generate markup tailored to mobile devices. If your website design supports both desktop and mobile browsers with the same responsive HTML/CSS markup, a mobile cache is not required.

Do I Need to Use WordPress Optimization Plugins?

No. Kinsta’s Managed WordPress Hosting platform provides local caching, Edge Caching, and a CDN that is finely tuned to support the world’s most popular CMS. No third-party WordPress plugins are required.

Can I Turn Off Edge Caching?

Yes. You can disable Edge Caching at any type within the MyKinsta dashboard. If you are not sure if your site is compatible with Edge Caching, contact Kinsta’s support team for advice.

Summary

The promise of the Internet has always been to connect people around the world. But, it turns out that the physical distance between servers and visitors has a real impact on the perceived performance of websites. Edge Caching moves that content closer to web browsers and speeds up the essential first step in faster page loads.

Kinsta makes Edge Caching a fundamental component of its Managed WordPress Hosting service, complementing the CDN and network security features that come with our Cloudflare integration.

On average, Kinsta Edge Caching cuts in half the time it takes to deliver the HTML of web pages to your site’s visitors. For websites with truly global audiences, the increase in speed can be dramatically higher.

Edge Caching is available to all of our customers at no extra cost. If you are still looking for a WordPress host built with security, ease of use, and performance in mind, we have a hosting plan that’s right for you.

Steve Bonisteel Kinsta

Steve Bonisteel is a Technical Editor at Kinsta who began his writing career as a print journalist, chasing ambulances and fire trucks. He has been covering Internet-related technology since the late 1990s.