Core Web Vitals Abnahmekriterien Ticket-Vorlagen mit Definition of Done für LCP, INP, CLS und TTFB, zum Übernehmen in Jira oder Azure DevOps
Ein Performance-Ticket ohne Abnahmekriterium endet in einer Diskussion über Lighthouse-Punkte. Die Vorlagen auf dieser Seite machen aus jeder Kennzahl eine Aufgabe, die ein Entwicklerteam umsetzen und eine unabhängige Stelle abnehmen kann: mit Ausgangswert, Zielwert je Seitentyp, Prüfung vor dem Merge, Nachweis in den Felddaten nach dem Livegang und einer Definition of Done für jedes Release.
Werte in eckigen Klammern sind PlatzhalterVorlagen als PDF herunterladen
Abnahmekriterien für Core Web Vitals: Grenzwerte, Perzentil und Messfenster
Google bewertet die Core Web Vitals im 75. Perzentil der Besuche, getrennt nach Mobilgeräten und Desktop, über ein gleitendes Fenster von 28 Tagen. Ein Abnahmekriterium übernimmt diese drei Festlegungen, sonst misst es etwas anderes als Google. Die Grenzwerte stammen von web.dev, für die Time to First Byte von web.dev/articles/ttfb.
| Kennzahl | Gut | Schlecht | Im Labor |
|---|---|---|---|
| Largest Contentful Paint | bis 2,5 s | über 4 s | messbar |
| Interaction to Next Paint | bis 200 ms | über 500 ms | nur mit ausgeführter Interaktion, Total Blocking Time als Näherung |
| Cumulative Layout Shift | bis 0,1 | über 0,25 | im Navigationsmodus nur die Ladephase |
| Time to First Byte | bis 800 ms | über 1,8 s | messbar |
Daraus folgt der Aufbau jeder Vorlage: Eine Labormessung unter festgelegten Bedingungen prüft vor dem Merge, ob die Änderung in die richtige Richtung wirkt. Abgenommen wird erst mit den Felddaten nach dem Livegang. Wie sich beide Quellen unterscheiden, beschreibt Core Web Vitals messen.
Aufbau der Ticket-Vorlagen: Ausgangswert, Zielwert, Prüfung und Nachweis
- Ticket-Titel mit Seitentyp, Kennzahl und Zielwert. Ein Ticket gilt für einen Seitentyp, nicht für die ganze Plattform.
- Kontext mit dem gemessenen Ausgangswert, seiner Quelle und dem Datum. Ohne Ausgangswert ist eine Verbesserung nicht belegbar.
- Akzeptanzkriterien vor dem Merge aus dem Labor und aus Prüfungen am Code, die das Team selbst ausführen kann.
- Akzeptanzkriterien nach dem Livegang aus den Felddaten, mit 28 Tagen Abstand.
- Nachweis, der dem Ticket angehängt wird, damit die Abnahme ohne Rückfrage möglich ist.
Ticket-Vorlage Largest Contentful Paint: LCP-Element benennen, Ladeweg verkürzen
Ticket-Titel: [Seitentyp]: Largest Contentful Paint mobil auf höchstens [2,5] Sekunden im 75. Perzentil
Kontext: Ausgangswert im 75. Perzentil mobil: [Wert] Sekunden laut [Chrome User Experience Report oder Real User Monitoring], Stand [Datum]. LCP-Element auf diesem Seitentyp: [Bild, Überschrift oder Textblock]. Referenz-URLs: [Liste].
LCP vor dem Merge: LCP-Element, Bildgröße und Labormessung
- Das LCP-Element des Seitentyps ist benannt. Ist es ein Bild, lädt es ohne Lazy Loading, mit
fetchpriority="high"und in einer Größe, die der dargestellten Breite entspricht. - Vor dem LCP-Element lädt keine blockierende Ressource, die für die erste Ansicht nicht nötig ist, insbesondere kein Skript eines Drittanbieters.
- Labormessung auf den Referenz-URLs unter festgelegten Bedingungen (Gerät, Netzwerkdrosselung, Median aus [5] Läufen): Largest Contentful Paint höchstens [Wert] Sekunden.
- Keine andere Kennzahl verschlechtert sich in derselben Messung um mehr als [10] Prozent gegenüber dem Ausgangswert.
LCP nach dem Livegang: 75. Perzentil der Felddaten über 28 Tage
- Der Largest Contentful Paint des Seitentyps liegt im 75. Perzentil der Felddaten auf Mobilgeräten über 28 Tage bei höchstens [2,5] Sekunden.
- Weicht der Wert ab, entsteht ein neues Ticket mit dem gemessenen Wert als Ausgangswert.
Nachweis: Messprotokoll mit Bedingungen, URLs, Datum und Werten vor und nach der Änderung, dazu der Verweis auf die Felddatenauswertung nach 28 Tagen.
Ticket-Vorlage Interaction to Next Paint: häufigste Interaktionen messen, Hauptprozess entlasten
Ticket-Titel: [Seitentyp]: Interaction to Next Paint mobil auf höchstens [200] Millisekunden im 75. Perzentil
Kontext: Ausgangswert im 75. Perzentil mobil: [Wert] Millisekunden laut [Quelle], Stand [Datum]. Langsamste Interaktion laut Real User Monitoring: [Element und Interaktion].
INP vor dem Merge: benannte Interaktionen mit CPU-Drosselung
- Die [3] häufigsten Interaktionen des Seitentyps sind benannt, etwa Menü öffnen, Filter setzen oder Eingabe in ein Formularfeld.
- Jede dieser Interaktionen ist im Performance-Panel der Chrome-Entwicklertools oder im Zeitspannenmodus von Lighthouse mit [4-facher] CPU-Drosselung gemessen und liegt bei höchstens [Wert] Millisekunden.
- Die Total Blocking Time der Seite liegt in der Labormessung bei höchstens [Wert] Millisekunden, als Näherung für die Belastung des Hauptprozesses beim Laden.
- Kein neues Skript eines Drittanbieters ohne Freigabe gegen das Performance-Budget.
INP nach dem Livegang: Felddaten mit Zuordnung der Interaktion
- Die Interaction to Next Paint des Seitentyps liegt im 75. Perzentil der Felddaten auf Mobilgeräten über 28 Tage bei höchstens [200] Millisekunden.
- Das Real User Monitoring ordnet langsame Interaktionen einem Element zu, damit ein Rückfall einem Baustein zugeordnet werden kann.
Nachweis: Aufzeichnung jeder benannten Interaktion mit Dauer, Gerät und Drosselung, dazu der Verweis auf die Felddatenauswertung nach 28 Tagen.
Ticket-Vorlage Cumulative Layout Shift: Platz reservieren, auch für nachgeladene Bausteine
Ticket-Titel: [Seitentyp]: Cumulative Layout Shift auf höchstens [0,1] im 75. Perzentil
Kontext: Ausgangswert im 75. Perzentil mobil: [Wert] laut [Quelle], Stand [Datum]. Größte Verschiebung laut Messung: [Baustein].
CLS vor dem Merge: Abmessungen, reservierter Platz und manueller Test
- Alle Bilder, Videos, iframes und Werbeflächen haben Breite und Höhe oder ein festes Seitenverhältnis im Markup.
- Nachgeladene Bausteine wie Personalisierung, Hinweise und Einwilligungsdialog haben reservierten Platz in fester Höhe oder erscheinen als Überlagerung ohne Verschiebung.
- Der Wechsel von der Ersatzschrift zur Webschrift verschiebt keinen sichtbaren Inhalt.
- Labormessung: Cumulative Layout Shift höchstens [Wert]. Zusätzlich ein manueller Test mit Scrollen und den häufigsten Interaktionen, weil die Labormessung des Seitenaufrufs nur die Ladephase erfasst.
CLS nach dem Livegang: Felddaten einschließlich Scrollen und Interaktion
- Der Cumulative Layout Shift des Seitentyps liegt im 75. Perzentil der Felddaten auf Mobilgeräten über 28 Tage bei höchstens [0,1].
Nachweis: Messprotokoll mit den verschobenen Elementen vor und nach der Änderung, Ergebnis des manuellen Tests, Verweis auf die Felddatenauswertung nach 28 Tagen.
Ticket-Vorlage Time to First Byte: Trefferquote des Caches als Abnahmekriterium
Ticket-Titel: [Seitentyp]: Time to First Byte auf höchstens [800] Millisekunden im 75. Perzentil
Kontext: Ausgangswert im 75. Perzentil mobil: [Wert] Millisekunden laut [Quelle], Stand [Datum]. Trefferquote des Caches für diesen Seitentyp: [Wert] Prozent.
TTFB vor dem Release: Trefferquote, Parameter und Invalidierung
- Anonyme Anfragen auf den Seitentyp werden zu mindestens [Wert] Prozent aus dem Cache beantwortet, nachgewiesen aus den Protokollen von Cache und CDN.
- Kampagnenparameter wie
utm_source,gclidundfbclidführen zu keinem Fehltreffer. Der Testfall ist dokumentiert. - Eine Veröffentlichung invalidiert nicht mehr als nötig. Der Umfang (Seite, Teilbaum oder Site) ist dokumentiert und mit einem Testfall belegt.
- Bei einem Fehltreffer antwortet die Anwendung in höchstens [Wert] Millisekunden, und vor der Seite liegt keine Weiterleitungskette.
TTFB nach dem Livegang: Antwortzeit echter Besucher je Seitentyp
- Die Time to First Byte des Seitentyps liegt im 75. Perzentil der Felddaten auf Mobilgeräten über 28 Tage bei höchstens [800] Millisekunden.
Nachweis: Auszug aus den Protokollen von Cache und CDN mit Trefferquote je Seitentyp, Ergebnis beider Testfälle, Verweis auf die Felddatenauswertung nach 28 Tagen.
Definition of Done für Performance: fünf Punkte für jedes Release
Die Tickets gelten für gezielte Verbesserungen. Damit eine Plattform nach der Optimierung nicht wieder langsamer wird, gehören fünf Punkte in die Definition of Done des Teams:
- Für jeden betroffenen Seitentyp liegt ein Messprotokoll mit festgelegten Bedingungen vor, vor und nach der Änderung.
- Die Budgets für JavaScript, CSS und Bilder werden in der Build-Pipeline geprüft. Eine Überschreitung bricht den Build ab.
- Jedes neue Skript eines Drittanbieters ist gegen das Performance-Budget freigegeben und hat einen benannten Eigentümer.
- Keine Kennzahl verschlechtert sich gegenüber dem letzten Release um mehr als [Toleranz] Prozent.
- 28 Tage nach dem Livegang sind die Felddaten geprüft. Jede Abweichung vom Zielwert wird ein neues Ticket.
Die Budget-Prüfung in der Pipeline lässt sich mit Lighthouse CI oder mit PerfDelta umsetzen, das Budgets je URL gegen Feld- und Labordaten prüft. Wie die Zielwerte entstehen und priorisiert werden, beschreibt Website Performance Optimierung.
Download: Ticket-Vorlagen als PDF unter CC BY 4.0
Die Vorlagen als PDF enthalten alle vier Tickets und die Definition of Done mit Checklisten zum Übertragen in Jira, Azure DevOps, GitLab oder GitHub. Sie stehen unter der Lizenz Creative Commons Namensnennung 4.0: Auftraggeber, Agenturen und IT-Dienstleister dürfen sie verwenden und anpassen, auch in kommerziellen Projekten, mit der Quellenangabe "Christian Schreiber, ch-schreiber.net".
Die Anforderungen, aus denen diese Tickets entstehen, stehen in den Lastenheft-Vorlagen Performance-Anforderungen im AEM-Lastenheft und Performance-Anforderungen im Magnolia-Lastenheft.
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 Abnahmekriterien für Core Web Vitals
Warum reicht ein Lighthouse-Wert nicht als Abnahmekriterium?
Lighthouse misst eine simulierte Seitenansicht ohne echte Geräte, ohne echte Netze und ohne erteilte Einwilligung, also ohne die Tags, die erst nach der Zustimmung laden. Google bewertet dagegen das 75. Perzentil echter Besuche über 28 Tage. Ein Lighthouse-Wert eignet sich als Prüfung vor dem Merge, abgenommen wird mit Felddaten je Seitentyp.
Wie wird Interaction to Next Paint vor dem Livegang geprüft?
Mit benannten Interaktionen, die im Performance-Panel der Chrome-Entwicklertools oder im Zeitspannenmodus von Lighthouse mit CPU-Drosselung ausgeführt und gemessen werden. Eine reine Ladeprüfung erfasst keine Interaktion. Die Total Blocking Time dient dort nur als Näherung für die Belastung des Hauptprozesses.
Wer nimmt Performance-Tickets ab?
Am besten eine Stelle, die die Umsetzung nicht selbst verantwortet. Das Team prüft die Kriterien vor dem Merge selbst. Den Nachweis in den Felddaten nach 28 Tagen prüft eine unabhängige Stelle gegen Zielwert und Ausgangswert.