Magnolia CMS speed statistics: 32 websites measured
Updated
Magnolia is a Java-based enterprise CMS, common at insurers, banks, universities and public authorities. Pages are usually rendered on the server and delivered through Magnolia's own page cache or a CDN, so a well-configured Magnolia site starts from a good position. Speed problems tend to come from what is added around the CMS, not from the core.
By Core Web Vitals pass rate, Magnolia CMS ranks first of seven platforms with their own page, ahead of Drupal. Clearest advantage over all measured websites: JavaScript (median), 766 KB against 1.5 MB.
Core Web Vitals on Magnolia CMS
59% of the 32 measured Magnolia CMS websites pass all three Core Web Vitals with real-user data. Across all measured websites the figure is 46%.
| Metric | Good | Median | Middle half | Threshold |
|---|---|---|---|---|
| LCP | 72% | 1667 ms | 1292 ms – 2646 ms | 2500 ms |
| INP | 97% | 118 ms | 86 ms – 153 ms | 200 ms |
| CLS | 78% | 0.03 | 0.00 – 0.09 | 0.10 |
Median mobile Lighthouse score: 55. Why lab score and field data diverge is explained in the Website Speed Statistics.
Who runs Magnolia CMS in this sample
Magnolia sites in this sample come mostly from insurers, health insurance funds, banks, universities and public authorities in Europe. These are large, regulated sites with many content types, login areas and forms, run by in-house teams or agencies on a shared enterprise platform.
How to read your own Magnolia CMS values
Compare your values with the median of this sample rather than with consumer sites, since these sites carry more consent, tracking and form logic. Time to first byte shows whether anonymous visitors are served from the cache. If the homepage is fast but product or service pages are slow, the gap usually lies in personalised components or third-party scripts on those templates.
More metrics: TTFB, FCP, TBT and Speed Index
Thresholds and sources: Website Speed Statistics.
| Metric | Source | Good | Magnolia CMS median | All websites median | Threshold |
|---|---|---|---|---|---|
| Time to First Byte | Field data | 52% | 664 ms | 707 ms | 800 ms |
| First Contentful Paint | Field data | 59% | 1517 ms | 1577 ms | 1800 ms |
| Total Blocking Time | Lab | 50% | 183 ms | 635 ms | 200 ms |
| Speed Index | Lab | 3% | 7709 ms | 8703 ms | 3400 ms |
Page weight and third-party code
A Magnolia CMS home page transfers 2.7 MB at the median, of which 766 KB is JavaScript. 88% load third-party code, from a median of three providers.
| Provider | Share | Main thread (median) |
|---|---|---|
| Google Tag Manager | 34% | 254 ms |
| Usercentrics CMP | 31% | 201 ms |
| OneTrust (Optanon) | 28% | 104 ms |
| Google Analytics | 19% | < 1 ms |
| Google Maps | 16% | 105 ms |
| Meta (Facebook) | 9% | 292 ms |
Most common lab findings
| Finding | Share | Saving (median) |
|---|---|---|
| Render-blocking resources | 100% | 5735 ms |
| Unused JavaScript | 100% | 1250 ms |
| Unused CSS | 72% | 310 ms |
| Images not properly sized | 69% | 1108 ms |
| Images not in next-gen formats | 56% | 1622 ms |
Typical Magnolia CMS performance bottlenecks
Time to first byte rises when personalised or uncached pages bypass the cache, which is common on sites with logins, calculators or form flows. Images from the Magnolia DAM are often delivered in larger renditions than the layout needs if the imaging variants are not tuned. On sites of this type, consent managers, tag managers and chat widgets are the usual reason for a slow INP, because they load early on every page.
Related guides: Time to First Byte (TTFB) · Properly size images · Interaction to Next Paint (INP)
Magnolia CMS by industry in this sample
- Finance and insurance: 63%
- Health and medical: 13%
- Telecommunications: 6%
- Education: 6%
Other platforms
How does your Magnolia CMS site compare?
Run a free test and put your values next to the Magnolia CMS median.