Seitengeschwindigkeit prüfen.
Rankings beschleunigen.

Labordaten und Felddaten widersprechen sich, und beide haben recht

Fast jede Diskussion über Seitengeschwindigkeit entsteht, weil zwei Zahlen verglichen werden, die nie dasselbe gemessen haben.

Labordaten sind ein einzelner synthetischer Ladevorgang auf einem festgelegten Gerät mit festgelegter Verbindung. Lighthouse lädt die Seite einmal, mit einem gedrosselten mobilen Mittelklasseprofil, in einem sauberen Browser ohne Erweiterungen und ohne Cache. Das ist reproduzierbar und isoliert die Ursache, weshalb es das richtige Werkzeug für die Fehlersuche ist. Zwischen identischen Durchläufen schwankt der Wert allerdings um mehrere Punkte, weil die CPU-Auslastung des Messrechners das Ergebnis verändert.

Felddaten zeigen, was echten Menschen tatsächlich passiert ist. Google sammelt sie im Chrome User Experience Report von Chrome-Nutzern, die zugestimmt haben, und aggregiert sie über ein gleitendes 28-Tage-Fenster. Sie spiegeln Ihr echtes Publikum wider, dessen echte Geräte, echte Netzwerke und zwischengespeicherte Folgebesuche. Diese Daten nutzt Google für das Page-Experience-Signal.

Eine Seite kann also in Lighthouse 62 Punkte erreichen und ihre Feldmetriken trotzdem locker bestehen, meist weil das echte Publikum mit schnellerer Hardware unterwegs ist als das gedrosselte Testprofil. Umgekehrt passiert es auch, und das wiegt schwerer: Eine Seite kann im Labor 95 Punkte erreichen und im Feld durchfallen, weil das Labor nie das Cookie-Banner, das Chat-Widget, die einwilligungsabhängige Analyse oder die Drittanbieter-Schrift geladen hat, die echte Nutzer bekommen.

Was die Zahl wirklich bewegt

In der Praxis konzentrieren sich die Erfolge auf eine kurze Liste. Bilder, die größer sind als ihre Darstellungsgröße, oder in einem Format ausgeliefert werden, das der Browser mühsamer dekodieren muss. Render-blockierendes CSS und synchrone Skripte im Head. Schriften ohne Anzeigestrategie, sodass Text unsichtbar bleibt, bis sie geladen sind. Drittanbieter-Einbindungen, die häufig der größte einzelne Kostenfaktor sind und um die sich niemand kümmert. Und die Antwortzeit des Servers, die sich durch keine Front-End-Arbeit ausgleichen lässt.

Die Falle ist, für den Score statt für das Erlebnis zu optimieren. Ein Skript erst nach dem Messzeitraum zu laden verbessert die Zahl und ändert für die wartende Person nichts.

So geht UtilitySEO damit um

Wir führen das Audit für Mobilgeräte und Desktop durch und weisen die vier Lighthouse-Kategorien getrennt aus, statt sie zu einer Zahl zusammenzufassen, denn eine Seite mit starker Performance und schwacher Barrierefreiheit braucht einen anderen Plan als umgekehrt. Jedes Problem kommt mit dem Grund, warum es markiert wurde, und mit dem, was zu ändern ist, sortiert nach Wirkung.