Page Speed: Definition, Messung und häufige technische Bremsen

Page Speed und Core Web Vitals werden oft synonym benutzt, sind es aber nicht. Page Speed ist der übergeordnete, umgangssprachliche Begriff: die allgemeine Wahrnehmung und Messung, wie lange eine Seite braucht, um zu laden und nutzbar zu werden. Der Begriff wird in SEO schon benutzt, seit es die heutigen Metriken noch gar nicht gab, und dient bis heute dazu, in einem Kundengespräch oder Briefing über die Performance einer Website zu sprechen, ohne gleich konkrete Zahlen zu nennen. Wer in einem Reporting nur "Page Speed verbessern" notiert, ohne zu sagen, welche Kennzahl oder welches Werkzeug gemeint ist, überlässt es dem Entwicklungsteam, an der falschen Stelle zu suchen.

Core Web Vitals ist die konkrete Umsetzung, für die sich Google seit 2020 entschieden hat, um diese Performance standardisiert zu messen: drei Metriken mit festgelegten Schwellenwerten, die Teil der "Page Experience"-Signale im Suchalgorithmus sind. Core Web Vitals ist also praktisch eine Teilmenge von Page Speed, der Teil, den Google zu einem messbaren Rankingfaktor gemacht hat. Page Speed umfasst darüber hinaus auch Aspekte, die diese drei Metriken nicht direkt erfassen, etwa die Antwortzeit des Servers bei Interaktionen, die nicht in die Berechnung von LCP, INP oder CLS einfließen, oder das subjektive Gefühl von Flüssigkeit, das ein Nutzer beim Navigieren hat.

Die vollständige Aufschlüsselung von LCP, INP und CLS mit Schwellenwerten und Beispielen steht im eigenen Artikel zu Core Web Vitals. Hier geht es um das, was dieser Artikel nicht abdeckt: wie man Page Speed in der Praxis misst und was ihn ausbremst.

Für die Messung von Page Speed reichen meist drei kostenlose Google-Werkzeuge.

PageSpeed Insights analysiert eine konkrete URL im Moment der Abfrage und liefert für diese Seite zwei unterschiedliche Datenblöcke: Labordaten und, sofern genug echte Besuche vorliegen, Felddaten. Es ist das gängigste Werkzeug für eine schnelle erste Prüfung.

Lighthouse ist die Engine, die die Laboranalyse durchführt, sowohl innerhalb von PageSpeed Insights als auch über die Chrome-Entwicklertools, die Kommandozeile oder ein Node-Modul. Es simuliert einen Besuch unter festen Bedingungen, mit einem Referenzgerät und einer Referenzverbindung, weshalb es bei unverändertem Code immer dasselbe Ergebnis liefert.

Der Geschwindigkeitsbericht beziehungsweise Core-Web-Vitals-Bericht der Search Console zeigt aggregierte Felddaten für Gruppen von URLs mit ähnlicher Struktur, nicht für eine einzelne Seite, und über ein Zeitfenster von mehreren Wochen. Er bildet am besten ab, was echte Besucher der Seite tatsächlich erleben, aktualisiert sich dafür aber langsamer als eine einzelne Stichprobenmessung. Für ein technisches Team ist er meist der richtige Ausgangspunkt für die Priorisierung, während Lighthouse eher für die tägliche Arbeit an einzelnen Vorlagen taugt.

Der Unterschied zwischen Labor- und Felddaten ist der Punkt, der Einsteiger am meisten verwirrt. Labordaten, die von Lighthouse stammen, entstehen in einer kontrollierten Umgebung: gleiches simuliertes Gerät, gleiche Netzwerkgeschwindigkeit, ohne das Rauschen tausender unterschiedlicher Verbindungen. Sie eignen sich, um ein konkretes Problem vor der Veröffentlichung einer Änderung zu debuggen, weil sie reproduzierbar sind. Felddaten, die aus dem Chrome User Experience Report (CrUX) stammen, kommen von echten Besuchen realer Chrome-Nutzer, die die Seite mit ihren eigenen Handys, Laptops und Verbindungen geladen haben, mit der ganzen Bandbreite, die das mit sich bringt.

Dass beide Werte nicht übereinstimmen, ist kein Fehler des Werkzeugs und kein Zeichen einer falschen Konfiguration. Sie messen von Natur aus unterschiedliche Dinge: Ein Labortest mit Glasfaser und einem Mittelklasse-Smartphone kann beim LCP "gut" ausfallen, während die realen Felddaten zeigen, dass ein Großteil der Besucher über ein Einsteigersmartphone mit schwachem 4G-Netz einsteigt, wodurch das aggregierte Ergebnis schlechter ausfällt. Weichen beide Zahlen stark voneinander ab, gibt bei der Priorisierung das Felddatum den Ausschlag, weil es beschreibt, was das Publikum tatsächlich erlebt.

Wichtig ist außerdem, wie das Felddatum überhaupt zustande kommt. PageSpeed Insights berechnet es über ein gleitendes 28-Tage-Fenster, es spiegelt also das aggregierte Verhalten der letzten vier Wochen wider, nicht das des aktuellen Tages. Bekommt eine konkrete URL nicht genug echten Traffic, erzeugt Chrome dafür kein Felddatum, es erscheint nur das Laborergebnis. In diesem Fall lohnt sich ein Blick auf den aggregierten Wert der URL-Gruppe mit ähnlicher Vorlage in Search Console, statt einfach anzunehmen, für diese Seite gebe es gar keine echten Performance-Daten.

Fast alle Page-Speed-Probleme lassen sich auf eine Handvoll technischer Ursachen zurückführen, die in Projekt um Projekt wiederkehren.

Unkomprimierte oder für ihre Anzeigefläche zu große Bilder sind die häufigste Ursache, besonders auf Seiten mit vielen Produktfotos oder redaktionellen Bildern. Die Lösung liegt darin, Bilder in modernen Formaten wie WebP oder AVIF auszuliefern, sie vor dem Hochladen zu komprimieren und responsive Größen zu verwenden, die je nach Gerät die passende Auflösung liefern, statt ein riesiges Bild nur per CSS zu verkleinern. Zusätzlich hilft verzögertes Laden, Lazy Loading, für Bilder außerhalb des ersten sichtbaren Bereichs, damit der Browser keine Bandbreite für Inhalt verbraucht, den der Nutzer noch gar nicht sieht.

Rendering-blockierendes JavaScript und CSS zwingen den Browser dazu, diesen Code herunterzuladen und auszuführen, bevor er überhaupt Inhalt anzeigen kann, selbst wenn dieser Code für den ersten sichtbaren Bereich gar nicht nötig ist. Üblich ist hier, nicht kritisches JavaScript zu verzögern oder asynchron zu laden und nur das für den Anfangsinhalt unbedingt nötige CSS inline einzubinden, den Rest erst danach. Nicht essenzielle Skripte mit den Attributen defer oder async zu markieren und zu prüfen, welcher Teil der Stylesheets für die erste sichtbare Fläche wirklich gebraucht wird, bringt dabei meist den größten Effekt im Verhältnis zum Aufwand.

Fehlendes Caching zwingt den Browser dazu, bei jedem Besuch Ressourcen neu herunterzuladen, die sich kaum ändern, etwa Logos, Stylesheets oder Bibliotheken. Die Lösung besteht darin, auf Server oder CDN passende Cache-Header zu setzen, damit diese Ressourcen eine angemessene Zeit im Browser gespeichert bleiben und nur bei echter Änderung neu angefragt werden. Dabei lohnt sich die Unterscheidung zwischen dem Browser-Cache, der statische Dateien wie Bilder oder Skripte speichert, und dem serverseitigen Full-Page-Cache, der verhindert, dass dynamisches HTML bei jedem Besuch neu erzeugt wird, obwohl sich der Inhalt gar nicht geändert hat.

Eine langsame Antwortzeit des Servers, bekannt als hoher TTFB, verzögert alles Weitere, weil der Browser erst nach der ersten Antwort mit dem Seitenaufbau beginnen kann. Hier hilft es, das Hosting zu prüfen, Server-Caching für Seiten zu aktivieren, die sich nicht bei jeder Anfrage ändern, und, wenn das Traffic-Volumen es rechtfertigt, auf ein CDN zu setzen, das Inhalte von einem Server näher am Nutzer ausliefert. Auf Seiten mit einem Content-Management-System stammt ein hoher TTFB häufig aus schlecht optimierten Datenbankabfragen oder aus Plugins, die bei jeder Anfrage aufwendige Aufgaben ausführen, weshalb sich ein Blick dorthin oft mehr lohnt als ein reiner Hosting-Wechsel.

Diese vier Bremsen treten selten allein auf. Eine Seite mit schweren Bildern und ohne serverseitiges Caching summiert die Effekte: Jede Ursache kostet für sich Zeit, und der Nutzer spürt die Gesamtsumme, nicht die einzelne Ursache. Deshalb löst sich eine Page-Speed-Prüfung selten mit nur einem Eingriff; sinnvoll ist, alle vier Ursachen im selben Durchgang zu prüfen, bevor man das Problem für gelöst hält.

• Dieselbe URL sowohl mit PageSpeed Insights als auch mit dem Core-Web-Vitals-Bericht der Search Console messen, bevor man Schlüsse zieht, um Labordaten mit echten Felddaten zu vergleichen.
• Bilder komprimieren und in modernen Formaten (WebP, AVIF) mit an das jeweilige Gerät angepassten Größen ausliefern, statt das Originalbild unverändert hochzuladen.
• Nicht kritisches JavaScript verzögern und nur das für den sichtbaren Anfangsinhalt nötige CSS inline laden.
• Cache-Header auf Server oder CDN für statische Ressourcen setzen, die sich selten ändern.
• Die Serverantwortzeit (TTFB) regelmäßig prüfen, nicht erst, wenn sich bereits Nutzer über Langsamkeit beschweren.

• Sich nur auf die Labordaten von Lighthouse verlassen und den Feldbericht der Search Console ignorieren, der die reale Erfahrung der Besucher besser abbildet.
• Ein "Speed-Optimierungs"-Plugin installieren, ohne zu prüfen, was es an der Seite tatsächlich verändert, und ohne das Ergebnis danach zu kontrollieren.
• Bilder in voller Auflösung hochladen und den Browser sie per CSS verkleinern lassen, statt die richtige Größe vorab zu erzeugen.
• Sämtliches JavaScript von Drittanbietern, Chats, Werbe-Pixel, Widgets, synchron im head laden und damit den Rest der Seite blockieren.
• Page Speed als einmalige Aufgabe vor einem Launch behandeln, statt ihn regelmäßig zu prüfen, wenn neue Inhalte und Funktionen dazukommen.