Zum Inhalt springen

Webseite

Was ein Ladezeit-Bericht wirklich sagt

Der Wert von 0 bis 100 ist nicht die Note, auf die Google schaut. Welche drei Zahlen zählen, woher sie kommen und was du getrost ignorieren kannst.

6 Min. Lesezeit Christopher Sakel

Inhalt
  1. Der wichtigste Unterschied steht ganz oben
  2. Drei Werte, drei Schwellen
  3. Die Labornote enthält INP überhaupt nicht
  4. „Nicht genügend Daten" ist bei kleinen Betrieben der Normalfall
  5. Was das fürs Ranking bedeutet
  6. Was du mit dem Bericht machst

Irgendwann liegt so ein Bericht auf dem Tisch. Ein Screenshot mit einem roten Kreis, darin eine Zahl — 38, oder 51. Darunter eine Liste mit Punkten, die niemand versteht, und daneben oft ein Angebot, das Ganze für einen Betrag zu richten.

Die Zahl im roten Kreis ist nicht die Zahl, an der Google deine Seite misst. Sie enthält nicht einmal alle Werte, auf die Google schaut, und einen davon lässt sie komplett weg. Wer nur sie verbessert, kann Geld ausgeben, ohne dass sich an dem ändert, was zählt.

Ein solcher Bericht ist trotzdem nützlich. Man muss nur wissen, welcher Teil davon eine Aussage ist und welcher Teil eine Momentaufnahme auf einem simulierten Billighandy.

Der wichtigste Unterschied steht ganz oben

Ein Bericht aus PageSpeed Insights hat zwei Hälften, und sie entstehen völlig verschieden.

Die obere Hälfte sind Felddaten. Sie kommen aus dem Chrome User Experience Report, also von echten Menschen mit echten Geräten in echten Netzen, die deine Seite tatsächlich aufgerufen haben. Google bildet daraus einen rollierenden Zeitraum der letzten 28 Tage. Was dort steht, ist gemessene Wirklichkeit — verzögert um bis zu vier Wochen.

Die untere Hälfte sind Labordaten. Dafür lädt Lighthouse deine Seite einmal, in einer simulierten Umgebung. Für die Mobilansicht bedeutet das laut Googles Dokumentation: ein Moto G4 an einer mobilen Verbindung. Das ist absichtlich ein schwaches Gerät.

Die bunte Zahl von 0 bis 100 gehört zur unteren Hälfte. Sie ist eine Labornote.

Drei Werte, drei Schwellen

Was Google unter Core Web Vitals führt, sind genau drei Messwerte. Für jeden nennt Google drei Stufen.

LCP — Largest Contentful Paint. Wann das größte sichtbare Element erscheint, meist ein Foto oder die Überschrift. Gut ist 2,5 Sekunden oder weniger. Zwischen 2,5 und 4,0 Sekunden gilt es als verbesserungsbedürftig, über 4,0 Sekunden als schlecht.

INP — Interaction to Next Paint. Wie lange es dauert, bis die Seite auf eine Eingabe sichtbar reagiert. Gut ist 200 Millisekunden oder weniger, bis 500 Millisekunden verbesserungsbedürftig, darüber schlecht. Gezählt werden Mausklicks, Antippen und Tastatureingaben — Scrollen, Überfahren mit der Maus und Zoomen ausdrücklich nicht.

CLS — Cumulative Layout Shift. Wie stark der Inhalt beim Laden verrutscht. Gut ist 0,1 oder weniger, über 0,25 schlecht, dazwischen verbesserungsbedürftig.

Als Auslöser für CLS nennt Google Bilder und Videos ohne Größenangabe, Schriftarten, die anders rendern als die Ersatzschrift, und dynamisch nachgeladene Fremdinhalte, die sich selbst vergrößern. Wenn ein Cookie-Banner oder eine nachgeladene Schrift den Text zwei Zeilen nach unten schubst, ist das kein Schönheitsfehler, sondern eine Messgröße.

Der Wert gilt für 75 von 100 Besuchern

Das ist der Punkt, an dem die meisten Berichte falsch gelesen werden. Google meldet nicht den Durchschnitt, sondern das 75. Perzentil, getrennt für Mobil und Desktop.

Ein LCP von 2,5 Sekunden heißt: Drei Viertel deiner Besucher hatten es so schnell oder schneller. Das letzte Viertel — alte Handys, schlechtes Netz — hatte es langsamer, und das ist eingeplant. Google begründet die Wahl damit, dass eine Seite auch unter schwierigen Geräte- und Netzbedingungen noch brauchbar sein soll.

Daraus folgt zweierlei. Erstens: Ein einzelner Messwert von deinem eigenen Rechner sagt über diese Zahl nichts. Zweitens: Eine Verbesserung, die du heute einbaust, erscheint im Feldbericht erst nach Wochen vollständig.

Die Labornote enthält INP überhaupt nicht

Jetzt zur Zahl im roten Kreis. Googles Dokumentation zur Berechnung weist für Lighthouse 10 folgende Gewichtung aus:

Messwert Anteil
Total Blocking Time 30 %
Largest Contentful Paint 25 %
Cumulative Layout Shift 25 %
First Contentful Paint 10 %
Speed Index 10 %

Zwei Dinge fallen auf. Der größte Einzelposten ist Total Blocking Time — ein Laborwert, der im Feldbericht nicht vorkommt. Und INP steht nicht in der Tabelle. Reaktionszeit auf Eingaben lässt sich in einem Lauf ohne echte Nutzer nicht messen, also ersetzt Lighthouse sie durch einen Näherungswert.

Umgekehrt gehen First Contentful Paint und Speed Index mit zusammen 20 Prozent ein, obwohl keiner von beiden ein Core Web Vital ist.

Google empfiehlt in derselben Dokumentation, die Leistung einer Seite als Verteilung von Werten zu betrachten statt als eine einzelne Zahl, und nennt als Ursachen für Schwankungen zwischen zwei Läufen unter anderem wechselnde Werbeauslieferung, andere Netzwege, andere Geräte, Browsererweiterungen und Virenscanner. Zwei Läufe hintereinander mit acht Punkten Unterschied sind normal und kein Ergebnis.

„Nicht genügend Daten" ist bei kleinen Betrieben der Normalfall

Wenn die obere Hälfte des Berichts leer bleibt, ist nichts kaputt. Google braucht genügend echte Aufrufe, um einen Wert zu melden. Reicht es für die einzelne Adresse nicht, wechselt PageSpeed Insights auf die Ebene der gesamten Domain. Reicht es auch dort nicht, werden keine Felddaten angezeigt.

Für eine Handwerkerseite mit dreißig Besuchern am Tag ist das der Regelfall. Dann bleibt nur die Labornote — und damit bleibt sie ein Hinweis auf mögliche Bremsen, keine Messung deiner Besucher.

Was das fürs Ranking bedeutet

Hier ist Nüchternheit angebracht, weil an dieser Stelle viel verkauft wird. Google schreibt zur Nutzererfahrung als Rankinggröße, es gebe kein einzelnes Signal und keinen Gesamtwert dafür. Und weiter: Die Suche zeige immer den relevantesten Inhalt, auch wenn die Nutzererfahrung mittelmäßig sei. Erst wenn zu einer Frage viele gleich hilfreiche Seiten bestehen, kann die Nutzererfahrung den Unterschied machen.

Google sagt außerdem selbst, dass der Versuch, allein für die Suchmaschine eine perfekte Punktzahl zu erreichen, nicht die beste Verwendung deiner Zeit sein muss.

Der bessere Grund, an der Ladezeit zu arbeiten, steht woanders: Wer zu lange wartet, bricht ab. Das wirkt auf jede Anfrage, die deshalb nicht gestellt wird, unabhängig von jeder Platzierung.

Was du mit dem Bericht machst

In dieser Reihenfolge:

  1. Auf Mobil umstellen. Der Desktop-Wert ist fast immer besser und fast immer irrelevant.
  2. Oben anfangen. Stehen dort Felddaten, entscheiden sie. Sind alle drei Werte grün, ist die Labornote darunter eine Fußnote.
  3. Fehlen Felddaten, die Labornote als Suchhilfe nehmen — nicht als Note. Interessant ist nicht die Zahl, sondern welche Einträge in der Liste darunter echte Kilobytes oder Millisekunden nennen.
  4. Die üblichen Verdächtigen prüfen. Bilder, Fremdskripte, Plugins, Hosting. Was in welcher Reihenfolge am meisten bringt, steht in Warum deine Seite langsam ist.

Bei CLS lohnt ein zweiter Blick auf Schriftarten und Banner. Wer Schriften vom fremden Server nachlädt, hat beides in einem: eine Verschiebung beim Rendern und ein Datenschutzthema — nachzulesen in Google Fonts lokal einbinden. Bei LCP ist fast immer das erste Bild schuld; wie es vorbereitet gehört, steht in Bilder fürs Web vorbereiten.

Und wenn nach Bildern, Skripten und Plugins immer noch nichts grün wird, liegt es unter der Seite. Dann ist der nächste Schritt kein Plugin, sondern wo deine Webseite eigentlich steht.

Christopher Sakel

Fachinformatiker für Anwendungsentwicklung (IHK). Betreibt Sakel-IT in Uslar und schreibt hier über das, was in der Arbeit immer wieder vorkommt.

Frage dazu stellen

Fragen dazu?

Wir schauen uns deinen Fall an und sagen dir, was zu tun ist. Auch dann, wenn das Ergebnis lautet, dass gerade nichts zu tun ist.

Erstgespräch vereinbaren

Passend dazu