Magnolia Headless Plan delivery endpoints, rendering strategy and JavaScript bundles so that load time and responsiveness improve instead of getting worse

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

Magnolia can deliver pages in the classic way or run as a headless system with a separate frontend. The architecture is clean, but responsibility for the Core Web Vitals only moves: from the templates of the public instance to delivery endpoints, rendering strategy and the JavaScript bundle of the frontend. This page describes where a headless project with Magnolia gains or loses performance and which requirements should be set before the first sprint.

Magnolia websites with a detected frontend framework perform worse in the benchmark

In the Magnolia CMS Core Web Vitals Benchmark 2026, 122 websites without a detectable frontend framework pass the Core Web Vitals at 68.0 percent, the 26 websites with a detected framework at 46.2 percent. The count includes websites whose homepage contains traces of React, Angular or Vue, regardless of whether the page is built in the browser or on the server. Fully decoupled frontends without Magnolia traces in the HTML are not detected by the fingerprint. For Interaction to Next Paint, both groups are in the green range at the median, at 136 versus 112 milliseconds; the larger gap is in the main content load time.

The framework group is small, and the correlation does not name a cause: teams that build their own frontend usually also build in more interaction. The figures do show, however, that a headless frontend does not improve the values by itself.

Magnolia Headless: delivery endpoints, GraphQL and a separate frontend

In headless mode, Magnolia delivers content as JSON via delivery endpoints configured in light modules, or via the GraphQL interface. The frontend, often built with React, Vue or Angular and a framework such as Next.js or Nuxt, fetches this content and builds the page from it. For editors, Magnolia provides editors that display the frontend in the familiar page editing view.

For performance, this adds three new places that matter: how fast and how often the endpoints respond, where the page is rendered and how much JavaScript reaches the browser.

Rendering strategy for Magnolia Headless: server, static or browser

• Rendering in the browser: the browser first loads the JavaScript, then calls the endpoints and only then builds the page. Largest Contentful Paint thus comes after two loading steps, and the delivered HTML is almost empty. Google does render JavaScript, but with a delay, and many other crawlers do not process it.
• Server-side rendering: the frontend generates the HTML per request on the server. The main content is in the HTML right away, but response time depends on every delivery endpoint call the page needs.
• Static generation with revalidation: pages are generated in advance or on the first request and cached, and regenerated after a publication. Response time equals a cache hit, and freshness depends on revalidation.

For content pages, server-side or static rendering is usually the better choice. The strategy should be decided per page type, not once for the whole platform.

Delivery endpoints: number of calls and caching of responses

In headless mode, a page often needs several calls: page content, navigation, footer and referenced content such as teasers or products. If these calls run one after another, their response times add up to the Time to First Byte of the page.

• Let the endpoint resolve references instead of loading them one by one.
• Run independent calls in parallel instead of in sequence.
• Cache endpoint responses in the Magnolia cache and in the CDN, with the same rules for parameters and invalidation as for pages. The basics are described in Magnolia Cache.

Revalidation after publication: webhooks instead of fixed expiry times

Statically generated pages need to know when content changes. Fixed expiry times are simple, but either serve outdated pages or regenerate pages more often than necessary. Since version 6.2.22, Magnolia DX Core offers a webhooks module that calls a URL on publication and unpublication, for example the revalidation in the frontend. The calls run asynchronously and are retried several times on failure, as described under Webhooks module. If an event is lost for good, the page stays outdated. An additional expiry time as a fallback is therefore part of the setup.

Hydration and JavaScript bundles: the price for responsiveness

Server-rendered pages also load the frontend JavaScript in the browser to make the page interactive. This hydration occupies the main thread, and inputs during that time have to wait. This directly affects Interaction to Next Paint.

• A JavaScript budget per page type, compressed transfer size and executed code.
• Components without interaction delivered without client-side JavaScript, where the framework allows it.
• Tag management, consent banner and third parties with a budget of their own, because they load in a headless frontend just as in classic delivery.

Images in the headless frontend: variants from Magnolia instead of originals

In headless mode, the endpoint often returns the URL of the original image, and the frontend loads it at full size. Magnolia generates image variants in defined sizes via the imaging module. The frontend should request these variants with suitable widths, load the image in the visible area with priority and specify width and height so the layout does not shift.

Headless requirements in the Magnolia specification

• Rendering strategy per page type, with justification.
• Maximum number and response time of endpoint calls per page, cache rules for the responses.
• Revalidation on publication with a fallback.
• JavaScript budget per page type, separated into frontend and third parties.
• Sign-off against field data of real visitors per page type, not against a lab value of the preview.

The complete wording is in the Magnolia Performance Requirements Template. How implementation partners and an independent sign-off work together is described in Performance Partner for Magnolia Agencies. All causes on Magnolia platforms are put in context under Magnolia CMS Performance.

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 Magnolia Headless