Magnolia CMS benchmark, data as of August 2026, version 2026-Q3
Magnolia CMS Core Web Vitals Benchmark 2026 172 verified installations in the DACH region, measured for the first time
Magnolia CMS does not appear in any public technology statistic. The detection on which all market analyses are based does not recognize the system, so neither adoption figures nor performance values exist for Magnolia. This study closes the gap: 46,394 domains were checked one by one, 172 Magnolia installations were verified, and for 148 of them Google's real-user data was evaluated.
- 64.2 percent of Magnolia websites with sufficient real-user data pass the Core Web Vitals on mobile devices.
- The main content becomes visible after a median of 1.8 seconds; the median server response time is 668 milliseconds.
- For 78.8 percent of the websites with a slow main content load time, the server response time alone is already too high.
- In Switzerland there are 15.1 Magnolia websites per 1,000 domains checked, in Germany 3.0.
- Among the websites that fail, 62.3 percent miss the threshold for the main content load time (LCP).
Book a free performance analysis
30 minutes by video. You see where your Magnolia platform stands in this distribution and which cause dominates in your case.
- Survey conducted independently, because no public source covers Magnolia CMS
- Every verification is based on publicly visible markers in the homepage source code
Magnolia is missing from public statistics because technology detection does not recognize the system
The gap is technical in nature and says nothing about how widely the system is used.
Market statistics rely on detection patterns, and there are none for Magnolia
Every statement about the market share of content management systems is based on a set of publicly maintained detection patterns. A crawler loads millions of homepages and checks whether typical traces of a system appear in the source code. Such patterns exist for WordPress, Sitecore or Adobe Experience Manager. For Magnolia CMS there are none. The system therefore appears in no aggregate analysis, regardless of how many websites run on it.
Magnolia verification via the /.imaging/ and /.resources/ paths
Magnolia delivers images via the imaging module under /.imaging/ and the theme files of light modules under /.resources/. In addition, there are page editor markers such as mgnlEditor. These paths appear in the source code of every delivered page and can be checked with a single request to the homepage. Of 35,964 reachable domains, 172 carry these markers, 168 of them unambiguously.
The figure is a lower bound, not a market size. It only covers domains from the ranking checked, only websites whose resource paths remain visible from outside, and only homepages. Websites running Magnolia behind a headless frontend or a content delivery network with rewritten paths do not appear here. For operators, this is a double disadvantage: there are no benchmark figures against which to measure their own platform, and there are no studies on which a budget request could be based.
Magnolia adoption: Switzerland is the core market
Measured against the domains checked per country, so that the different sizes of the country lists do not distort the picture.
Per 1,000 reachable domains, there are 15.1 Magnolia websites in Switzerland, 6.9 in Austria and 3.0 in Germany. In absolute numbers, these are 60 Swiss, 26 Austrian and 84 German websites. The vendor is based in Basel, and this is clearly reflected in the distribution: in relative terms, the system is several times as widespread in Switzerland as in Germany.
The composition stands out. The verified installations include public transport operators, cantonal and municipal administrations, universities, insurers and energy utilities. This is the class of websites that is operated over many years, carries several languages and has its content maintained by many editorial teams. For the assessment of the Core Web Vitals this matters, because such websites have different load profiles than ad-funded portals.
64.2 percent of Magnolia websites pass, and LCP is decisive
A website passes the Core Web Vitals only if all three metrics are in the green range. For comparison: across all recorded websites in the three countries, the figure is 68.7 percent.
Largest Contentful Paint: main content load time
77.7 percent meet the threshold of 2.5 seconds; the median is 1.8 seconds. On Magnolia websites, the largest element in the initial viewport is almost always an image from the imaging module. Its variants are generated on the first request and cached afterwards, which puts the first visitor to a rarely requested page at a clear disadvantage compared with all subsequent ones.
Interaction to Next Paint: response time to input
91.0 percent stay below 200 milliseconds; the median is 118 milliseconds. This metric measures how long the page takes to respond visibly to a click. It rises with the amount of JavaScript on the main thread, that is, with the tag manager, the consent banner and, frequently on Magnolia, with individual interactive components embedded in the page as separate applications.
Cumulative Layout Shift: layout stability
85.8 percent are below 0.1; the median is 0.00. The metric measures how much content shifts during loading. Where this value fails, the cause is usually components loaded later without reserved dimensions, such as notice bars, promotional badges and personalized areas that are inserted only after the initial render.
The page cache decides: for 78.8 percent of slow websites, the server already responds too late
Magnolia renders pages in Java and delivers them via an upstream cache. Whether a request is answered in milliseconds or in seconds is therefore decided before the browser. The real-user data contains this value as the server response time, which makes it possible to separate the causes.
26 of 33 slow Magnolia websites already respond too late on the server
Of 33 websites with a slow main content load time, 26 already have a server response time that is too high, with a median of 1,668 milliseconds. For the remaining 7, the server responds after 474 milliseconds, so the delay only occurs afterwards. Across all websites checked, 57.4 percent keep the response time in the good range.
Magnolia cache: every additional variant lowers the cache hit ratio
A high response time usually means that the request misses the cache and the public instance renders the page again. The hit ratio drops with every dimension that creates its own variant: language, country, personalization segment, parameters from campaign links. In multisite setups with many variants, this creates tens of thousands of entries, most of which are never requested a second time. The cache then exists formally but has no practical effect.
In practice, this means: the cache hit ratio should be measured, not assumed, per page type and market. A ratio below 80 percent on pages that rarely change is an operations finding, not a frontend issue. Only once the response time is under control does work on image variants, fonts and scripts pay off.
Websites with an SPA frontend pass 21.9 points less often
Magnolia renders on the server. Some websites put a frontend built with React, Angular or Vue in front of it, which builds the page only in the browser. The separate crawl detects this through signatures in the delivered HTML, so both groups can be evaluated separately.
SPA websites fall behind mainly in input responsiveness
122 websites deliver without a recognizable framework and pass at a rate of 68.0 percent; the 26 websites with a detected framework pass at 46.2 percent. The gap goes hand in hand above all with input responsiveness: a median of 136 versus 112 milliseconds, and 88.0 versus 91.6 percent meet the threshold of 200 milliseconds.
Significance of the comparison: enough for two groups, too little per framework
The group with a detected framework comprises 26 websites. That is enough to compare the two groups but too small for a statement per framework. Only what remains visible in the delivered HTML is detected; a setup that rewrites the resource paths counts toward the server-side group here. The correlation also does not name a cause: organizations that use an SPA frontend usually build more interaction into it as well.
In practice, this means: an SPA frontend in front of Magnolia shifts work into the browser and makes input responsiveness the leading metric. Where this route is chosen, INP per page type belongs in the sign-off, on an equal footing with the main content load time.
Magnolia websites by industry: response time and load time point to different causes
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 |
|---|---|---|---|---|
| Banks and financial services | 14 | 92.9% | 1.6 s | 649 ms |
| Public sector | 15 | 73.3% | 1.3 s | 550 ms |
| Media and culture | 10 | 70.0% | 1.9 s | 580 ms |
| Consumer goods and retail | 18 | 55.6% | 2.2 s | 712 ms |
| Transport and logistics | 15 | 53.3% | 1.5 s | 499 ms |
| Insurance | 15 | 46.7% | 2.0 s | 899 ms |
The best group, Banks and financial services, reaches 92.9 percent; the weakest group, Insurance, reaches 46.7 percent, a range of 46.2 percentage points. To benchmark your own platform, compare it within your own industry, because the requirements for interactivity and for embedded third-party services are similar there.
The last two columns are more revealing than the ranking. Where the response time is low and the main content still appears late, the delay lies in the browser, that is, in images, fonts and scripts; the cache layer is already working well there. Where, conversely, the response time is already above the threshold, the hit ratio of the page cache is the first problem area, and work on the frontend would have no visible effect. Both patterns occur in this table, and they require opposite measures.
The assignment is based on patterns in the domain name. Of 148 websites, 87 are in the reported groups. Another 38 are spread across industries below the minimum size of 10 websites, and 22 match no pattern. Both parts are left out, so the table describes the groups listed and not the entire study.
The fastest Magnolia 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.nmbs.ch | Transport and logistics | 0.6 s | 64 ms | 217 ms |
| www.landgard.de | Consumer goods and retail | 0.8 s | 78 ms | 341 ms |
| www.mvg.de | Transport and logistics | 0.8 s | 141 ms | 310 ms |
| www.musik-akademie.ch | Universities and research | 0.9 s | 89 ms | 433 ms |
| www.oekb.at | Banks and financial services | 0.9 s | 69 ms | 304 ms |
| www.sympany.ch | Insurance | 0.9 s | 85 ms | 303 ms |
| www.iwb.ch | Energy and utilities | 0.9 s | 104 ms | 359 ms |
| www.prosenectute.ch | Associations and unions | 1.0 s | 112 ms | 500 ms |
| stadtzug.ch | Public sector | 1.0 s | 85 ms | 531 ms |
| zg.ch | Public sector | 1.0 s | 92 ms | 481 ms |
The last column is the most revealing. The websites on this list consistently deliver the first byte well below the threshold. On a server-side rendered platform, a working cache layer is therefore not a sufficient condition for green values, but in practice it is a necessary one.
Four steps for Magnolia platforms: cache hit ratio first
Four steps, in this order, derived from the distribution of causes in this study.
Measure the cache hit ratio per page type
The most frequent finding of this study lies before the first byte, that is, in the Time to First Byte. A useful step is an analysis of cache hits broken down by page type and market, combined with the question of which dimension creates the most variants. Often it is a single one: a parameter from campaign links that makes every URL unique and thus prevents every hit.
Set an upper limit for personalization
Every variant served on the server side creates its own cache entry. A practical approach is a fixed upper limit for simultaneously active segments per page type, combined with the rule that personalized components have reserved dimensions. Without both, personalization grows from campaign to campaign until the cache has no effect and layout stability suffers at the same time.
Generate image variants in advance instead of on the first request
The imaging module generates variants on demand. For rarely requested pages, this means the first visitor regularly pays for the generation, and exactly this request ends up in the real-user data. Where the variants are generated and delivered in advance after publication, part of the spread in the main content load time disappears.
Target values per page type and sign-off of every release
Google calculates the values from a rolling 28-day window, so deteriorations become visible with a delay. To keep the values, agree on target values per page type and check against a performance budget before go-live. This applies regardless of whether the platform runs on 6.2, is updated to 6.4 or moves to the DX Cloud.
What these steps mean for cache, light modules and personalization is described on the page Magnolia CMS Performance. 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 Magnolia Performance Requirements Template and Performance Partner for Magnolia Agencies.
Methodology of the Magnolia benchmark: separate crawl and real-user data from the Chrome UX Report
The study was produced on 15 September 2026 with the data month August 2026.
Candidates from the Majestic Million and verification per domain
The basis is the Majestic Million ranking, filtered to the endings de, at and ch and supplemented by large websites under com addresses. Of 46,394 domains, 35,964 were reachable. Each was requested once on the homepage and checked for the markers of Magnolia. A website counts as unambiguous if it delivers paths of the imaging module, the resources module or page editor markers.
Measurements from the Chrome UX Report, mobile and desktop
For each verified website, the real-user data from the Chrome UX Report was queried, separately for mobile and desktop: main content load time, input responsiveness, layout stability, first contentful paint and server response time, each at the 75th percentile over 28 days. Mobile values are available for 148 of the 172 websites; the rest lack the traffic required.
Thresholds: LCP 2.5 seconds, INP 200 milliseconds, CLS 0.1
The assessment follows Google's thresholds: 2.5 seconds for the main content load time, 200 milliseconds for input responsiveness, 0.1 for layout stability. 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 separates operations from the frontend.
Limits of the Magnolia study: a sample, not a full census
The figures are based on a purpose-built sample, not on a full census, and therefore cannot be equated with the aggregate values of other systems. Installations behind headless frontends or rewritten resource paths are missing. A website does not equal a company. All relationships are observations, not causes.
Sources: Chrome UX Report, retrieved on 15 September 2026. The candidate list Majestic Million is licensed under Creative Commons Attribution 3.0. The reference value across all websites comes from the HTTP Archive Technology Report API.
Frequently asked questions about the Magnolia CMS Core Web Vitals Benchmark
Five points that come up regularly with this type of study.
Why does technology detection not recognize Magnolia?
Because nobody has submitted a detection pattern for it. The signature set on which all market statistics are based is publicly maintained and grows through contributions. For widely used systems this happens early; for systems with few but large installations, often not at all. The gap is therefore a side effect of visibility, not a judgment on the quality of the system.
The pages are cached. Why do the Core Web Vitals 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 hit after 80 milliseconds helps little if two megabytes of JavaScript are loaded afterwards. Conversely, this study shows that for the majority of slow websites the cache precisely does not take effect, because the response time is already too high.
Does a headless frontend in front of Magnolia deliver better values?
Not by itself. The response time then depends on the delivery APIs and on the number of requests per page, the main content load time on whether the first view is generated on the server, and the input responsiveness on the size of the delivered JavaScript bundle. In practice, this bundle turns out larger in headless projects than what the classic delivery would have needed.
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. Since the survey runs anew each time, the number of verified installations is expected to keep growing. Each edition has its own version so that figures from different editions remain distinguishable.
Magnolia benchmark data: reuse and citation
The processed data is available as a file, without registration and without a form.
- All metrics as JSON
- 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 | 64.2% | 148 |
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: Magnolia CMS Core Web Vitals Benchmark 2026 for the DACH region, version 2026-Q3, ch-schreiber.net, data as of August 2026.
Benchmark your own Magnolia 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.