AEM Edge Delivery Services Why Lighthouse 100 in the lab is not enough, and how tags, consent and personalization fit into the three loading phases
Edge Delivery Services is the delivery of Adobe Experience Manager that is marketed with a Lighthouse score of 100. The architecture is indeed leaner than the classic path via publish instance and Dispatcher. Whether a website passes the Core Web Vitals is still decided in production: by tag management, consent banner and personalization added after go-live. This page describes where Edge Delivery Services gains performance and where it is lost again.
Edge Delivery Services in the benchmark: faster server response, open question for the main content
The AEM Core Web Vitals Benchmark 2026 covers websites with Edge Delivery Services in the DACH region in 87 datasets per website and country. Of these, 54.0 percent pass the Core Web Vitals on mobile, compared with 49.4 percent for classic delivery.
| Metric | Edge Delivery Services | Classic delivery |
|---|---|---|
| Time to First Byte | 82.4 % | 66.4 % |
| Largest Contentful Paint | 65.5 % | 67.6 % |
| Interaction to Next Paint | 80.3 % | 74.4 % |
| Cumulative Layout Shift | 72.2 % | 75.7 % |
Server response time is the part that delivery influences directly. Largest Contentful Paint also depends on images, fonts, the consent banner and everything that loads before the main content. The group is small and not randomly composed: teams that move to Edge Delivery Services rebuild the frontend and often drop legacy code in the process. In the separate crawl, the 51 websites with Edge Delivery Services pass at a rate of 45.1 percent, the remaining AEM websites at 68.4 percent; no advantage of the delivery method can be derived from this.
Three loading phases in Edge Delivery Services: eager, lazy and delayed
Edge Delivery Services serves prerendered HTML through a CDN and splits page loading into three phases. Adobe describes them under Keeping it 100:
- Eager: everything needed for the first visible area and the LCP element. As a rule of thumb, Adobe recommends loading from a single host and less than 100 kilobytes in total before Largest Contentful Paint.
- Lazy: header and footer of the page, blocks below the visible area, further styles and fonts, loaded after the main content.
- Delayed: code outside the control of the project, above all tags, analytics and other third parties, loaded only after the main content and without effect on the first render: in the current boilerplate after a consent check, in many existing projects with a fixed delay of about three seconds.
This split is the actual reason for the good lab values. It only holds as long as every new script lands in the right phase.
Adobe Tags and martech: the delayed phase decides responsiveness
A typical pattern after a migration: the tag manager embed code, such as Adobe Experience Platform Tags (formerly Adobe Launch), is taken over from the old platform and included synchronously in the head. A second host with extensive JavaScript loads before the main content again, and the loading phases lose their effect.
Personalization, for example with Adobe Target, is harder. If it runs in the delayed phase, visitors briefly see the default content before it is replaced. If it runs in the first phase, it burdens the main content. Adobe has developed its own approaches for Edge Delivery Services that distribute the martech components across the loading phases. Which option applies per page type should be decided before go-live and recorded in the performance budget. How the loading phase affects Interaction to Next Paint only shows in field data.
Consent banner on Edge Delivery Services: often the LCP element on mobile
On mobile, the consent banner can be the largest element in the visible area and then becomes the LCP element itself. If it loads in the delayed phase, in that case Largest Contentful Paint moves to the moment it appears. If it loads early as a third-party script, it burdens the first phase.
What works is a lean banner that appears with the first render, does not shift its position afterwards and loads the actual consent logic late. The decision on provider and presentation is usually made by data protection, and its effect on the Core Web Vitals belongs in the same discussion.
Operational Telemetry: your own field data from Edge Delivery Services
Edge Delivery Services comes with its own real-user measurement, Operational Telemetry. It works with samples, without cookies and without local storage, and records Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Adobe describes the data under Operational Telemetry.
- For work on the platform, the samples show changes per page faster than the rolling 28-day window of the Chrome User Experience Report.
- For Google's assessment, the Chrome User Experience Report remains decisive, as described under Measuring Core Web Vitals.
- Browsers on iOS have only reported Largest Contentful Paint and Interaction to Next Paint since Safari 26.2 (December 2025), and still no Cumulative Layout Shift. The Chrome User Experience Report contains no data from Safari. For audiences with a high iOS share, this belongs in the analysis.
Migrating to Edge Delivery Services: target values before the first block
Edge Delivery Services replaces Dispatcher and client libraries with CDN and blocks. The underlying questions remain: cache key and invalidation in the CDN as described under AEM Dispatcher Cache, size and loading mode of JavaScript as described under AEM Client Libraries. For the migration, this means:
- Baseline values per page type from field data of the existing platform, measured before the rebuild.
- Target values for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift per page type, set before the first block.
- An assignment of every tag manager script to a loading phase, with owner and justification.
- Sign-off against field data after go-live, not against the Lighthouse score of a preview.
Dates and paths after AEM 6.5 are covered under AEM 6.5 End of Support, the wording for the specification in the AEM Performance Requirements Template. All causes on AEM platforms are put in context under Adobe Experience Manager Performance.
Book a free performance analysis
30 minutes by video. You receive Google's real-user data for your platform compared with two competitors, whether or not a collaboration follows.
Frequently asked questions about AEM Edge Delivery Services
Does every website on Edge Delivery Services reach good Core Web Vitals?
No. Edge Delivery Services creates a good starting point, above all for server response time. Whether a website passes the Core Web Vitals depends in production on tag management, consent banner, personalization and images. Google assesses the experience of real visitors over the last 28 days, not the Lighthouse score.
Where do Adobe Tags (Adobe Launch) belong with Edge Delivery Services?
In the delayed phase, which loads after the main content and after the consent check. An embed code included synchronously in the head loads a second host before the main content and cancels the loading phases. For personalization that has to take effect early, it should be decided per page type which part may load earlier.
How are Core Web Vitals measured on Edge Delivery Services?
With two sources. Operational Telemetry samples real visitors on your own platform and shows changes per page quickly. The Chrome User Experience Report shows how Google assesses the pages and remains the yardstick for sign-off.