Magnolia Headless Delivery-Endpunkte, Rendering-Strategie und JavaScript-Bündel so planen, dass Ladezeit und Reaktionszeit besser werden statt schlechter

Von Christian Schreiber, Web Performance Consultant für Magnolia, aktualisiert am 1. November 2026

Magnolia lässt sich klassisch ausliefern oder als Headless-System mit einem eigenen Frontend betreiben. Die Architektur ist sauber, die Verantwortung für die Core Web Vitals wandert dabei aber nur: von den Templates der Public-Instanz zu Delivery-Endpunkten, Rendering-Strategie und JavaScript-Bündel des Frontends. Diese Seite beschreibt, an welchen Stellen ein Headless-Projekt mit Magnolia Performance gewinnt oder verliert und welche Anforderungen vor dem ersten Sprint feststehen sollten.

Magnolia-Auftritte mit erkanntem Frontend-Framework schneiden im Benchmark schlechter ab

Im Magnolia CMS Core Web Vitals Benchmark 2026 bestehen 122 Auftritte ohne erkennbares Frontend-Framework die Core Web Vitals zu 68,0 Prozent, die 26 Auftritte mit erkanntem Framework zu 46,2 Prozent. Erfasst sind Auftritte, deren Startseite Spuren von React, Angular oder Vue enthält, unabhängig davon, ob die Seite im Browser oder serverseitig aufgebaut wird. Vollständig entkoppelte Frontends ohne Magnolia-Merkmale im HTML erkennt der Fingerabdruck nicht. Bei der Interaction to Next Paint liegen beide Gruppen im Median im grünen Bereich, bei 136 gegenüber 112 Millisekunden; der größere Abstand liegt bei der Ladezeit des Hauptinhalts.

Die Gruppe mit Framework ist klein, und der Zusammenhang benennt keine Ursache: Wer ein eigenes Frontend baut, baut meist auch mehr Interaktion ein. Die Zahlen zeigen aber, dass ein Headless-Frontend die Werte nicht von selbst verbessert.

Magnolia Headless: Delivery-Endpunkte, GraphQL und ein eigenes Frontend

Im Headless-Betrieb liefert Magnolia Inhalte über Delivery-Endpunkte als JSON aus, konfiguriert in Light Modules, oder über die GraphQL-Schnittstelle. Das Frontend, häufig mit React, Vue oder Angular und einem Framework wie Next.js oder Nuxt gebaut, holt diese Inhalte ab und erzeugt daraus die Seite. Für die Redaktion stellt Magnolia Editoren bereit, die das Frontend in der gewohnten Seitenbearbeitung anzeigen.

Für die Performance zählen damit drei neue Stellen: wie schnell und wie oft die Endpunkte antworten, wo die Seite gerendert wird und wie viel JavaScript im Browser ankommt.

Rendering-Strategie für Magnolia Headless: serverseitig, statisch oder im Browser

• Rendering im Browser: Der Browser lädt erst das JavaScript, ruft dann die Endpunkte ab und baut erst danach die Seite auf. Der Largest Contentful Paint liegt damit hinter zwei Ladeschritten, und das ausgelieferte HTML ist fast leer. Google rendert JavaScript zwar nach, aber zeitversetzt, viele andere Crawler werten es nicht aus.
• Serverseitiges Rendering: Das Frontend erzeugt das HTML je Anfrage auf dem Server. Der Hauptinhalt steht sofort im HTML, die Antwortzeit hängt aber an jedem Aufruf der Delivery-Endpunkte, den die Seite braucht.
• Statische Erzeugung mit Revalidierung: Seiten werden vorab oder beim ersten Abruf erzeugt und zwischengespeichert, nach einer Veröffentlichung neu. Die Antwortzeit entspricht einem Cache-Treffer, die Aktualität hängt an der Revalidierung.

Für Inhaltsseiten ist serverseitiges oder statisches Rendering in aller Regel die bessere Wahl. Die Strategie gehört je Seitentyp entschieden, nicht einmal für die ganze Plattform.

Delivery-Endpunkte: Zahl der Aufrufe und Cache der Antworten

Eine Seite braucht im Headless-Betrieb oft mehrere Aufrufe: Seiteninhalt, Navigation, Fußbereich, referenzierte Inhalte wie Teaser oder Produkte. Laufen diese Aufrufe nacheinander, addieren sich ihre Antwortzeiten zur Time to First Byte der Seite.

• Referenzen im Endpunkt auflösen lassen, statt sie einzeln nachzuladen.
• Unabhängige Aufrufe parallel statt nacheinander ausführen.
• Antworten der Endpunkte im Cache von Magnolia und im CDN zwischenspeichern, mit denselben Regeln für Parameter und Invalidierung wie bei Seiten. Die Grundlagen dazu beschreibt Magnolia Cache.

Revalidierung nach Veröffentlichung: Webhooks statt fester Ablaufzeiten

Statisch erzeugte Seiten müssen erfahren, wann sich Inhalte ändern. Feste Ablaufzeiten sind einfach, liefern aber entweder veraltete Seiten oder erzeugen Seiten häufiger neu als nötig. Magnolia DX Core bietet seit Version 6.2.22 ein Webhooks-Modul, das bei Veröffentlichung und Rücknahme eine Adresse aufruft, etwa die Revalidierung im Frontend. Die Aufrufe laufen asynchron und werden bei Fehlern mehrfach wiederholt, beschrieben unter Webhooks module. Geht ein Ereignis endgültig verloren, bleibt die Seite veraltet. Eine zusätzliche Ablaufzeit als Rückfallebene gehört deshalb dazu.

Hydration und JavaScript-Bündel: der Preis für die Reaktionszeit

Auch serverseitig gerenderte Seiten laden im Browser das JavaScript des Frontends und machen die Seite damit interaktiv. Diese Hydration belegt den Hauptprozess, und Eingaben in dieser Zeit warten. Das wirkt direkt auf die Interaction to Next Paint.

• Ein Budget für JavaScript je Seitentyp, komprimiert übertragen und ausgeführt.
• Komponenten ohne Interaktion ohne clientseitiges JavaScript ausliefern, sofern das Framework das erlaubt.
• Tag-Verwaltung, Einwilligungsdialog und Drittanbieter mit eigenem Budget, weil sie im Headless-Frontend genauso laden wie in der klassischen Auslieferung.

Bilder im Headless-Frontend: Varianten aus Magnolia statt Originale

Im Headless-Betrieb gibt der Endpunkt häufig die Adresse des Originalbilds zurück, und das Frontend lädt es in voller Größe. Magnolia erzeugt über das Imaging-Modul Bildvarianten in definierten Größen. Das Frontend sollte diese Varianten mit passenden Breiten anfordern, das Bild im sichtbaren Bereich bevorzugt laden und Breite und Höhe angeben, damit sich das Layout nicht verschiebt.

Headless-Anforderungen im Magnolia-Lastenheft

• Rendering-Strategie je Seitentyp, mit Begründung.
• Höchstzahl und Antwortzeit der Endpunkt-Aufrufe je Seite, Cache-Regeln für die Antworten.
• Revalidierung bei Veröffentlichung mit Rückfallebene.
• Budget für JavaScript je Seitentyp, getrennt nach Frontend und Drittanbietern.
• Abnahme gegen Felddaten echter Besucher je Seitentyp, nicht gegen einen Laborwert der Vorschau.

Die vollständigen Formulierungen stehen in der Vorlage Performance-Anforderungen im Magnolia-Lastenheft. Wie Implementierungspartner und unabhängige Abnahme dabei zusammenarbeiten, beschreibt Performance-Partner für Magnolia-Agenturen. Alle Ursachen auf Magnolia-Plattformen ordnet Magnolia CMS Performance ein.

Kostenfreie Performance-Erstanalyse buchen

30 Minuten per Video. Sie erhalten die Google-Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern, unabhängig davon, ob wir zusammenarbeiten.

Häufige Fragen zu Magnolia Headless