Adobe Experience Manager benchmark, data as of August 2026, version 2026-Q3
AEM Core Web Vitals Benchmark 2026 4,222 websites in the DACH region, evaluated by cause instead of by score
Adobe Experience Manager runs the largest websites in the German-speaking region, and that is exactly where delivery determines the user experience. This study takes apart 4,222 AEM websites from Google's real-user data and adds a separate crawl of 46,394 domains that shows which generation delivers the pages and whether a slow page is a matter of operations or of the frontend.
- 49.4 percent of AEM websites 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 is already too high. For them, the work starts in operations, not in the frontend.
- Among the websites that fail, 55.9 percent miss the threshold for the main content load time (LCP).
- 28.8 percent of the AEM websites detected in the separate crawl still deliver via the paths of the generations up to 6.3.
- Websites on Edge Delivery Services pass at a rate of 54.0 percent, 4.6 percentage points better than the classic delivery.
Book a free performance analysis
30 minutes by video. You see where your platform stands in this distribution and which of the two causes dominates in your case.
- Two data sources: Google's real-user data for breadth, a separate crawl for generation and cause
- No login, no form. Raw data, methodology and queries are on this page
AEM websites are 19.3 points below the market average, and size alone does not explain it
The first comparison sets the AEM websites in the DACH region against all recorded websites in the three countries, each on mobile devices.
Objection: AEM websites are larger than average
Part of the gap is structural. AEM is used where websites are large: several markets and languages, campaign pages, personalization, tag management, consent banner. The average across all websites, by contrast, is carried by many small, technically simple websites. In that sense, the first figure compares two different classes of websites.
The gap remains even among the 100,000 most visited websites
The objection only holds until the second figure. Within the 100,000 most visited websites, in other words in the same size class, AEM websites pass at a rate of 53.9 percent, which is 4.5 percentage points better than across all ranks. The gap to the overall market remains. The size of the websites explains part of the gap, not all of it.
Operations or frontend: for 80.3 percent of slow websites, the server already responds too late
The most important question in an analysis is not how bad a value is but who can fix it. The two can be separated because, in addition to the main content load time, the server response time is also available as real-user data.
Operations or frontend: the server response time separates the two at 800 milliseconds
The server response time measures how long it takes until the first byte of the page reaches the browser. Up to 800 milliseconds it counts as good. If this value is already poor, every optimization of images and scripts has no effect, because the delay occurs before them: in the Dispatcher, in the cache hit ratio, in the rendering time of the publish instance. If the response time is good and the main content still arrives late, the cause lies in the frontend.
57 of 71 slow AEM websites already respond too late on the server
Of 71 websites with a slow main content load time, 57 already have a server response time that is too high, with a median of 1,565 milliseconds. For the remaining 14 websites, the server responds after a median of 614 milliseconds, so the delay occurs afterwards. Across all websites checked, 68.7 percent keep the response time in the good range.
In practice, this means: for the majority of these websites, a performance ticket for the frontend team goes to the wrong address. The first look belongs to the cache hit ratio of the Dispatcher cache, the invalidation rules after each activation and the question of how many page variants personalization creates. Only once the response time is under control does work on images, fonts and scripts pay off.
LCP decides whether AEM websites pass the Core Web Vitals
A website passes the Core Web Vitals only if all three metrics are in the green range. The breakdown shows which of them is decisive in practice.
Largest Contentful Paint: main content load time
67.6 percent meet the threshold of 2.5 seconds; the median is 2.0 seconds. The metric measures when the largest visible element in the initial viewport has finished loading, usually the hero image. On AEM websites this is almost always an asset from the DAM, delivered through a rendition chain that is rarely optimized for mobile screen widths.
Interaction to Next Paint: response time to input
74.4 percent stay below 200 milliseconds; the median is 150 milliseconds. This metric rises with the amount of JavaScript working on the main thread. On large websites, that JavaScript rarely comes from the CMS: tag manager, consent banner, testing tools and analytics share the same thread as the page's controls.
Cumulative Layout Shift: layout stability
75.7 percent are below 0.1; the median is 0.05. The metric measures how much content shifts during loading. It is the best-controlled of the three metrics because fixed dimensions for images and ad slots are standard practice. Where it fails, the cause is usually campaign banners loaded later without reserved space.
In the separate crawl of 364 websites with real-user data, 127 fail. Of these, 47.2 percent miss the response time threshold, 55.9 percent the load time threshold and 46.5 percent the layout stability threshold. For 37.8 percent, several metrics fail at the same time, which as a rule points to a common cause rather than three separate problem areas.
AEM generations: 140 of 486 websites deliver via the old paths
No public statistic reveals which AEM generation a website uses. The HTTP Archive technology detection has exactly one entry for Adobe Experience Manager and no version. The generation is visible nonetheless, in the delivery path of the client libraries.
AEM generation recognizable by the client library paths
Up to and including AEM 6.3, the bundled scripts and stylesheets are located under /etc/designs/ and /etc/clientlibs/. From 6.4 onwards, the proxy delivers them under /etc.clientlibs/. Edge Delivery Services identifies itself through its own host names and through /scripts/aem.js. All three patterns appear in the source code of every page and can be checked with a single request to the homepage.
Old client library paths indicate a version without vendor support
Of 486 detected websites, 140 deliver exclusively via the old paths. This is not proof of a specific version, but a reliable indication of a version the vendor no longer supports. For the operator, the figure is above all a statement about room for action: whoever is at this level can use neither Core Components in their current form nor the newer image and delivery features. Which dates apply to AEM 6.5 and how a migration can be safeguarded is described under AEM 6.5 End of Support.
| Generation | Websites | Passed | Excluding group websites | Server response time |
|---|---|---|---|---|
| AEM 6.4+ with legacy paths | 25 | 72.0% | 72.0% of 25 | 493 ms |
| CQ5 to AEM 6.3 | 134 | 87.3% | 70.6% of 51 | 636 ms |
| AEM 6.4+ | 154 | 51.3% | 51.3% of 154 | 792 ms |
| Edge Delivery Services | 51 | 45.1% | 45.1% of 51 | 782 ms |
A single group of websites shifts the statistics of an entire generation
At first glance, the legacy installations perform brilliantly: 87.3 percent of 134 websites pass the Core Web Vitals. The reason is not the age of the software. 83 of these websites belong to the Sparkassen savings bank group, run on a jointly operated platform with uniform templates and pass at a rate of 97.6 percent. They are counted as many websites, but they go back to a single technical decision.
Without this group, 51 websites remain on a generation without vendor support, passing at a rate of 70.6 percent, compared with 54.2 percent for the 179 websites from version 6.4 onwards. The gap of 16.4 percentage points still favors the older group, but it is considerably smaller. It can be explained without reference to the version: organizations that have not migrated for years usually also run the leaner website, without personalization and without the campaign logic of newer projects. A new version does not make a platform slower; in practice it simply comes with more features.
The actionable insight: an upgrade does not improve the Core Web Vitals on its own, and skipping the upgrade does not protect them. What counts is how much campaign, personalization and third-party logic is added with each release. That is why a performance budget belongs in the sign-off of every release, regardless of the version.
Edge Delivery Services: a lead of 4.6 points, but no free pass
Adobe promotes Edge Delivery Services with top scores in Lighthouse. The real-user data shows a more sober, but still clear picture.
Edge Delivery Services: 54.0 percent pass, in a small group
In the DACH region, 87 websites with Edge Delivery Services are recorded. Of these, 54.0 percent pass the Core Web Vitals, compared with 49.4 percent for the classic delivery. The lead is real, but the group is small and its composition is not random: organizations that switch to Edge Delivery today rebuild the frontend and usually shed legacy code that has nothing to do with the delivery method.
Edge Delivery Services shortens the response time, not the work in the browser
Delivery via the edge network shortens the server response time, which is exactly the part that is the problem for 80.3 percent of the slow websites. Everything that happens afterwards in the browser remains unsolved. Tag manager, consent banner and personalization usually move along unchanged in a migration. A website whose response time to input depends on three analytics tools today will not become faster on Edge Delivery.
For the decision, this means: the question before a migration is not whether Edge Delivery is faster, but what share of your own delay occurs before the first byte. This figure is in your own real-user data and can be determined within an hour. If the focus lies in the frontend, the migration delivers less than half of what the example values suggest.
Mobile and desktop are 3.1 points apart
Both form factors are assessed separately, and for rankings the mobile value usually counts.
In the separate crawl, 65.1 percent of the websites pass on mobile devices and 62.0 percent on desktop. On mobile, the main content becomes visible after a median of 1.9 seconds, on desktop after 1.4 seconds. This gap is not caused by screen size but by computing power and network: the same JavaScript bundle takes many times longer on a mid-range phone than on a workstation. Basing the sign-off of a release on desktop values systematically measures the more favorable case.
Industries: 67.8 points between the best and the weakest group
The industry is assigned based on the domain name; the patterns are listed in the methodology. Only groups with at least ten websites are reported.
| Industry | Websites | Passed | Main content | Response time |
|---|---|---|---|---|
| Insurance | 27 | 81.5% | 1.8 s | 637 ms |
| Banks and financial services | 50 | 76.0% | 1.8 s | 629 ms |
| Industry and engineering | 37 | 64.9% | 1.9 s | 782 ms |
| Chemicals, pharma and medical technology | 19 | 57.9% | 2.2 s | 1,072 ms |
| Consumer goods and retail | 14 | 50.0% | 2.3 s | 1,049 ms |
| Automotive and suppliers | 38 | 36.8% | 2.3 s | 667 ms |
| Telecommunications and IT | 22 | 13.6% | 2.6 s | 969 ms |
The range between the best group, Insurance, at 81.5 percent and the weakest group, Telecommunications and IT, at 13.6 percent is 67.8 percentage points. It is therefore many times larger than the gap between the AEM generations. This is the actual finding of this table: how a website is operated and equipped weighs more heavily than the question of which version runs underneath.
The last two columns separate two different problems that look the same at first glance. Industries with a good response time and still a late main content load time have their delay in the browser: large hero images, render-blocking stylesheets, late-loading fonts. There, work on media delivery helps, not work on the cache. Industries in which the response time is already above the threshold carry their problem before that point, in the Dispatcher, rendering time and cache hit ratio. If you look for your own industry in this table, it is best to read the row from right to left: first the response time, then the load time, then the share of passing websites.
The assignment is based on patterns in the domain name. Of 364 websites in the separate crawl, 207 are in the reported groups. Another 51 are spread across industries below the minimum size of 10 websites, and 23 match no pattern. Both parts are left out. The 83 websites of the Sparkassen savings bank group are also excluded because they run on a shared platform and would otherwise determine the industry on their own. The table therefore describes the groups listed, not the entire study.
Germany, Austria and Switzerland compared: market differences are small
The three markets are reported separately, provided there are at least 30 websites.
In Germany, 50.6 percent of 2,605 websites pass, in Austria 44.4 percent of 734 and in Switzerland 50.1 percent of 883. A website can be recorded in several countries if it reaches enough real-user data in each of them; the sum of the three figures is therefore higher than the number of individual websites. The differences between the markets are smaller than those between the industries and do not serve as an explanation for a weak value of your own.
Trend: 4.3 percentage points since January 2024
The HTTP Archive API provides the values on a monthly basis. Over 32 months, this results in a time series instead of a snapshot.
Since January 2024, the share of passing AEM websites has risen by 4.3 percentage points, while the gap to the overall market remains. Two effects overlap in this line: the actual work on the platforms and the change in the population, because websites are added and dropped every month. To assess a single platform, its own trend over the same 28-day windows is therefore more meaningful than the market line.
The fastest AEM websites in the DACH region
Only websites that keep all three metrics in the green range are named. Platforms below the thresholds appear exclusively in aggregated form.
| Website | Industry | Main content | Response to input | Server response |
|---|---|---|---|---|
| www.zh.ch | Public sector | 0.7 s | 83 ms | 306 ms |
| svazurich.ch | Public sector | 0.8 s | 88 ms | 269 ms |
| www.fraunhofer.at | Universities and research | 0.8 s | no data | 335 ms |
| www.datev.de | Telecommunications and IT | 0.9 s | 104 ms | 316 ms |
| www.aral.de | Energy and utilities | 0.9 s | 103 ms | 407 ms |
| www.ebill.ch | Banks and financial services | 1.0 s | 108 ms | 331 ms |
| www.elco.de | Industry and engineering | 1.0 s | 80 ms | 323 ms |
| www.dzbank.de | Banks and financial services | 1.1 s | 133 ms | 430 ms |
| www.horbach.de | Insurance | 1.1 s | 91 ms | 599 ms |
| www.techem.com | Industry and engineering | 1.1 s | 135 ms | 485 ms |
The last column stands out. Almost all websites on this list deliver the first byte well below the threshold of 800 milliseconds. Fast delivery is therefore not a sufficient condition for green values, but in practice it is a necessary one.
Four steps for AEM platforms: response time first, then the frontend
Four steps, in this order, derived from the distribution of causes in this study.
Clarify the server response time first, not the images
The first value to obtain is the server response time, the Time to First Byte, from your own real-user data, broken down by page type. If it is above 800 milliseconds, the order is decided: cache hit ratio of the Dispatcher cache, invalidation rules, number of personalized variants. Everything else waits, because it would not show in the result.
Take inventory of third-party scripts nobody ordered
Input responsiveness is the metric that least often originates in the CMS. A list of all scripts delivered via the tag manager, with owner and last proof of use, regularly achieves more on large websites than any frontend optimization. What matters is not the number of scripts but how much of them runs before the first interaction.
Target values per page type instead of one overall value
Homepage, overview page, detail page and form have different load profiles. A single value for the domain hides which page type drags the result down and makes the sign-off of a release impossible, because nobody can say what has deteriorated.
Sign off every release against a performance budget
Google calculates the values from a rolling 28-day window. A deterioration becomes visible weeks after the release, and so does a fix. To keep the values, check against a performance budget before go-live, on the same page types for which the target values apply.
What these steps mean for Dispatcher, client libraries and Edge Delivery Services is described on the page Adobe Experience Manager Performance; an assessment of Adobe's own tool is on the page AEM Sites Optimizer. The process with target values per page type and independent sign-off is described under Website Performance Optimization. For requirements specifications and implementation partners, see the AEM Performance Requirements Template and Performance Partner for AEM Agencies.
Methodology of the AEM benchmark: two public sources, both verifiable
The study was produced on 15 September 2026 with the data month August 2026.
Breadth: Google's real-user data via the HTTP Archive API
The Chrome UX Report collects the measurements of real Chrome users and publishes them monthly per website and country. The HTTP Archive combines these values with a technology detection and provides the analysis via an open API. All figures on the population, the countries, the rank classes and the trend come from this source: 4,222 AEM websites and 812,368 websites as a reference value.
Depth: separate crawl of 46,394 domains for generation and cause
The aggregate API is not sufficient for generation, server response time and industry assignment. For these, 46,394 domains from the Majestic Million ranking, filtered to the endings de, at and ch, were each requested once on the homepage and checked for visible resource paths. For the 486 AEM websites detected, the real-user data was then queried per website; 364 of them have enough traffic for reliable values.
Thresholds: LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1
The assessment uses 2.5 seconds for the main content load time, 200 milliseconds for input responsiveness and 0.1 for layout stability, each at the 75th percentile over 28 days. Passed means: all available metrics in the green range. The server response time counts as good up to 800 milliseconds; it is not one of the Core Web Vitals, but it is the value that separates operations from the frontend.
Industry assignment via the domain name and its limits
The industry is recognized from the domain name, for example from endings such as gv.at and admin.ch for the public sector, from manufacturer names for automotive and industry, or from name components such as versicher and bank for the financial sector. The patterns are kept in one place in the repository and are therefore traceable. Anything that matches no pattern remains unassigned and is not included in any group; a wrong assignment would be worse than a missing one. Websites of the Sparkassen savings bank group are reported separately for the generations because they run on a shared platform and would otherwise determine an entire group.
Sources: Chrome UX Report and the HTTP Archive Technology Report API, both retrieved on 15 September 2026. The candidate list Majestic Million is licensed under Creative Commons Attribution 3.0.
Limitations: the Chrome UX Report only contains websites with sufficient Chrome traffic; smaller websites are systematically missing. A website does not equal a company. The technology detection misses installations whose resource paths are hidden behind a content delivery network. All relationships in this study are observations, not causes.
Frequently asked questions about the AEM Core Web Vitals Benchmark
Five points that come up regularly with this type of study.
Why do these figures differ from your PageSpeed Insights result?
PageSpeed Insights shows two things side by side: a lab measurement with a score and the field data from the Chrome UX Report. This study uses only the field data, that is, the values of real users over 28 days. The lab score can be 100 while the field data misses the threshold, because the lab involves neither a consent banner nor a tag manager nor real devices. Which tool uses which source is described under Measuring Core Web Vitals.
The pages are in the Dispatcher cache. Why do the values still need improvement?
The cache speeds up the server's response, that is, the first step. The Core Web Vitals are produced afterwards in the browser, by images, scripts, fonts, tag manager and consent banner. A cache hit after 80 milliseconds helps little if two megabytes of JavaScript are then loaded and executed. Conversely, the finding of this study applies: for the majority of slow websites, the cache is precisely not the reason, because the response time is already too high before that point.
Is switching to Edge Delivery Services worthwhile for the Core Web Vitals?
That depends on where your delay occurs. If the focus is before the first byte, in cache and delivery, the switch brings a lot. If it is afterwards, in the frontend and in third-party scripts, the problem moves along with you. The answer is in your own real-user data and can be determined before any architecture decision.
Why are websites with poor values not named?
Because the figures come from a one-month window and are a snapshot. A campaign, a new hero image or an additional script can explain the result of a single month. A public list of poorly rated websites would therefore be a claim about the state of an organization that the data does not support.
How often is the study renewed?
Quarterly, with the latest data month in each case. The time series grows with it, so changes can be tracked over years. Each edition has its own version so that figures from different editions remain distinguishable.
AEM benchmark data: reuse and citation
The processed data is available as a file, without registration and without a form.
- All metrics as JSON, including the time series over 32 months
- Aggregated values as CSV for further processing in a spreadsheet
| Version | Data as of | Published | Passed, mobile | Websites |
|---|---|---|---|---|
| 2026-Q3 | August 2026 | 15 September 2026 | 49.4% | 4,222 |
The study is published quarterly at this address. Older editions are not mirrored; the data status stated above is authoritative, and the changelog records what applied before.
Suggested citation: Schreiber, Christian: AEM Core Web Vitals Benchmark 2026 for the DACH region, version 2026-Q3, ch-schreiber.net, data as of August 2026.
Benchmark your own AEM platform: real-user data compared with two competitors
In the free initial performance analysis, the entry point to Web Performance Consulting, you see the real-user data of your platform compared with two competitors of your choice, separated into response time and frontend, and learn which of the two parts is decisive in your case.
Book a free performance analysis
30 minutes by video, no preparation required on your part. You receive the analysis whether or not a project follows.