Adobe Experience Manager Performance AEM performance optimization for Core Web Vitals, from 6.5 to Edge Delivery Services

By Christian Schreiber, Web Performance Consultant for AEM, updated 1 November 2026

AEM delivers pages fast as long as the cache layer in front of it does its job. Everything that comes after it determines the values real users experience: bundled scripts and styles, the data layer, personalization, tags and the consent banner. This page describes where an AEM platform actually loses time, which layer affects which metric, which performance requirements belong in an AEM implementation and how to hold the result across releases and migrations.

AEM 6.5 on Adobe Managed Services: end of support 31 August 2026AEM 6.5 on-premises: February 2027

Dispatcher: the cache layer determines server response time

The Dispatcher sits in front of the publish instances as a cache and filter. Ideally, it answers most requests from the file system without AEM itself doing any work. Where an AEM platform has poor server response time, measured as Time to First Byte, the cause almost always lies here and rarely in the application.

Three patterns recur. First, requests with parameters that bypass the cache, such as campaign or language parameters that do not produce a page of their own. Second, invalidation that is too coarse: when an author's change flushes entire sections of the content tree, the platform effectively runs without a cache during busy editorial periods. Third, personalized areas that mark an entire page as non-cacheable, although only one component is affected. In such cases, measuring the cache hit ratio per page type and limiting invalidation to the paths actually affected achieves more than any frontend optimization.

AEM platforms in the DACH region: 49.4 percent pass the Core Web Vitals

That the cause usually lies in front of the frontend is not a rule of thumb but measurable. For the AEM Core Web Vitals Benchmark 2026, 4,222 AEM websites were evaluated using Google's real-user data and 46,394 domains were checked individually. 49.4 percent pass the Core Web Vitals on mobile devices, compared with 68.7 percent across all websites in the three countries.

For 80.3 percent of the websites with a slow main content load time, the server response time alone already exceeds the threshold of 800 milliseconds. This is exactly the area the Dispatcher is responsible for. The analysis also breaks the results down by generation, industry and delivery type: the best and the weakest industry are 67.8 percentage points apart, considerably more than the AEM generations.

Web performance role models: the fastest AEM websites in the DACH region

These websites keep all three Core Web Vitals in the green range on mobile devices, measured against the real-user data of the Chrome User Experience Report (CrUX). They show that AEM can be fast on large websites when delivery and frontend are right. Only websites that meet all thresholds are named. All others appear only in aggregated form in the AEM Core Web Vitals Benchmark 2026.

AEM websites with passing Core Web Vitals, sorted by main content load time, mobile, data as of August 2026

Website	Industry	LCP	INP	CLS	TTFB
www.zh.ch	Public sector	0.7 s	83 ms	0.02	306 ms
svazurich.ch	Public sector	0.8 s	88 ms	0.04	269 ms
www.fraunhofer.at	Universities and research	0.8 s	no data	0.00	335 ms
www.datev.de	Telecommunications and IT	0.9 s	104 ms	0.00	316 ms
www.aral.de	Energy and utilities	0.9 s	103 ms	0.00	407 ms
www.ebill.ch	Banks and financial services	1.0 s	108 ms	0.00	331 ms
www.elco.de	Industry and engineering	1.0 s	80 ms	0.01	323 ms
www.dzbank.de	Banks and financial services	1.1 s	133 ms	0.09	430 ms
www.horbach.de	Insurance	1.1 s	91 ms	0.00	599 ms
www.techem.com	Industry and engineering	1.1 s	135 ms	0.00	485 ms

Almost all websites on this list share a server response time well below 800 milliseconds. Fast delivery from the cache is not a sufficient condition for green values, but in practice it is a necessary one.

Client libraries: the core component library determines input responsiveness

AEM bundles JavaScript and CSS in client libraries. The concept makes sense, the practice that grows around it rarely does: over the years, categories emerge that embed each other until every page ends up loading the same large bundle, regardless of which components it actually uses. On a homepage this barely shows. On a detail page with three components, it is the largest single item.

Three steps are effective: splitting the bundles by page type rather than by authoring logic, separating the part needed for the visible area from the rest, and deferring everything not needed for the first view. In addition, check whether the core component library runs in the current version, because older versions bring dependencies that have long been unnecessary. This area directly affects Interaction to Next Paint, the time between an input and the visible response.

Core Components and image delivery: the most common cause of layout shifts

Adobe's Core Components already provide a usable foundation for images, layout and navigation, including responsive image variants and reserved dimensions. Projects that have built their own components often do without this unintentionally and create two problems at once: images that are too large for small screens, and jumping layouts because the dimensions are missing from the markup.

For Cumulative Layout Shift, the measure of layout shifts, this is the most common cause on AEM pages, followed by teasers that load after the initial render. Where Dynamic Media is in use, the generated variants and the image format also come into play: modern formats and a suitable number of widths reduce the transferred data volume considerably without touching a single component.

Data layer, tags and personalization: the layer after delivery

The data layer is the bridge between AEM and the marketing infrastructure. It is rarely the problem itself, but it stands at the start of a chain: data layer, tag management via Adobe Launch, analytics, personalization via Adobe Target, consent banner. Each link brings its own JavaScript, and the order in which these scripts run determines the input responsiveness of the page.

Personalization adds a second effect. If an area is swapped in the browser only after the page has rendered, the layout shifts and the user briefly sees the wrong content. If the decision is made on the server instead, this effect disappears, but the cache hit ratio in the Dispatcher drops. Making this trade-off per page type and documenting it in writing is part of the performance budget, not a decision made on the side during a sprint.

AEM infrastructure: Cloud Service and Cloud Manager do not check what happens in the browser

With the move to AEM as a Cloud Service, responsibility for operations and scaling shifts to Adobe. The CDN node in front of the platform, delivery and updates come from the service, and Cloud Manager runs every deployment through a fixed pipeline with quality gates.

What this does not settle is the question of what happens in the browser. The pipeline checks code quality and can include a Lighthouse run, but it sees neither the tags from tag management nor the consent logic nor the differences between markets and devices. A platform can pass every check in Cloud Manager and still have red real-user data. That is why acceptance against real-user data remains a separate task in the Cloud Service as well. What Adobe's own tool contributes here and what remains open is covered under AEM Sites Optimizer.

Edge Delivery Services: Lighthouse 100 in the lab, an open question in production

Edge Delivery Services is Adobe's new delivery approach and is marketed with a Lighthouse score of 100. For a page without marketing infrastructure this score is achievable, and the architecture is indeed leaner than the classic path via Sling and Dispatcher.

However, the score comes from a simulation without tag management, without a consent banner, without personalization and without real devices. Google, by contrast, evaluates what real visitors experienced over the last 28 days. In practice, the difference between the two numbers is exactly what marketing and third parties add after go-live. Edge Delivery is therefore a good starting point, not a result in itself, and the target values for production belong before the migration, not after it.

Monitoring AEM: holding values requires ongoing measurement

An improvement, once achieved, does not hold by itself. Every release, every new tag and every new component shifts the values, and the rolling 28-day window shows a deterioration only with a delay. Monitoring an AEM platform therefore requires two data sources side by side.

The Chrome User Experience Report provides the data Google uses for its assessment and is the benchmark for acceptance. Real user monitoring collects the same metrics on your own website, per page type, market and device, and shows the effect of a release as early as the next day. Lab tools such as Lighthouse remain useful for root cause analysis but are not suitable as target values. Which tool uses which source is explained under Measuring Core Web Vitals.

Legacy systems: Adobe CQ and CQ5 as migration cases

Before its acquisition by Adobe, AEM was called Day Communiqué and was marketed as CQ5 from version 5 onward. Adobe initially continued the product as Adobe CQ and renamed it Adobe Experience Manager as part of building its Marketing Cloud. Anyone still running a system from this generation or from AEM 6.3 today is operating without vendor support.

Such installations can be recognized technically by the delivery paths of their client libraries: older versions deliver under /etc/designs/ and /etc/clientlibs/, and AEM 6.4 adds the path /etc.clientlibs/. For performance, the difference is significant, because the older architecture packs everything into a few large bundles and barely allows for splitting by page type. Such platforms are therefore less an optimization case than a migration case, and in migrations, the target values come before the first sprint.

AEM implementation: performance requirements belong in the requirements specification

Most performance problems of an AEM platform are built in during implementation and only become visible after go-live. The reason is rarely a lack of skill. More often, the requirements specification describes functions, components and integrations, but no measurable speed requirements. What is not required is not signed off. Seven requirements belong in every tender and every implementation contract:

1. Target values per page type and market for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, measured at the 75th percentile of real-user data on mobile devices, not as a Lighthouse score.
2. Cache architecture with specifications for the Dispatcher or CDN: which parameters are ignored, how far a publication invalidates the cache and which page types are fully cached.
3. Client library budget per page type, meaning the maximum amount of JavaScript and CSS a page may load, split between the visible area and the rest.
4. Image delivery via the Core Components image component or Dynamic Media, with defined widths, modern formats and reserved dimensions in the markup.
5. Approval for tags and third parties, so that every new script is checked against the budget before go-live rather than being noticed afterwards.
6. Measurement in operation with real user monitoring per page type alongside the Chrome User Experience Report, set up before go-live and not as a follow-up project.
7. Acceptance per milestone against these target values, carried out by a party that is not itself responsible for the implementation.

These requirements apply regardless of the architecture, whether classic with Dispatcher, AEM as a Cloud Service, Edge Delivery Services or a headless frontend. They barely change the implementation, but they turn speed into a part of the deliverable that can be signed off instead of a hope. How an optimization with such target values works is described under Website Performance Optimization. All seven requirements as a ready-to-use template are available under AEM Performance Requirements Template.

AEM migration: target values before the first milestone, sign-off per area

Whether the path leads to the cloud version, to Edge Delivery Services or to a headless frontend: the target values per page type and market belong before the first milestone, and each migrated area is signed off individually against real-user data. A migration that is measured only after the full go-live delivers exactly one number and no way left to attribute the cause to an area. Dates and paths after AEM 6.5 are covered under AEM 6.5 End of Support.

The implementation partner is responsible for the architecture, the acceptance criteria come from outside. This separation is the reason an independent party adds value here at all: whoever is responsible for the implementation cannot sign it off at the same time.

Independent AEM consulting: implementation and acceptance kept separate

In the DACH region, there is a limited number of implementation partners for Adobe Experience Manager, and most companies already have one. What projects lack is rarely development capacity and almost always a party that sets target values and checks that they are met. This is exactly what this Web Performance Consulting is designed for: no implementation in the same project, no commission from Adobe, no stake in the implementation partner.

The three services, a Performance Assessment, Ongoing Performance Control and Performance Sign-off in Migration Projects, are listed with their scope under Services. How the collaboration with implementation partners works is described under Performance Partner for AEM Agencies.

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 performance optimization