# Performance-Anforderungen im Magnolia-Lastenheft

English version: https://ch-schreiber.net/downloads/magnolia-performance-requirements.md

Vorlage für Ausschreibung, Lastenheft und Implementierungsvertrag von Magnolia CMS-Projekten.

Quelle: Christian Schreiber, ch-schreiber.net, https://ch-schreiber.net/magnolia-performance-anforderungen

Lizenz: Creative Commons Namensnennung 4.0 (CC BY 4.0), https://creativecommons.org/licenses/by/4.0/deed.de

Werte in eckigen Klammern sind Platzhalter. Ausgangspunkt sind die Grenzwerte von Google für "gut". Zielwerte gelten je Seitentyp, gemessen im 75. Perzentil der Felddaten auf Mobilgeräten.

## Anforderung 1: Zielwerte je Seitentyp aus echten Nutzerdaten

**Anforderung:** 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

**Anforderung:** 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

**Anforderung:** 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

**Anforderung:** 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

**Anforderung:** 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

**Anforderung:** 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

**Anforderung:** 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.