Core Web Vitals Benchmark for the DACH Region Two studies from Google field data, with open datasets and a disclosed methodology
No general statistic shows how fast the websites of an industry or a content management system actually are. The studies published here close this gap for two enterprise systems in the German-speaking region: they check 46,394 domains for the system in use and evaluate the Core Web Vitals of the websites found, based on field data from the Chrome User Experience Report (CrUX). Data as of August 2026, version 2026-Q3.
Survey of 15 September 2026Germany, Austria and Switzerland
Two benchmarks: Adobe Experience Manager and Magnolia CMS
Both studies follow the same methodology and can therefore be read side by side. They differ in their starting point: for Adobe Experience Manager there is a large population with public detection, while for Magnolia CMS no figures existed at all before this study.
AEM Core Web Vitals Benchmark 2026
4,222 websites on Adobe Experience Manager in the DACH region, of which 49.4 percent pass all three Core Web Vitals on mobile devices. Supplemented by a separate crawl that determines the AEM generation of each website: 28.8 percent still deliver via the paths of the generations up to 6.3, 61 websites via Edge Delivery Services.
Magnolia CMS Core Web Vitals Benchmark 2026
172 verified Magnolia installations, 148 of them with real-user data available. 64.2 percent pass the Core Web Vitals on mobile devices. Magnolia does not appear in any public technology statistic because the common detection does not recognize the system; the installations were therefore verified one by one.
The consulting services for both systems are described on the platform pages for Adobe Experience Manager Performance and Magnolia CMS Performance.
Measured values are LCP, INP and CLS, not scores
The Core Web Vitals are three metrics that Google derives from the behavior of real visitors. Largest Contentful Paint measures the load time of the largest visible content element; the threshold for "good" is 2.5 seconds. Interaction to Next Paint measures the time between an input and the visible response; the threshold is 200 milliseconds. Cumulative Layout Shift measures visual stability; the threshold is 0.1. A website passes if all three values at the 75th percentile are below their thresholds.
A score from a lab tool does not appear in these studies. It is a snapshot of a simulated device and does not answer what visitors experience. Instead, the studies evaluate per metric how many websites are in the green range and, for those that fail, which metric is decisive.
Field data from the Chrome User Experience Report as the source
The basis is the Chrome User Experience Report, CrUX for short: in it, Google publishes per origin the measurements of real Chrome users over the last 28 days. This field data is the same yardstick Google uses to assess a website, and it differs systematically from lab data from PageSpeed Insights or Lighthouse, which measure without a tag manager, without a consent banner and on simulated hardware.
This has two consequences for the evaluation. First, only websites with sufficient traffic appear, so small websites are missing. Second, every change takes effect with a delay because the 28-day window lags behind. For an assessment of a live platform, real user monitoring that collects the same metrics daily therefore belongs alongside it.
Methodology: detection, data retrieval, minimum group sizes
The study runs in three steps. First, a domain list is checked for the system in use, for this edition 46,394 domains, of which 35,964 were reachable. Detection relies on delivery paths and signatures, not on self-reported information. Next, the field data for the websites found is retrieved per origin, separately for mobile and desktop. Finally, groups are formed by country and industry; groups below a minimum size are reported but not interpreted.
Whether a slow page is a matter of operations or of the frontend is decided by the breakdown of the load time: if the server response time is already above the threshold, the work starts in operations. This attribution is the same in both studies and makes them comparable.
Result of both studies: the cause usually lies in operations, not in the frontend
For websites with a main content load time that is too slow, the cause lies mostly in operations: 80.3 percent for Adobe Experience Manager, 78.8 percent for Magnolia CMS. The median server response time is 666 milliseconds for AEM and 668 milliseconds for Magnolia, a nearly identical value for two different systems.
The bottleneck in both cases is the main content load time (LCP). In input responsiveness both systems perform well: 83.4 percent for AEM and 91.0 percent for Magnolia are in the green range. This finding determines the order of work: cache layer and response time first, frontend afterwards.
Open datasets: every benchmark figure can be recalculated
Each study comes with the evaluated data as JSON and as CSV, published under Creative Commons Attribution 4.0. This makes every figure in the studies verifiable, and the data can be reused for your own analyses.
- AEM: benchmark.json and benchmark.csv
- Magnolia CMS: benchmark.json and benchmark.csv
The sources of the raw data are the Chrome User Experience Report for the measurements and a domain list from publicly available rankings for the selection of the websites checked. The license is available from Creative Commons.
Quarterly benchmark update at a permanent address
Both studies are surveyed again every quarter; the current edition is version 2026-Q3. The addresses stay the same, the figures are replaced, and changes compared with the previous edition are reported in the studies. If you cite a specific edition, state the version.
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.
Frequently asked questions about the Core Web Vitals Benchmark
Where do the measurements in these benchmarks come from?
From the Chrome User Experience Report. In it, Google publishes per origin the Core Web Vitals of real Chrome users from a rolling 28-day window. The 75th percentile is evaluated, separately for mobile and desktop. Values from lab tools such as PageSpeed Insights or Lighthouse are not included because they are produced without a tag manager, without consent and on simulated hardware.
How is the system a website uses detected?
Through a separate request per domain that evaluates delivery paths and signatures, not through self-reported information or third-party technology databases. For this edition, 46,394 domains were checked, 35,964 of which were reachable. For Magnolia CMS this step is the precondition for the study in the first place, because the common detection does not recognize the system.
Why do so few websites pass the Core Web Vitals?
Because all three values must be below their thresholds at the same time. Viewed individually, the values are considerably better: for Adobe Experience Manager, 80.5 percent are in the green range for main content load time and 83.8 percent for layout stability. Usually a single metric is decisive, and in both studies that is the main content load time.
Can the figures be compared with other studies?
Only on the same basis. Analyses differ in their source, their percentile, their device type and in whether they count origins or individual pages. These studies state all four points and publish the datasets, so a review is possible. A comparison with a study that does not disclose its methodology leads nowhere.
How often are the benchmarks updated?
Quarterly. The current edition is version 2026-Q3 with data as of August 2026. The addresses of the studies stay the same across editions, and changes compared with the previous edition are reported in the studies.