CDN for enterprise platforms What a content delivery network in front of AEM and Magnolia does for response time, and where its effect ends
A content delivery network serves pages and files from nodes close to visitors and relieves the publish or public instances behind it. Whether this actually lowers Time to First Byte depends on the configuration: only a request that the CDN answers from its cache is fast. Every other request runs through to the platform and carries its response time plus the detour.
The Core Web Vitals Benchmark 2026 shows how large the lever is. On smartphones, 68.7 percent of the AEM websites examined and 57.4 percent of the Magnolia websites keep the response time within the good range of up to 800 milliseconds. Among websites whose main content loads too slowly, the cause already lies in the response time for 80.3 percent (AEM) and 78.8 percent (Magnolia), with a median of 1,565 and 1,668 milliseconds.
CDN per platform: Fastly for AEM Cloud Service, Edge Delivery Services and Magnolia DX Cloud
Which CDN sits in front of a platform is fixed for the vendors' cloud offerings. For self-operated platforms, the operator chooses.
| Platform | CDN | Own CDN |
|---|---|---|
| AEM as a Cloud Service | Adobe CDN based on Fastly, always in the delivery path | after approval by Adobe, in front of the Adobe CDN (Adobe KA-35110) |
| AEM Edge Delivery Services | Fastly, managed by Adobe | Fastly, Cloudflare, Akamai or CloudFront (aem.live CDN guide) |
| AEM 6.5 on-premises and Managed Services | chosen by the operator | free choice, in front of the Dispatcher |
| Magnolia DX Cloud | Fastly, part of the managed infrastructure | in coordination with the vendor |
| Magnolia self-operated | chosen by the operator | free choice, in front of the public instances |
For AEM as a Cloud Service, Adobe describes the included CDN under CDN in AEM as a Cloud Service. If your own CDN sits in front, Fastly stays in the path; it then has to be defined which layer caches and which only passes through, so that no two caches with contradictory rules arise. The platform basics are described under Adobe Experience Manager Performance and Magnolia CMS Performance.
Cache key in the CDN: parameters, cookies and headers determine the hit ratio
The CDN stores a response under a key, usually made of host, path and parameters. Every deviation in the key creates a new entry and thus a cache miss. Three sources drive the number of variants:
- Parameters: campaign parameters such as
utm_source,gclidorfbcliddo not change the content but create unique URLs. They should be removed from the key before caching. Adobe does this itself in the CDN of AEM as a Cloud Service for the common parameters since October 2023, but not for custom campaign parameters. - Cookies and sessions: a cookie set for anonymous visitors makes every response individual if the CDN does not cache requests with cookies. The rule: deliver anonymous pages without a session.
- Vary headers:
Vary: User-AgentorVary: Cookiemultiplies the variants. Device-dependent output is better mapped to a few normalized device groups than to the full user agent.
The same rules apply one level down for the AEM Dispatcher cache and the Magnolia cache. The list of ignored and effective parameters is best kept once and maintained jointly for the CDN and the platform cache.
TTL and invalidation in the CDN: Cache-Control, stale-while-revalidate and purge by tag
How long the CDN keeps a response is controlled by the platform's headers. With s-maxage, shared caches such as the CDN get their own lifetime, independent of the lifetime in the browser (RFC 9111). With stale-while-revalidate, the CDN keeps serving the previous version after expiry while fetching the new one in the background (RFC 5861). No visitor then hits the waiting time of a regeneration.
Short lifetimes are often a consequence of missing invalidation: because changes should become visible quickly, content is cached for only a few minutes. A long lifetime with targeted purging on publication works better. The large CDNs purge by tag instead of by URL for this: Akamai via cache tags in the Edge-Cache-Tag header, Cloudflare via cache tags in the Cache-Tag header, Fastly via surrogate keys. A page carries the tags of the content it displays; when content is published, exactly the pages containing it disappear, not the whole cache.
Measuring the hit ratio: CDN logs per page type instead of an overall value
An overall value across all requests is usually high, because images, fonts and scripts cache well. For response time, the hit ratio of the HTML pages counts, separated by page type and market. It is found in the CDN logs. For AEM as a Cloud Service, these logs are available through Cloud Manager for seven days (Adobe KA-52839); for longer analyses, they are forwarded to your own analysis via log forwarding.
Two analyses belong in every review: the hit ratio per page type over time, so that a release with a new parameter or a new session stands out immediately, and the response time of the misses, i.e. of the platform itself. If the latter is well above one second, even a better CDN helps only the hits. An intermediate layer between the edge nodes and the platform, called origin shield, shielding or tiered cache depending on the vendor, bundles the misses and further reduces the load on the platform.
Limits of a CDN: a lever for TTFB and LCP, little effect on INP and CLS
A CDN shortens delivery. What happens afterwards in the browser remains untouched: Interaction to Next Paint arises from scripts, tags and consent dialogs, Cumulative Layout Shift from late-loading areas without reserved space. For Largest Contentful Paint, too, the CDN affects only the first part up to the first byte and the loading time of the image.
The status code 103 Early Hints offers an additional lever: the CDN sends the browser hints about stylesheets, fonts or the main image before the actual response is ready. Akamai, Cloudflare and Fastly support it, with different setups (Akamai, Cloudflare, Fastly, there only over HTTP/2 and HTTP/3). It is most effective on cache misses, because the browser uses the waiting time for the platform.
Acceptance criteria for the CDN: measurable requirements per page type
- A target hit ratio in the CDN is defined for each page type and reported monthly from the logs.
- The list of ignored parameters is documented and identical for the CDN and the platform cache.
- Anonymous pages are delivered without a session cookie.
- Publications purge by tag, not the whole cache.
- Time to First Byte is below 800 milliseconds at the 75th percentile of field data per market, measured in real user monitoring and in the Chrome User Experience Report.
How such requirements are written as tickets is shown in the Core Web Vitals acceptance criteria.
Book a free performance analysis
30 minutes via video call. You see whether your response time arises in the CDN, in the platform cache or in the frontend.
Frequently asked questions about CDNs on enterprise platforms
Which CDN is the fastest?
There is no general answer. Akamai, Cloudflare and Fastly operate dense networks in Europe; on large platforms, the difference between them is usually smaller than the difference between a good and a poor configuration. What matters are hit ratio, cache key and invalidation, measured per page type and market.
Can AEM as a Cloud Service run with your own CDN?
Yes, after approval by Adobe. Your CDN then points to the Adobe CDN, which is based on Fastly and always remains in the delivery path. To avoid two caches with contradictory rules, it is defined which of the two layers caches and which only passes requests through.
What hit ratio should a CDN reach?
There is no universal figure, because page types differ widely: articles and category pages reach high ratios, search and personalized pages low ones. A target value per page type, measured from the CDN logs, makes sense, along with an investigation of every page type that falls clearly below it.
Does a CDN improve the Core Web Vitals?
For Time to First Byte and therefore for Largest Contentful Paint, yes, if the hit ratio is high. Interaction to Next Paint and Cumulative Layout Shift arise in the browser, from scripts, tags and layout. A CDN has little influence on them.