Core Web Vitals für Webanwendungen: was eine nicht bestandene Bewertung bedeutet und was Sie die Firma fragen sollten, die Ihre Anwendung baut

Core Web Vitals sind drei Messwerte dafür, wie sich eine Seite für die Menschen anfühlt, die sie nutzen. Sie zeigen, wie bald ihr Hauptinhalt erscheint, wie schnell sie auf einen Klick oder Tastendruck reagiert und wie ruhig sie auf dem Bildschirm bleibt. Googles Rankingsysteme nutzen sie, aber als ein Signal unter vielen: Laut Google will die Suche immer die relevantesten Inhalte zeigen, auch wenn das Nutzererlebnis der Seite mittelmässig ist.

Was bedeutet «Core-Web-Vitals-Bewertung: Nicht bestanden»?

Es bedeutet, dass bei mindestens einem der drei Messwerte mehr als ein Viertel der echten Besuche in Chrome hinter dem zurückblieb, was Google als gut einstuft. PageSpeed Insights betrachtet die letzten 28 Tage, und eine Seite oder eine ganze Website besteht nur, wenn mindestens drei von vier Besuchen bei allen drei Werten gut sind.

Gibt es zu wenige Daten zu INP, entscheiden Laden und Stabilität allein. Gibt es zu einem dieser beiden zu wenige Daten, gibt es gar keine Bewertung.

Bei einer Webanwendung sollten Sie das Ergebnis sorgfältig lesen. Diese Zahlen umfassen nur öffentlich auffindbare Seiten, so beurteilt, wie eine Suchmaschine sie beurteilt, darum erscheinen die Ansichten hinter Ihrer Anmeldung normalerweise nicht einzeln. Teilt Ihre Anwendung aber ihre Adresse mit Ihrer öffentlichen Website, statt auf einer eigenen Subdomain zu laufen, zählen die Besuche angemeldeter Nutzer trotzdem in den Zahlen für die ganze Website mit.

Was sind die drei Core Web Vitals und ihre Schwellenwerte?

Es sind drei: LCP misst das Laden, INP die Reaktionsfähigkeit und CLS die visuelle Stabilität. Die Schwellenwerte unten sind die, die Google auf web.dev angibt. Gemessen wird jeweils beim 75. Perzentil der Seitenaufrufe, getrennt nach Handy und Computer.

• LCP, Largest Contentful Paint (Laden): wann das grösste sichtbare Bild oder der grösste Textblock erschienen ist. Gut sind 2,5 Sekunden oder weniger; schlecht sind mehr als 4 Sekunden.
• INP, Interaction to Next Paint (Reaktionsfähigkeit): wie lange die Seite braucht, um auf einen Klick, ein Tippen oder einen Tastendruck sichtbar zu reagieren, beurteilt über den ganzen Besuch. Gut sind 200 Millisekunden oder weniger; schlecht sind mehr als 500 Millisekunden.
• CLS, Cumulative Layout Shift (visuelle Stabilität): wie stark sich der Inhalt unerwartet verschiebt, über die ganze Lebensdauer der Seite. Gut ist 0,1 oder weniger; schlecht ist mehr als 0,25.

Bei einer Webanwendung verdient INP die grösste Aufmerksamkeit. Die Nutzungsdaten von Chrome zeigen, dass 90 % der Zeit, die jemand auf einer Seite verbringt, nach dem Laden liegen, und in einer Anwendung wird den ganzen Tag geklickt, getippt und gefiltert.

Die Schwellenwerte sind schwerer zu erreichen, als sie klingen. Im Web Almanac 2024 des HTTP Archive hatten 43 % der Websites auf dem Handy gute Core Web Vitals und 54 % auf dem Computer.

Warum eine Webanwendung sie verfehlen kann

Eine verbreitete Bauweise für Webanwendungen ist die Single-Page-Anwendung: Der Browser erhält zuerst eine fast leere Seite, und JavaScript füllt dann den Inhalt ein. Das zeigt sich in allen drei Messwerten.

• Laden: Der Hauptinhalt erscheint erst, wenn das JavaScript angekommen ist und ausgeführt wurde. Der Web Almanac 2024 stellte fest, dass eine vollständig im Browser gerenderte Seite den LCP deutlich verschlechtert.
• Reaktionsfähigkeit: Die Menge an JavaScript wächst meist mit der Anwendung, und das kann INP schaden. Eine sehr grosse Seite, etwa eine lange Tabelle, kann zudem dazu führen, dass jede Aktualisierung nach einem Klick aufwendig zu zeichnen ist.
• Stabilität: Inhalte, die später ankommen, etwa Daten vom Server, verschieben das Layout, wenn kein Platz für sie freigehalten wurde.

Wie werden sie gemessen?

Zwei Arten von Daten beantworten zwei verschiedene Fragen. Felddaten stammen von echten Besuchern und zeigen, ob Sie bestehen. Labordaten stammen aus einem Testlauf auf einem Gerät und helfen, die Ursache zu finden.

• PageSpeed Insights zeigt beides für eine öffentliche Adresse: die Felddaten der letzten 28 Tage aus dem Chrome User Experience Report, sofern genug davon vorhanden sind, und einen Labortest mit Lighthouse. Labor-Werkzeuge, die die Seite nur laden, ohne etwas anzuklicken, können INP nicht messen.
• Der Core-Web-Vitals-Bericht der Search Console fasst ähnliche Seiten zu Gruppen zusammen und gibt jeder Gruppe den Status ihres schlechtesten Messwerts der letzten 28 Tage. Darin erscheinen nur indexierte Seiten.
• Die Bibliothek web-vitals misst die drei Werte in den Browsern Ihrer eigenen Nutzer, so wie Chrome sie misst, und schickt sie, wohin Sie wollen. Von diesen Werkzeugen misst nur sie Ihre echten Nutzer in den Ansichten hinter Ihrer Anmeldung.
• Chrome DevTools: Das Performance-Panel zeigt einem Entwickler, welche Arbeit eine einzelne Interaktion verlangsamt hat.

Was sollten Sie vor dem Livegang fragen?

Fünf Dinge: welche Seiten gefunden werden müssen, was die Ziele sind, wie die Ansichten für angemeldete Nutzer gemessen werden, was verhindert, dass eine neue Version alles langsamer macht, und wer die Zahlen nach dem Livegang im Blick behält. Wer Ihre Webanwendung baut, sollte alle fünf vor dem Livegang in einfachen Worten beantworten können.

1. Welche Seiten müssen bei Google gefunden werden, und kann eine Suchmaschine sie lesen? Öffentliche Seiten sollten als fertiges HTML ankommen, auf dem Server oder im Voraus gerendert, statt nach dem Laden von JavaScript gezeichnet zu werden. Die Ansichten hinter Ihrer Anmeldung müssen nicht gefunden werden.
2. Was sind die Ziele, und auf welchen Geräten? Verlangen Sie alle drei Werte innerhalb der guten Schwellenwerte, gemessen auf dem Handy wie am Computer.
3. Wie werden die Ansichten für angemeldete Nutzer gemessen, sobald echte Menschen sie nutzen? Die Felddaten von Google zeigen sie nicht, die Anwendung muss sich also selbst messen.
4. Was verhindert, dass eine neue Version alles langsamer macht? Eine Grössengrenze für das JavaScript, bei jeder neuen Version geprüft, fängt einen Teil davon vor einem Release ab.
5. Wer behält die Zahlen nach dem Livegang im Blick? Ein Status kann sich ändern, ohne dass Sie etwas ändern, etwa wenn die Besucherzahlen stark ansteigen. Was Software braucht, sobald sie live ist, behandelt unser Beitrag über die Wartung von Software nach dem Livegang.

Für Ihre Entwickler: Korrekturen in Single-Page-Apps

Dieser Teil verwendet Fachbegriffe, damit Sie ihn so weitergeben können, wie er ist.

Laden (LCP)

• Laden Sie das Bild, das wahrscheinlich das LCP-Element ist, nie per Lazy Loading. Lassen Sie es normal laden und geben Sie ihm fetchpriority="high"; verwenden Sie loading="lazy" nur für Bilder weiter unten auf der Seite.
• Rendern Sie die öffentlichen Seiten im Voraus oder auf dem Server, damit der Hauptinhalt in der ersten HTML-Antwort steckt.
• Prüfen Sie die Antwortzeit des Servers und liefern Sie die Dateien nahe bei Ihren Nutzern aus, etwa über ein CDN. Im Web Almanac 2024 war die Time to First Byte der grösste Anteil am LCP, und Websites mit schlechtem LCP verbrauchten allein dafür 2,27 Sekunden.
• Machen Sie grosse Bilder kleiner, indem Sie sie komprimieren oder als AVIF oder WebP ausliefern. Auf 73 % der mobilen Seiten ist das LCP-Element ein Bild (Web Almanac 2024), Bilder sind also ein guter Ansatzpunkt.

Reaktionsfähigkeit (INP)

• Teilen Sie das JavaScript auf, damit jede Ansicht nur lädt, was sie braucht. In React lädt lazy() mit Suspense den Code einer Komponente erst, wenn sie zum ersten Mal angezeigt wird.
• Teilen Sie lange Aufgaben in Event-Handlern auf und geben Sie den Main Thread frei, damit der Browser die Reaktion zuerst zeichnen kann.
• Halten Sie das DOM der Seite klein: Zeigen Sie lange Listen und Tabellen in Teilen, und ziehen Sie content-visibility für Inhalte weit unterhalb des sichtbaren Bereichs in Betracht.

Stabilität (CLS)

• Geben Sie jedem Bild und Video seine Breite und Höhe, oder reservieren Sie seinen Platz mit CSS aspect-ratio.
• Halten Sie Platz frei für alles, was später ankommt: Daten vom Server, eingebettete Inhalte und Banner.
• Laden Sie die wichtigen Webfonts vorab, und verwenden Sie font-display: optional oder eine mit size-adjust angepasste Ersatzschrift, denn auch der Wechsel von einer Schrift zur anderen kann das Layout verschieben.

Checkliste

• LCP von 2,5 Sekunden oder weniger auf jeder wichtigen Seite, auf dem Handy und am Computer
• INP von 200 Millisekunden oder weniger, getestet mit echten Klicks und Eingaben
• CLS von 0,1 oder weniger, besonders auf dem Handy geprüft
• Öffentliche Seiten kommen als fertiges HTML an, und das LCP-Bild wird nicht per Lazy Loading geladen
• Bilder komprimiert, als AVIF oder WebP, jedes mit Breite und Höhe
• Schriften vorab geladen, mit font-display: optional oder einer angepassten Ersatzschrift
• Eine Grössengrenze für das JavaScript, bei jeder neuen Version geprüft
• Die Bibliothek web-vitals an Ihre Auswertung angebunden, damit auch die Ansichten für angemeldete Nutzer gemessen werden
• Der Bericht der Search Console nach jedem Release geprüft

Core Web Vitals sind kein einmaliges Projekt, sondern eine laufende Aufgabe. Messen Sie regelmässig, setzen Sie Prioritäten anhand der Daten und verbessern Sie Schritt für Schritt.