Page Speed

Page Speed bezeichnet, wie schnell eine Seite lädt und benutzbar wird. Der Begriff stammt von Googles gleichnamigem Analysewerkzeug und hat sich als Sammelbezeichnung durchgesetzt. Gemeint ist damit heute selten eine einzelne Zeitangabe: Der Seitenaufbau zerfällt in Phasen, die unterschiedliche Ursachen haben und deshalb getrennt gemessen werden.

Die Core Web Vitals

Seit 2020 fasst Google die aus seiner Sicht entscheidenden Messwerte unter dem Namen Core Web Vitals zusammen. Es sind drei.

Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element im Sichtbereich fertig gerendert ist — in der Regel ein Titelbild, ein Video-Vorschaubild oder ein großer Textblock. Bis 2,5 Sekunden gilt der Wert als gut, ab 4 Sekunden als schlecht.

Interaction to Next Paint (INP) misst die Reaktionszeit auf Eingaben: Wie lange dauert es vom Klick, Tap oder Tastendruck, bis die Seite sichtbar reagiert? Bewertet wird dabei nicht die erste Interaktion, sondern praktisch die schlechteste eines Seitenbesuchs. INP hat im März 2024 den älteren First Input Delay (FID) abgelöst. FID erfasste nur die Verzögerung bis zum Beginn der Verarbeitung, nicht deren Dauer, und lieferte deshalb fast überall gute Werte — auch auf Seiten, die sich für Nutzer zäh anfühlten. Bis 200 Millisekunden gilt INP als gut, ab 500 Millisekunden als schlecht.

Cumulative Layout Shift (CLS) misst, wie stark sich das Layout während des Ladens noch verschiebt. Gemeint ist der Effekt, bei dem eine Schaltfläche wegrutscht, weil darüber verspätet ein Bild oder ein Werbebanner einspringt. Der Wert ist dimensionslos, bis 0,1 gilt er als gut, ab 0,25 als schlecht.

Die häufigste Ursache für hohe CLS-Werte ist banal: Bilder und eingebettete Elemente ohne Angabe von Breite und Höhe. Der Browser kann dann keinen Platz reservieren und schiebt den Rest der Seite beiseite, sobald die Datei eintrifft.

Felddaten und Labordaten

Zwei Messarten liefern unterschiedliche Antworten, und die Verwechslung der beiden ist die häufigste Fehlerquelle bei der Bewertung.

Felddaten stammen aus dem Chrome User Experience Report (CrUX): anonymisierte Messwerte echter Chrome-Nutzer, gesammelt über ein fortlaufendes Zeitfenster der letzten 28 Tage. Sie bilden ab, was Besucher tatsächlich erleben — mit ihren Geräten, ihren Verbindungen, ihren Standorten. Bewertet wird das 75. Perzentil: Erst wenn drei Viertel der gemessenen Aufrufe unter dem Schwellenwert liegen, gilt eine URL als bestanden. Der Median genügt also nicht.

Labordaten erzeugt Lighthouse in einer simulierten Umgebung mit festen Annahmen zu Gerät und Netzwerk. Der Vorteil: Das Ergebnis ist reproduzierbar und lässt sich vor dem Livegang messen. Der Nachteil: Es ist eine Simulation. Der Lighthouse-Score von 0 bis 100 ist ein gewichteter Mischwert aus mehreren Labormetriken und keine Note, die Google fürs Ranking verwendet. INP lässt sich im Labor überhaupt nicht messen, weil dort niemand klickt; Lighthouse weist stattdessen die Total Blocking Time als Näherung aus.

PageSpeed Insights zeigt beides untereinander an — oben die Felddaten, sofern für die URL genug Messungen vorliegen, darunter den Lighthouse-Lauf. Für eine Übersicht über die gesamte Website ist der Core-Web-Vitals-Bericht in der Search Console der bessere Einstieg: Er gruppiert URLs mit ähnlichem Verhalten, sodass sich Probleme meist einem Seitentyp zuordnen lassen statt einer einzelnen Adresse.

Woran es in der Praxis hängt

Die Ursachen wiederholen sich über Projekte hinweg erstaunlich zuverlässig.

• Bilder. Zu große Dateien, in voller Auflösung ausgeliefert und per CSS heruntergerechnet. Moderne Formate wie WebP und AVIF, passende Größen über srcset und loading="lazy" für alles unterhalb des Sichtbereichs lösen einen Großteil davon.
• Antwortzeit des Servers. Bevor der Browser überhaupt etwas rendern kann, muss das erste Byte ankommen. Langsame Datenbankabfragen, fehlendes Caching und knapp bemessene Hosting-Pakete wirken direkt auf LCP. Wo der Flaschenhals in der Infrastruktur liegt, lässt sich oft schon durch schnelleres Hosting entschärfen.
• Skripte von Drittanbietern. Consent-Banner, Tag Manager, Chat-Widgets, A/B-Testing-Tools, Werbe- und Trackingcode. Sie sind der Bereich, über den in Optimierungsprojekten am seltensten gesprochen wird und der am häufigsten den größten Anteil ausmacht — nicht zuletzt, weil das Consent-Banner naturgemäß vor allem anderen läuft.
• Blockierendes CSS und JavaScript. Dateien im Seitenkopf, die den Aufbau anhalten, bis sie geladen und ausgewertet sind. Was JavaScript im Browser leisten muss, wirkt sich vor allem auf INP aus, weil ein blockierter Hauptthread keine Eingaben verarbeiten kann.
• Schriften. Webfonts, die spät nachgeladen werden, führen zu Textsprüngen; font-display und Preloading begrenzen den Effekt.

Der Ratschlag, CSS-Dateien zu Sprites zu bündeln und Requests um jeden Preis zu reduzieren, stammt aus der HTTP/1.1-Zeit. Mit HTTP/2 und HTTP/3 werden Anfragen parallel über eine Verbindung abgewickelt; die Anzahl der Dateien ist damit nicht mehr das Problem, ihr Gesamtgewicht schon.

Was Page Speed fürs Ranking bedeutet

Google berücksichtigt Ladezeit seit 2010 im Ranking, zunächst nur für Desktop-Suchen, seit dem Speed Update 2018 auch mobil. 2021 kamen die Core Web Vitals als Teil des Page-Experience-Signals hinzu.

Der ehrliche Befund lautet: Es ist ein bestätigter, aber schwacher Faktor. Google beschreibt ihn selbst als etwas, das bei inhaltlich vergleichbaren Ergebnissen den Ausschlag geben kann — eine wirklich passende Antwort schlägt eine schnellere, die schlechter passt. Der Signalkomplex ist zudem mehrfach neu eingeordnet worden; Google spricht inzwischen weniger von einem eigenen Rankingsystem als von einer Reihe von Empfehlungen zum Seitenerlebnis. Eine langsame Seite verliert also nicht deshalb, weil ein Zähler unter einem Schwellenwert liegt, sondern weil sie schlechter benutzbar ist. Wo Ladezeit im Verhältnis zu anderen Signalen steht, ordnet der Eintrag zu den Rankingfaktoren ein.

Abbrüche, Umsatz und die Zahlen dazu

Dass langsame Seiten mehr Abbrüche produzieren, ist unstrittig und im eigenen Analysewerkzeug meist gut sichtbar. Die Prozentwerte, die dazu seit Jahren zirkulieren — X Prozent Umsatzverlust je zusätzlicher Sekunde —, stammen aus einzelnen Unternehmensmessungen, sind teils über ein Jahrzehnt alt und lassen sich auf andere Websites nicht übertragen. Wer wissen will, was Ladezeit im eigenen Shop kostet, misst es selbst: Abbruchraten nach Ladezeit-Segment, verglichen über Templates und Gerätetypen. Das ist Teil der Conversion-Optimierung und liefert belastbarere Argumente als jede fremde Studie.

Vorgehen bei der Optimierung

Zuerst die Felddaten ansehen, nicht den Lighthouse-Score. Dann nach Seitentyp sortieren statt nach Einzel-URL: Wenn alle Produktdetailseiten dieselbe LCP-Schwäche zeigen, liegt es am Template, nicht an einem Produkt. Danach in der Reihenfolge des Hebels arbeiten — Bilder, Drittanbieter-Skripte, Serverantwortzeit — und nach jedem Eingriff neu messen, statt eine Liste von Empfehlungen pauschal abzuarbeiten.

Ausführlicher beschreibt das der Beitrag zur Optimierung der Seitenladezeiten. Ladezeit ist dabei ein Teilgebiet des Technical SEO und entfaltet seine Wirkung erst zusammen mit sauberem Crawling, korrekter Indexierung und Inhalten, die zur Suchanfrage passen.