A shop can respond lightning-fast at the origin server and still feel sluggish for users on another continent. The reason is physics: light travels through fiber at only about 124 miles per millisecond (Cloudflare) -- roughly two-thirds of its vacuum speed. Every bit of distance costs measurable time before the first byte arrives. This is exactly where a CDN and edge caching come in: they place copies of your content on servers near the user, so requests no longer have to travel across the globe to the origin. The effect is directly business-relevant. Amazon found that every additional 100 milliseconds (Amazon) of latency cost roughly 1 percent (Amazon) in sales, and Akamai measured that a 100-millisecond (Akamai) delay can reduce conversions by up to 7 percent (Akamai). This article shows how to combine a CDN, edge caching and cache-control headers so your Core Web Vitals stay stable even far from your location -- distinct from origin caching with Varnish and Redis, which forms its own layer.
Why Distance Decides Time to First Byte
Time to First Byte measures the time from the request to the first received byte of the response. It is made up of DNS resolution, connection setup, TLS handshake and server processing -- and network latency runs through each of these steps. One of the principal causes of that latency is simply the distance between user and server. Cloudflare illustrates this with an example: a server hosted in Columbus, Ohio answers requests from Cincinnati, about 100 miles away, in 5 to 10 milliseconds (Cloudflare), while requests from Los Angeles, around 2,200 miles away, take closer to 40 to 50 milliseconds (Cloudflare) -- and that is for a single trip only.
This latency adds up because establishing a connection requires several round trips. On a transcontinental connection, DNS, TCP handshake and TLS negotiation quickly accumulate to several hundred milliseconds before the first content-bearing byte even flows. That is precisely why the same shop feels slower in a distant market, even though the pure server processing is identical. A sound server optimization therefore never considers TTFB locally alone, but from the perspective of a genuinely distributed user base.
TTFB, Edge and Origin -- the Terms
How a CDN Shortens the Path to the User
A content delivery network is a globally distributed network of edge servers. Instead of routing every request to the origin, the CDN serves content from the node closest to the user. Hundreds of milliseconds of round-trip time often become just a few -- perceived speed rises markedly without putting more load on the origin. In fact this delivery model has long been mainstream: in the Web Almanac dataset, 54 percent (Web Almanac, 2024) of over 1.3 billion requests are answered from a CDN.
Adoption, however, follows a clear pattern by reach. While 71 percent (Web Almanac, 2024) of the 1,000 most-visited websites use a CDN, only 49 percent (Web Almanac, 2024) of the top 1 million sites do, and merely 35 percent (Web Almanac, 2024) of the top 10 million. Smaller and mid-sized shops in particular often leave potential on the table here: the technique large providers take for granted is accessible to them too. Since around 57 percent (Statista, 2024) of worldwide e-commerce revenue happens on mobile devices -- often over cellular networks with higher base latency -- edge proximity is especially impactful there.
Geographic Proximity
Edge PoPs serve static content from the user's region. The round trip to the distant origin is eliminated for the bulk of requests, which immediately lowers TTFB.
Origin Relief
Every cache HIT at the edge is a request that never reaches the origin. This shields the source server from load spikes and stabilizes response times under heavy demand.
Optimized Connections
CDN nodes often keep warm, reusable connections to the origin and terminate TLS at the edge. This shortens handshakes and speeds up even dynamic responses.
Cache-Control: the Language the Edge Understands
A CDN does not cache arbitrarily but follows the instructions your origin sends in the HTTP response headers. The most important of these is Cache-Control. It defines whether, where and for how long a response may be cached. In practice this header is widespread: according to the Web Almanac, 74.8 percent (Web Almanac, 2024) of desktop requests use a Cache-Control header. What matters, however, is not its mere presence but the right directive for the respective resource type.
# Static asset with hash in the filename -- cache long, immutable
Cache-Control: public, max-age=31536000, immutable
# HTML document -- cache at the edge, revalidate server-side
Cache-Control: public, s-maxage=600, stale-while-revalidate=60
# Personalized page -- never store at the edge
Cache-Control: private, no-storeThree building blocks deserve special attention. s-maxage sets the lifetime exclusively for shared caches like the CDN and can be controlled separately from the browser cache (max-age). immutable signals that a file never changes -- ideal for versioned assets. And stale-while-revalidate lets the edge serve a slightly stale response immediately and fetch a fresh version in the background, so no user waits for revalidation. How this interplays with the browser and application cache is explored in our article on caching strategies with Varnish and Redis, which examines the layers behind the edge.
Personalized Content Does Not Belong in the Shared Cache
What Can Be Cached -- and What Cannot
Not every resource is equally suited to the edge. Static assets are nearly ideal: according to the Web Almanac, 99.3 percent (Web Almanac, 2024) of CSS responses and 95.3 percent (Web Almanac, 2024) of scripts are cacheable, and for fonts even 99.8 percent (Web Almanac, 2024). Overall, 90.4 percent (Web Almanac, 2024) of all desktop responses are considered cacheable. These files rarely change, can be versioned and can sit at the edge with a long lifetime.
With the HTML document it gets more nuanced: only 72.6 percent (Web Almanac, 2024) of HTML responses are cacheable, because HTML often carries personalized or time-critical content. Here edge caching with a short s-maxage and stale-while-revalidate helps, or a separation into a static frame and dynamically loaded fragments. Anyone already working on image optimization with modern formats benefits twice: smaller image files sitting at the edge travel short distances and are small -- two levers that add up.
The edge does have a limit, however: resources loaded from third-party domains do not sit in your CDN and escape your cache control. This applies precisely to external scripts whose delivery the provider controls. They continue to travel their own paths and can undo the benefits of a fast edge again. How to deliberately reduce such scripts is covered in our article on trimming third-party scripts -- a lever that sensibly complements edge caching.
| Resource type | Edge suitability | Recommended strategy | Typical lifetime |
|---|---|---|---|
| Versioned assets (CSS, JS, fonts) | Very high | public, immutable | up to one year |
| Images and media | High | public, long max-age | weeks to months |
| Static HTML | Medium | s-maxage plus revalidate | seconds to minutes |
| Personalized pages | None | private, no-store | not at the edge |
| API with dynamic data | Low | short s-maxage or no-store | seconds or not at all |
Cache Invalidation: Staying Fresh Without Losing Speed
The hardest question in edge caching is not how to cache but how to get rid of stale content again. If a response with a long lifetime sits at the edge, users see changes only when the lifetime expires -- unless the cache is invalidated deliberately. The most robust approach is cache busting via the filename: if a file changes, its hash in the name changes, and the edge treats it as a new resource. That is exactly why versioned assets may safely cache for a year.
For content whose URL stays stable -- such as a product page whose price changes -- active invalidation is needed. Two methods have proven themselves: the targeted purge of individual paths and grouped invalidation via cache tags, where a single event invalidates all related pages at once. In our experience (project experience), a well-thought-out tag strategy is the difference between a cache that relieves load and one that constantly causes trouble. Route-based code splitting additionally helps here, because changes can be confined to individual, clearly delimited files.
Practical Tip: stale-while-revalidate as a Safety Net
Edge Caching in the Shop: Separate Personalization Cleanly
In e-commerce, the desire for edge caching seemingly collides with the reality of personalized content: cart, login status and customer-group pricing cannot be cached globally in a naive way. The way out lies in separation. Static and semi-static areas -- category pages, product descriptions, images, scripts -- are served from the edge, while personalized fragments are loaded via a client-side call or through an uncached partial response. This way the large part of the page that is identical for everyone benefits from edge proximity, without private data getting mixed up.
For server-side rendered shops based on Shopware CE, this means structuring storefront delivery deliberately: the stable page frame may sit at the edge, while the personalized header area with the cart is loaded separately. Which levers apply specifically here is explored on our Shopware performance page. What matters is clean marking via Cache-Control and the choice of the right Vary headers, so the edge holds separate entries for different variants -- such as language or compression -- without fragmenting the cache.
Edge caching in the shop is not an all-or-nothing decision. The art lies in consistently bringing the part of a page that is identical for everyone to the edge and cleanly separating the personalized rest -- then TTFB drops for most bytes without losing personalization.
Avoiding Common Edge-Caching Mistakes
Edge caching is effective but error-prone when applied schematically. The most consequential mistake is accidentally serving personalized content from a shared cache. Equally common are lifetimes that are too short, which depress the HIT rate, as well as missing invalidation, through which users see stale prices or stock. Patience cannot be taken for granted: a delay of two seconds increased the bounce rate by 103 percent (Akamai, 2017) in Akamai's measurements.
- Consistently mark personalized responses with private or no-store, never public
- Cache versioned assets via a hash in the filename with a long max-age and immutable
- Control s-maxage for the edge separately from max-age for the browser
- Use stale-while-revalidate to avoid cache stampedes on expiry
- Plan active invalidation via purge or cache tags for stable URLs
- Set Vary headers deliberately so as not to fragment the cache unnecessarily
Another classic is optimizing without measurement. Anyone who changes cache headers without observing HIT rate and TTFB before and after works blind. Since the probability of a bounce rises by 32 percent (Google/SOASTA, 2017) when load time grows from one to three seconds and by 90 percent (Google/SOASTA, 2017) from one to five seconds, every saved hundredth of a second counts. A sound performance analysis shows which resources sit at the edge, how high the real HIT rate is and where TTFB per region still lags.
Measure, Safeguard and Stay Globally Fast
Edge performance is not a permanent state but requires observation. Key metrics are the cache HIT rate, TTFB segmented by region and the share of requests that reach the origin. If the HIT rate drops, it is worth looking at lifetimes, Vary headers and unintentionally non-cacheable responses. Geographic segmentation is revealing: only it shows whether users in distant markets are truly served by a nearby PoP or whether requests slip through to the origin unnoticed.
We combine synthetic measurements from several world regions with Real User Monitoring from actual sessions. Synthetic tests reveal regressions quickly and reproducibly, field data shows the actual experience across different connections. Since 53 percent (Google, 2018) of mobile visits are abandoned when loading takes longer than three seconds, this continuous observation is no luxury. It is part of our performance services, which consider origin and edge together.
The Core in One Sentence
The effort pays off multiple times. A low TTFB improves Largest Contentful Paint and thus the Core Web Vitals, which strengthens organic visibility. Faster delivery in distant markets reduces bounce rate and lifts conversion -- a mobile load time 0.1 seconds faster increased retail conversions by 8.4 percent (Google/Deloitte, 2020). And a relieved origin stays stable even under load spikes. This turns geographic proximity into a lasting speed advantage -- the lever a specialized server optimization operates consistently together with origin caching.