PageSpeed Website: Insights richtig lesen und Maßnahmen sinnvoll priorisieren

Der PageSpeed einer Website wird selten daran scheitern, dass niemand gemessen hat. Er scheitert daran, dass ein Bericht voller Empfehlungen vorliegt und niemand entscheidet, welche davon zuerst umgesetzt wird. Dieser Leitfaden zeigt, wie sich ein PageSpeed-Insights-Bericht lesen lässt, welche Werte tatsächlich handlungsleitend sind und in welcher Reihenfolge technische Maßnahmen den größten Effekt haben, geräteübergreifend statt nur für den Desktop-Screenshot im Meeting.

Zwei Datenquellen, zwei verschiedene Aussagen

Der wichtigste Lesefehler passiert ganz oben im Bericht. PageSpeed Insights bewertet eine URL mit Lighthouse-Labordaten und zeigt zusätzlich, sofern verfügbar, reale Nutzungsdaten aus dem Chrome UX Report an. Das sind zwei Messungen mit unterschiedlichem Anspruch, keine Bestätigung derselben Zahl.

Die Labordaten entstehen in einer kontrollierten Testumgebung und können deshalb von den Erfahrungen realer Nutzer abweichen. Sie sind reproduzierbar und damit gut geeignet, um eine Änderung vorher und nachher zu vergleichen. Die Felddaten aus dem Chrome UX Report sind aggregierte Werte über die Nutzungserfahrung realer Chrome-Nutzer und beschreiben, was auf echten Geräten, in echten Netzen, mit echten Browser-Erweiterungen passiert ist.

Daraus folgt eine einfache Arbeitsteilung. Die Felddaten beantworten die Frage, ob ein Problem existiert. Die Labordaten beantworten die Frage, woran es liegt. Wer die Reihenfolge vertauscht, optimiert Befunde, die reale Nutzer nie erreicht haben.

Die drei Kennzahlen, an denen entschieden wird

Die aktuellen Core Web Vitals sind Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Sie decken drei unterschiedliche Erfahrungen ab: wie schnell der Hauptinhalt sichtbar ist, wie zügig die Seite auf Eingaben reagiert und wie ruhig das Layout dabei bleibt.

Als gute Richtwerte gelten ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1. Maßgeblich ist jeweils das 75. Perzentil, also der Wert, den drei von vier Seitenaufrufen einhalten. Diese Perzentil-Regel ist keine Formalie, sondern der eigentliche Maßstab: Ein guter Durchschnitt kann entstehen, während ein Viertel der Nutzer eine deutlich langsamere Seite erlebt. Genau dieses Viertel entscheidet über die Bewertung.

Praktisch heißt das: Notieren Sie pro URL-Gruppe die drei Feldwerte im 75. Perzentil, getrennt nach Mobil und Desktop, und behandeln Sie nur die Kennzahl als Baustelle, die den Richtwert reißt. Zwei grüne Metriken machen eine rote nicht besser.

Der Score ist eine Zusammenfassung, keine Aufgabenliste

Lighthouse ordnet einen Performance-Score von 90 bis 100 als gut ein, 50 bis 89 als verbesserungswürdig und 0 bis 49 als schlecht. Der Wert eignet sich als grobe Ampel und als Verlaufskurve über Releases hinweg. Er eignet sich nicht als Zielgröße, an der ein Projekt gesteuert wird.

Der Grund ist die Konstruktion: Der Score verdichtet mehrere Labormetriken zu einer Zahl. Zwei Seiten mit identischem Score können völlig unterschiedliche Defekte haben, und eine Verbesserung von 62 auf 71 sagt niemandem, welches Nutzererlebnis besser geworden ist. Die Diagnose-Abschnitte unterhalb des Scores tragen die verwertbare Information, nicht der Kreis darüber.

Nützlich ist der Score dort, wo er Regressionen sichtbar macht. Fällt er nach einem Deployment deutlich, lohnt der Blick in die Details, bevor die Änderung in den Felddaten ankommt.

Mobil und Desktop sind zwei Berichte

Geräteübergreifend zu arbeiten bedeutet nicht, einen Mittelwert zu bilden. Mobile Geräte haben weniger CPU-Leistung, wechselhafte Netzqualität und andere Viewport-Größen. Ein Bild, das auf dem Desktop früh vollständig geladen ist, kann mobil zum LCP-Element werden. Ein Skript, dessen Ausführungszeit auf einem Entwicklerrechner nicht auffällt, kann auf einem Mittelklasse-Smartphone die Reaktionszeit über die INP-Schwelle drücken.

Sinnvoll ist deshalb: Der mobile Bericht setzt die Prioritäten, der Desktop-Bericht dient der Gegenprobe. Findet sich ein Problem nur mobil, ist die Ursache meist Rechenzeit oder Bildgewicht. Findet es sich auf beiden Geräten, liegt sie eher in der Auslieferung, also bei Serverantwortzeit, Umleitungsketten oder blockierenden Ressourcen.

Priorisierung: von der auffälligen Kennzahl zur Maßnahme

Die Reihenfolge ergibt sich aus der Metrik, die den Richtwert verfehlt, nicht aus der Reihenfolge der Empfehlungen im Bericht.

Wenn LCP zu hoch ist, geht es um den Weg des größten sichtbaren Elements. Zu prüfen sind Serverantwortzeit, Umleitungen vor dem ersten Byte, render-blockierende Ressourcen im Head und vor allem das LCP-Element selbst. Ist es ein Bild, sind Format und Größe der erste Hebel: WebP und AVIF können gegenüber älteren Bildformaten eine bessere Komprimierung liefern und dadurch die übertragenen Bilddaten reduzieren. Bilder, die im sichtbaren Bereich stehen, dürfen nicht verzögert geladen werden, Bilder darunter dagegen schon. Wenn Nutzer geografisch verteilt sind, kann ein CDN Inhalte näher an Nutzern ausliefern und dadurch die Netzwerklatenz verringern.

Wenn INP zu hoch ist, geht es um JavaScript. Nicht benötigtes JavaScript verursacht zusätzliche Netzwerk-, Parse-, Compile- und Ausführungszeit und sollte reduziert oder verzögert geladen werden. Prüfen Sie in dieser Reihenfolge: Was kann komplett entfallen, etwa ungenutzte Bibliotheken und mehrfach eingebundene Tracking-Skripte? Was kann später geladen werden, weil es erst nach einer Interaktion gebraucht wird? Was muss bleiben und lässt sich in kleinere Aufgaben zerlegen, damit lange Blockaden im Hauptthread aufbrechen? Skripte von Drittanbietern verdienen dabei eigene Aufmerksamkeit, weil sie oft am meisten Ausführungszeit kosten und am wenigsten kontrolliert werden.

Wenn CLS zu hoch ist, geht es fast immer um reservierten Platz. Bilder und eingebettete Elemente ohne feste Abmessungen, nachträglich eingeblendete Banner und Schriftwechsel verschieben Inhalte, während der Nutzer schon liest oder tippt. Diese Klasse von Fehlern ist meist günstig zu beheben und wirkt sofort, weshalb sie sich gut als erster Schritt eignet, wenn Kapazität knapp ist.

Als grobe Priorisierungshilfe über alle drei Metriken hinweg:

Wann ein Wert nicht handlungsleitend ist

Nicht jede rote Zeile verdient ein Ticket. Drei Fälle sollten bewusst zurückgestellt werden. Erstens: Für die URL liegen keine Felddaten vor, weil zu wenig Verkehr darauf entfällt. Dann ist der Laborwert ein Hinweis, kein Nachweis, und die Entscheidung sollte über eine Seitengruppe statt über die Einzel-URL fallen. Zweitens: Der Befund betrifft eine Seite ohne relevanten Verkehr. Die Optimierungsarbeit gehört auf die Vorlagen, die viele Seiten gleichzeitig verbessern. Drittens: Die Empfehlung spart wenige Kilobyte an einer Stelle, an der eine andere Metrik längst über dem Richtwert liegt.

Der Bezug zur Sichtbarkeit, ohne Übertreibung

Core Web Vitals werden von Google in den Suchsystemen berücksichtigt, eine gute Bewertung garantiert jedoch keine Spitzenposition in den Suchergebnissen. Das ist die realistische Einordnung: Performance ist eine Voraussetzung, die eine schwache Seite nicht stark macht, deren Fehlen aber eine starke Seite ausbremst und Nutzer vor der Interaktion abspringen lässt.

Ein Vorgehen, das sich wiederholen lässt

Setzen Sie den Ablauf als Schleife auf statt als Projekt. Feldwerte im 75. Perzentil je Seitengruppe und Gerät erheben, die verfehlte Metrik bestimmen, im Laborbericht die Ursache dazu suchen, genau eine Maßnahme umsetzen, im Labor gegenprüfen und danach abwarten, bis die Felddaten die Änderung abbilden. Wer stattdessen mehrere Maßnahmen gleichzeitig ausrollt, verbessert vielleicht den Wert, weiß aber nicht, wodurch. Beim nächsten Regressionsfall beginnt die Suche dann wieder bei null.