Christian SchreiberWeb Performance Consulting Performance-Erstanalyse buchen

Core Web Vitals sind Betrieb Einmalige Optimierungen verpuffen, solange Performance-Budget, Release-Abnahme und Monitoring fehlen

Von , Web Performance Consultant für AEM und Magnolia, veröffentlicht am

Core Web Vitals sind für mich ein Betriebsthema, kein Projekt. Ein Optimierungsprojekt endet mit guten Werten und einer Übergabe. Die Plattform läuft danach weiter: Jedes Release, jede Kampagne und jedes neue Tag verändert Ladezeit, Reaktionszeit und Layoutstabilität. Ohne feste Regeln im Betrieb kehren die Werte dorthin zurück, wo sie vor dem Projekt lagen.

Diese Position stütze ich auf zwei Quellen: auf den eigenen Core Web Vitals Benchmark 2026 mit Googles Nutzerdaten für den DACH-Raum und auf das, was sich in Projekten auf Adobe Experience Manager und Magnolia CMS immer wieder zeigt. Am Ende stehen die drei Routinen, die ich für unverzichtbar halte.

Core Web Vitals im AEM-Benchmark: 49,4 Prozent bestehen auf Smartphones

Im AEM Core Web Vitals Benchmark bestehen auf Smartphones 49,4 Prozent der 4.222 AEM-Datensätze aus Deutschland, Österreich und der Schweiz alle drei Core Web Vitals. Über alle Websites der drei Länder sind es 68,7 Prozent, Datenstand August 2026. Im Magnolia CMS Benchmark, der auf einem eigenen Abruf von 148 Auftritten beruht, bestehen 64,2 Prozent.

Für sich genommen sagt diese Momentaufnahme wenig darüber, ob gute Werte halten. Dafür braucht es den Verlauf über mehrere Monate.

Verlauf seit Januar 2024: Erreichte Anteile halten sich nicht von selbst

Die Schnittstelle des HTTP Archive liefert die Anteile monatsweise, im Benchmark ab Januar 2024. Damals bestanden 45,2 Prozent der AEM-Auftritte auf Smartphones, im Januar 2026 51,7 Prozent und im August 2026 49,4 Prozent. Der Gesamtmarkt der drei Länder stieg im selben Zeitraum von 62,2 auf 68,7 Prozent.

Zwei Dinge lese ich daraus. Erstens bewegt sich der Markt: Wer seine Werte nur hält, fällt im Vergleich zum Wettbewerb zurück. Zweitens ist ein erreichter Stand nicht stabil, denn zwischen Januar und August 2026 ging der Anteil der AEM-Auftritte wieder zurück.

Die Linie mischt echte Arbeit an den Plattformen mit einer Grundgesamtheit, die sich jeden Monat ändert. Für eine einzelne Plattform beweist sie deshalb nichts. Sie passt aber zu dem, was sich in Projekten zeigt: Ohne Regeln im Betrieb wird ein Gewinn nach und nach aufgebraucht.

INP statt FID ab März 2024: Google verschiebt die Messlatte

Neben der eigenen Plattform verändert sich auch der Maßstab. Am 12. März 2024 hat Interaction to Next Paint die Kennzahl First Input Delay als Core Web Vital abgelöst (web.dev). INP bewertet die Reaktionszeit aller Interaktionen eines Besuchs, FID erfasste nur die Wartezeit vor der ersten Eingabe (web.dev zu INP).

In der Zeitreihe des Benchmarks fiel der Anteil bestandener AEM-Auftritte von Februar auf März 2024 von 45,6 auf 39,8 Prozent, der Gesamtmarkt von 62,1 auf 56,4 Prozent. Ich nehme an, dass ein Teil dieser Auftritte in diesem Monat nichts verändert hat und trotzdem nicht mehr bestand. Wer Core Web Vitals als abgeschlossenes Projekt verbucht hat, hat für einen solchen Wechsel weder Budget noch Zuständigkeit.

Releases, Kampagnen und Tags: drei Quellen der Regression im laufenden Betrieb

In Projekten zeigt sich immer wieder dasselbe Muster. Die Verschlechterung kommt selten mit einem großen Umbau, sondern in kleinen Schritten, die einzeln begründbar sind:

Ein Optimierungsprojekt räumt den Bestand auf. Gegen den Zufluss hilft es nicht, weil der Zufluss nach dem Projektende weitergeht.

28-Tage-Fenster im Chrome UX Report: Regressionen werden spät sichtbar

Google bewertet die Core Web Vitals aus dem Chrome User Experience Report, im 75. Perzentil über ein rollierendes Fenster von 28 Tagen (CrUX-Methodik). Ein Release, das die Werte verschlechtert, zeigt sich in diesen Daten erst nach Tagen und ist erst nach vier Wochen vollständig abgebildet. Eine Korrektur braucht noch einmal so lange.

Wer nur die Daten von Google beobachtet, erfährt von einer Regression also, wenn sie schon wochenlang im Feld ist. Für ein Projekt mit Abschlussbericht ist das kein Problem, für eine Plattform mit Releases alle zwei Wochen schon: Bis eine Verschlechterung auffällt, sind zwei weitere Releases live, und die Ursache lässt sich kaum noch zuordnen.

Performance-Budget, Release-Abnahme und Monitoring halten die Core Web Vitals im Betrieb

Daraus folgen drei Routinen, die nach jedem Projekt weiterlaufen sollten. Keine davon ist aufwendig, aber jede braucht einen Eigentümer.

  1. Performance-Budget je Seitentyp: Obergrenzen für JavaScript, Bildgewicht, Zahl der Drittanbieter und Laborwerte, geprüft in der Auslieferungskette. Ein Build, der das Budget reißt, wird abgelehnt oder bewusst freigegeben. Aufbau und Werte beschreibt Performance-Budget.
  2. Release-Abnahme gegen Zielwerte: Vor dem Livegang eine Labormessung je Seitentyp gegen das Budget, nach dem Livegang der Abgleich mit den Felddaten. Abweichungen werden zu Tickets mit Messwert, Zielwert und Abnahmekriterium.
  3. Monitoring im Feld: Ein Real User Monitoring nach Seitentyp, Markt und Gerät meldet eine Verschlechterung innerhalb eines Tages statt nach vier Wochen. Neue Tags gehen erst nach einer Prüfung gegen das Budget live.

Die Routinen antworten auf die drei Quellen der Regression: Das Budget fängt Releases ab, die Abnahme macht Abweichungen zu Aufgaben, und das Monitoring zeigt, was Kampagnen und Tags im Feld bewirken.

Zuständigkeit für Performance: ein Posten im Betriebsbudget statt eines Projekts

Die organisatorische Folge ist unbequemer als die technische. Ein Projekt hat ein Budget, einen Anfang und ein Ende; danach fühlt sich niemand mehr zuständig. Im Betrieb braucht Performance dasselbe wie Verfügbarkeit oder Sicherheit: einen benannten Eigentümer, einen festen Platz in der Release-Planung und einen Posten im laufenden Budget. Fehlt dieser Posten, fehlt beim nächsten Rückschritt das Geld für die Korrektur, und das nächste Projekt beginnt wieder beim Ausgangsniveau.

Ich halte deshalb wenig von der Frage, wie schnell eine Plattform am Ende eines Projekts ist. Aussagekräftiger ist, wie schnell sie zwölf Monate später ist und ob jemand eine Verschlechterung in dieser Zeit bemerkt hätte. Mein Anteil daran sind Zielwerte, Messung und Abnahme; die Umsetzung liegt beim Team, das die Plattform täglich baut. Den Ablauf beschreibt Website Performance Optimierung, und warum die Abnahme nicht beim umsetzenden Team liegen sollte, steht in der Position Abnahme getrennt von Umsetzung.

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 Core Web Vitals im Betrieb

Reicht ein Optimierungsprojekt im Jahr für gute Core Web Vitals?

Ein jährliches Projekt räumt den Bestand auf. Zwischen zwei Projekten laufen Releases, Kampagnen und neue Tags aber weiter, und Google bewertet immer die letzten 28 Tage. Es zählt also der Zustand in jedem Monat, nicht der am Projektende. Wirksamer ist eine laufende Kontrolle mit einem Performance-Budget je Seitentyp und einer Abnahme je Release.

Welche Rolle spielt Real User Monitoring im Betrieb?

Es verkürzt die Zeit, bis eine Verschlechterung auffällt. Die Daten von Google bilden ein Release erst nach vier Wochen vollständig ab, ein Real User Monitoring zeigt die Veränderung nach Seitentyp, Markt und Gerät innerhalb eines Tages. Maßstab für die Abnahme bleiben die Felddaten im 75. Perzentil.

Wer sollte im Betrieb für die Core Web Vitals verantwortlich sein?

Eine benannte Person auf Seiten des Plattformbetreibers, häufig die Plattformverantwortung oder der Product Owner. Dazu kommt je Wert im Performance-Budget ein Eigentümer, etwa das Marketing für Tags und die Entwicklung für JavaScript. Ohne diese Zuordnung bleibt eine gemeldete Verschlechterung liegen.