Performance-Anforderungen im Magnolia-Lastenheft Vorlage mit sieben Anforderungen für Magnolia CMS-Projekte, frei nutzbar unter CC BY 4.0

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

Die meisten Performance-Probleme einer Magnolia CMS-Plattform entstehen in der Implementierung und fallen erst nach dem Livegang auf. Der Grund ist selten fehlendes Können, sondern ein Lastenheft ohne messbare Anforderungen an die Geschwindigkeit: Was nicht gefordert ist, wird nicht umgesetzt und nicht abgenommen. Diese Vorlage enthält sieben Anforderungen mit Abnahmekriterium für Ausschreibung, Lastenheft und Implementierungsvertrag von Magnolia CMS-Projekten.

Werte in eckigen Klammern sind PlatzhalterVorlage als Markdown herunterladen

Vorlage verwenden: Platzhalter je Seitentyp ausfüllen

Jede Anforderung besteht aus einer Formulierung für das Lastenheft und einem Abnahmekriterium. Werte in eckigen Klammern sind Platzhalter. Ausgangspunkt sind die Grenzwerte von Google für "gut"; strengere Werte sind für Seitentypen sinnvoll, die viel Umsatz tragen, etwa Formularstrecken. Werte, die die bestehende Plattform heute schon besser erreicht, gehören als Ausgangswert ins Lastenheft, damit sich die Plattform durch das Projekt nicht verschlechtert.

Anforderung 1: Zielwerte je Seitentyp aus echten Nutzerdaten

Formulierung für das Lastenheft: Für die Seitentypen [Startseite, Übersichtsseite, Detailseite, Formular] gelten auf Mobilgeräten im 75. Perzentil der Felddaten: Largest Contentful Paint höchstens [2,5] Sekunden, Interaction to Next Paint höchstens [200] Millisekunden, Cumulative Layout Shift höchstens [0,1]. Die Zielwerte gelten je Seitentyp, nicht je Domain. Ein Lighthouse-Punktwert ist kein Zielwert.

Abnahmekriterium: Die Werte werden nach dem Livegang über 28 Tage in den Felddaten des Chrome User Experience Report oder eines Real User Monitoring je Seitentyp nachgewiesen. Vor dem Livegang dient eine Labormessung unter festgelegten Bedingungen als Vorabprüfung.

Anforderung 2: Antwortzeit des Servers und Cache-Strategie

Formulierung für das Lastenheft: Die Time to First Byte liegt im 75. Perzentil bei höchstens [800] Millisekunden. Der Cache vor den Public-Instanzen beantwortet anonyme Zugriffe je Seitentyp zu mindestens [Wert] Prozent. Parameter ohne Einfluss auf den Inhalt erzeugen keine eigene Cache-Variante, für anonyme Besucher entstehen keine Sitzungen, und eine Veröffentlichung invalidiert nur die betroffenen Pfade.

Abnahmekriterium: Trefferquote und Antwortzeit werden je Seitentyp aus den Protokollen von Cache und CDN nachgewiesen, die Invalidierung an einem Testfall mit Veröffentlichung.

Anforderung 3: Budget für JavaScript und CSS je Seitentyp

Formulierung für das Lastenheft: Ressourcen der Light Modules und Theme-Dateien werden je Seitentyp gebündelt. Je Seitentyp werden höchstens [Wert] KB JavaScript und [Wert] KB CSS komprimiert geladen; der Teil für den sichtbaren Bereich ist vom Rest getrennt, Skripte für spätere Interaktionen laden verzögert. Bei Headless-Frontends wird die erste Ansicht serverseitig erzeugt.

Abnahmekriterium: Die Größen werden je Seitentyp in der Auslieferungskette gemessen; ein Build, der das Budget überschreitet, wird abgelehnt.

Anforderung 4: Bildauslieferung und Layoutstabilität

Formulierung für das Lastenheft: Bildvarianten des Imaging-Moduls werden vorab in mindestens [Anzahl] Breiten und modernen Formaten erzeugt statt beim ersten Abruf. Jedes Bild trägt Höhe und Breite im Markup. Das größte Bild im sichtbaren Bereich wird bevorzugt geladen und nie verzögert.

Abnahmekriterium: Stichprobe je Seitentyp im Labor, Layoutverschiebungen im Feld unter dem Zielwert aus Anforderung 1.

Anforderung 5: Freigabe für Tags und Drittanbieter

Formulierung für das Lastenheft: Tags, Personalisierungsdienste und jedes weitere Skript aus Tag Manager, Einwilligungsdialog, Analyse- oder Testwerkzeug werden vor dem Livegang gegen das Performance-Budget geprüft und freigegeben. Die Zahl gleichzeitig aktiver Segmente der Personalisierung je Seitentyp ist auf [Anzahl] begrenzt. Der Einwilligungsdialog verschiebt keinen Inhalt.

Abnahmekriterium: Ein Inventar aller Drittanbieter-Skripte mit Blockierzeit in Millisekunden liegt bei Abnahme vor und wird je Release fortgeschrieben.

Anforderung 6: Messung im Betrieb ab dem Livegang

Formulierung für das Lastenheft: Vor dem Livegang ist ein Real User Monitoring je Seitentyp, Markt und Gerät eingerichtet, ergänzt um Trefferquote des Caches und Antwortzeit der Public-Instanzen. Daneben werden die Felddaten des Chrome User Experience Report monatlich gegen die Zielwerte geprüft.

Abnahmekriterium: Die Messung liefert vor dem Livegang Werte für alle Seitentypen aus Anforderung 1.

Anforderung 7: Abnahme je Meilenstein durch eine unabhängige Stelle

Formulierung für das Lastenheft: Jeder Meilenstein und jedes Release wird gegen die Zielwerte aus Anforderung 1 bis 6 abgenommen, von einer Stelle, die die Umsetzung nicht selbst verantwortet. Verfehlte Zielwerte führen zu priorisierten Aufgaben mit Abnahmekriterien. Das gilt auch für den Wechsel von DX Core auf DX Cloud und auf ein Headless-Frontend.

Abnahmekriterium: Ein Abnahmeprotokoll je Meilenstein nennt Messwert, Zielwert und Quelle je Seitentyp.

Download: Magnolia-Vorlage als Markdown unter CC BY 4.0

Die Vorlage als Markdown-Datei enthält alle sieben Anforderungen mit Platzhaltern zum Einfügen in Lastenheft, Ausschreibung oder Angebot. Sie steht unter der Lizenz Creative Commons Namensnennung 4.0: Auftraggeber, Agenturen und IT-Dienstleister dürfen sie verwenden und anpassen, auch in kommerziellen Angeboten, mit der Quellenangabe "Christian Schreiber, ch-schreiber.net".

Anforderungen werden zu beauftragten Tickets für den Magnolia-Implementierungspartner

Ohne Anforderungen im Lastenheft wird Performance nach dem Livegang zur unbezahlten Nacharbeit oder zum Streitpunkt zwischen Auftraggeber und Implementierungspartner. Mit ihnen wird sie zu beauftragter, abnehmbarer Arbeit. Wie die Zusammenarbeit aussieht, steht unter Performance-Partner für Magnolia-Agenturen; die technischen Ursachen beschreibt Magnolia CMS Performance, den Ablauf einer Optimierung Website Performance Optimierung.

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 Performance-Anforderungen im Magnolia-Lastenheft