BlogWebsite-Performance

Core Web Vitals und PageSpeed: Der Preis einer langsamen Website

PageSpeed Insights zeigt zwei verschiedene Dinge: einen simulierten Labortest und Felddaten aus echten Chrome-Nutzungen. Die Core Web Vitals beschreiben Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität. Wer beide Ebenen auseinanderhält, erkennt, warum eine Website langsam wirkt, und welcher Eingriff tatsächlich hilft.

von Oli Feiler · 9. September 2026

Ein PageSpeed-Score ist noch keine Diagnose

„Die Website ist langsam" gehört zu den häufigsten Sätzen, die eine Geschäftsführung über den eigenen Auftritt zu hören bekommt, mal von Kundschaft, mal vom eigenen Marketingteam, mal einfach vom Warten auf die Startseite im eigenen Büro. Der Satz beschreibt ein Symptom, keine Ursache. PageSpeed Insights kann bei der Diagnose helfen, zeigt dafür allerdings zwei grundverschiedene Ansichten: einen Performance-Score aus einem simulierten Testlauf und, sofern genügend Daten vorliegen, die Core-Web-Vitals-Bewertung aus echten Chrome-Nutzungen. Wer beides miteinander verwechselt, hat eine scheinbar präzise Zahl, aber noch keine Diagnose.

Der Performance-Score von 0 bis 100 stammt aus einem einzelnen, simulierten Lighthouse-Labortest, in den First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time und Cumulative Layout Shift unterschiedlich gewichtet einfließen, aktuell mit dem größten Anteil für Total Blocking Time, gefolgt von Largest Contentful Paint und Cumulative Layout Shift. Die Core-Web-Vitals-Bewertung dagegen stammt aus aggregierten Felddaten des Chrome User Experience Report und beruht auf LCP, INP und CLS. Interaction to Next Paint fließt dabei gar nicht direkt in den Lighthouse-Score ein, weil der automatisierte Testlauf keine echte Interaktion simuliert; Lighthouse verwendet stattdessen Total Blocking Time als verwandte Diagnosemetrik (1). Daher kann der Performance-Score schlecht ausfallen, obwohl die Core Web Vitals gut sind, und umgekehrt.

Was Google misst: LCP, INP, CLS

Die Core Web Vitals übersetzen drei Aspekte des Nutzungserlebnisses in messbare Kennzahlen: wann der wichtigste Inhalt sichtbar wird, wie schnell die Seite reagiert und wie stabil ihr Layout bleibt. Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte Inhaltselement im sichtbaren Bereich, meist ein Hero-Bild oder eine große Überschrift, vollständig gerendert ist. Interaction to Next Paint (INP) misst, wie schnell eine Seite auf Klicks, Taps oder Tastatureingaben reagiert; maßgeblich ist über die gesamte Sitzung hinweg die langsamste beziehungsweise bei vielen Eingaben annähernd langsamste qualifizierte Interaktion. Cumulative Layout Shift (CLS) misst, wie stark sich Inhalte während des Ladens und der weiteren Nutzung ungewollt verschieben, etwa wenn ein später nachgeladenes Element bereits sichtbaren Text nach unten schiebt.

WertLeitfrageGut
LCPWann ist der wichtigste Inhalt sichtbar?bis 2,5 s
INPWie schnell kann die Seite sichtbar auf eine Interaktion reagieren?bis 200 ms
CLSWie stabil bleibt das Layout?bis 0,1

Für die Bewertung zählt nicht der beste oder durchschnittliche Seitenaufruf, sondern das 75. Perzentil echter Nutzungsdaten aus einem rollierenden 28-Tage-Fenster. Eine Seite besteht die Bewertung nur, wenn das 75. Perzentil bei allen drei Messwerten im guten Bereich liegt. Mobile und Desktop-Aufrufe werden dabei getrennt betrachtet. Die Datenbasis dafür ist der Chrome User Experience Report, kurz CrUX, der ausschließlich einwilligende Chrome-Nutzungen erfasst, nicht die gesamte Besucherschaft einer Website. Liegen für eine einzelne URL zu wenige Daten vor, zeigt PageSpeed Insights unter Umständen ersatzweise zusammengefasste Daten des Origins, vereinfacht also der Website, ein Hinweis, der in der Oberfläche leicht übersehen wird.

Ladezeit endet nicht in der Entwicklungsabteilung

Der eigentliche Grund, weshalb sich die Beschäftigung mit diesen drei Werten lohnt, liegt selten in der Suchmaschinenoptimierung selbst, sondern im Verhalten der Besucherinnen und Besucher. Eine viel zitierte Untersuchung von Google und dem Analyseunternehmen SOASTA modellierte anhand eines Vorhersagemodells, dass die Abbruchwahrscheinlichkeit eines mobilen Besuchs um 32 Prozent steigt, wenn die Ladezeit von einer auf drei Sekunden wächst, und um 90 Prozent bei fünf Sekunden. Die oft zitierte Zahl, wonach über die Hälfte der mobilen Besuche nach mehr als drei Sekunden abgebrochen wird, stammt aus einer separaten DoubleClick-/Google-Untersuchung von 2016 auf Basis von mehr als 10.000 mobilen Domains sowie Daten aus Google Analytics und DoubleClick, die dieselbe Veröffentlichung ebenfalls anführt (2). Beide Werte sind eher eine historische Größenordnung als ein aktuelles Naturgesetz, die Richtung hat sich seither aber nicht umgekehrt.

Die Marketing-Agentur Portent kommt in einer eigenen Analyse zu einem ähnlichen Bild aus der anderen Richtung. Portent wertete dafür 5,6 Millionen Sitzungen auf 20 B2B- und B2C-Websites aus, darunter sechs E-Commerce-Angebote. Bei diesen sechs Angeboten lag die Conversion-Rate von Seiten mit einer Sekunde Ladezeit rund 2,5-mal so hoch wie bei fünf Sekunden (3). Das ist eine starke Korrelation innerhalb einer begrenzten Stichprobe, kein universeller Umrechnungsfaktor für jede Branche.

Auf web.dev finden sich mehrere Unternehmensfallstudien, deren Aussagekraft unterschiedlich ist. Am aussagekräftigsten ist der A/B-Test von Vodafone Italien: Bei identischem Design und identischer Funktionalität verkürzte die optimierte Variante durch Änderungen an Rendering, JavaScript und Bildauslieferung den LCP-Wert um 31 Prozent und erzielte acht Prozent mehr Verkäufe. Andere Fallstudien erlauben keine ebenso eindeutige Zuordnung: Bei der indischen Nachrichtenseite NDTV korrelierte eine LCP-Verbesserung um 55 Prozent mit einer halbierten Absprungrate, allerdings bei gleichzeitig weiteren Produktänderungen, ein Vorbehalt, den die Quelle selbst nennt. Der Kosmetikhändler Nykaa berichtete nach einer 40-prozentigen LCP-Verbesserung von 28 Prozent mehr organischem Traffic aus kleineren indischen Städten, gerade dort, wo Mobilfunknetze langsamer sind (4). Diese Fallstudien liefern keine allgemeingültige Umsatzformel. Sie zeigen aber, dass sich Performance wirtschaftlich messen lässt, sobald jemand die Mühe macht, sie zu isolieren.

PageSpeed Insights lesen, ohne Entwickler zu sein

Wer die eigene URL bei PageSpeed Insights einträgt, bekommt zwei unterschiedliche Datensätze angezeigt, die häufig verwechselt werden. Die Felddaten stammen, wie beschrieben, aus dem Chrome User Experience Report und spiegeln echte Nutzungen der vergangenen 28 Tage; sie sind die Grundlage für die Core-Web-Vitals-Bewertung. Die Labordaten darunter stammen aus einem einzelnen Lighthouse-Testlauf mit einem standardisierten mobilen oder Desktop-Testprofil; im mobilen Bericht werden Gerät und Verbindung bewusst gedrosselt (5). Ein Lighthouse-Score ab 90 gilt als gut. Ein Wert von 100 weist aber lediglich eine sehr gute Leistung unter diesen Testbedingungen nach und eignet sich deshalb kaum als eigenständiges Geschäftsziel.

Wenn Labor- und Felddaten auseinanderfallen, hat das selten nur einen Grund. Ein schlechter Laborwert bei guten Felddaten kann bedeuten, dass der Test unter härteren Bedingungen lief als der durchschnittliche Besuch, er kann aber ebenso am Cache-Zustand, an URL- gegenüber zusammengefassten Website-Daten, an der regionalen Verteilung der Besucherschaft oder schlicht an der Variabilität eines einzelnen Testlaufs liegen. Ein guter Laborwert bei schlechten Felddaten ist tendenziell das ernstere Signal: Er deutet darauf hin, dass ein Teil der echten Besucherschaft, etwa mit älteren Geräten oder schwächerem Mobilfunk, eine deutlich schlechtere Erfahrung macht, als der eigene Bildschirm es vermuten lässt. Wer mehrere Seiten im Blick behalten will, findet die gleichen Felddaten gebündelt im Core-Web-Vitals-Bericht der Google Search Console.

Für die Suche gilt dabei eine Einschränkung, die selten deutlich gesagt wird: Core Web Vitals fließen in Googles Ranking-Systeme ein, sind aber kein eigenständiger Page-Experience-Score und keine Garantie für bessere Platzierungen. Google selbst rät ausdrücklich davon ab, allein für die Suchmaschinenoptimierung einem perfekten Messwert hinterherzujagen.

Woran es meistens hakt

Der Web Almanac des HTTP Archive liefert keine Diagnose für eine einzelne Website, aber verlässliche Hinweise darauf, wo sich die Suche über Millionen untersuchter Seiten hinweg am häufigsten lohnt. 2025 war auf 85,3 Prozent der untersuchten Desktopseiten und 76 Prozent der mobilen Seiten ein Bild das LCP-Element (6). Das macht die Bildauslieferung zu einem naheliegenden ersten Prüfpunkt, beweist für eine konkrete Website aber noch nicht, dass die Datei selbst zu groß oder falsch dimensioniert ist. Ein schlechter LCP-Wert kann ebenso durch eine langsame Serverantwort, eine zu spät im Code entdeckte Bildquelle oder eine verzögerte Darstellung entstehen.

Ähnlich vorsichtig lässt sich der CLS-Wert lesen. 62 Prozent der mobilen Seiten enthielten mindestens ein Bild ohne feste Breiten- und Höhenangabe, 87 Prozent verwendeten mindestens einen Webfont. Beides erhöht das Risiko sichtbarer Verschiebungen, ist aber nicht automatisch deren Ursache: Ein Bild ohne feste Maße beeinflusst den CLS nur dann, wenn sein späteres Erscheinen bereits dargestellte sichtbare Inhalte tatsächlich verschiebt.

Beim INP-Wert liegt der Engpass meist in langen Aufgaben auf dem Hauptthread, dem zentralen Ausführungsstrang, auf dem der Browser unter anderem JavaScript, Layout und Teile des Renderings nacheinander abarbeitet. Ausgelöst werden kann das durch eigenen Anwendungscode ebenso wie durch fremdes JavaScript aus Drittanbieter-Skripten, durch aufwendige Ereignisverarbeitung oder durch Layoutberechnungen, die auf eine Interaktion folgen. Eine langsame erste Serverantwort, das sogenannte Time to First Byte, verlängert unmittelbar den LCP-Wert und kann weitere Ladevorgänge verzögern, wirkt sich aber nicht zwangsläufig auf INP oder CLS aus.

Eine Checkliste, die realistisch bleibt

Eine vollständige Performance-Optimierung ist Entwicklerarbeit. Wer aber als Auftraggeberin oder Auftraggeber beurteilen will, ob ein Angebot die richtigen Punkte trifft, kann sich an sechs Hebeln orientieren, die in der Praxis den größten Unterschied machen:

  • Bilder: richtige Auflösung statt Originaldatei, moderne Formate wie WebP oder AVIF, feste Breiten- und Höhenangaben sowie srcset und sizes für unterschiedliche Bildschirmgrößen. Das Bild, das den LCP-Wert bestimmt, sollte nie lazy geladen werden, denn genau das verzögert die Anzeige des wichtigsten Inhalts.
  • Serverantwortzeit: nicht pauschal zuerst das Hosting wechseln, sondern zunächst klären, ob Zeit im Netzwerk, im Server, in der Datenbank, im Seitenaufbau oder an fehlendem Caching verloren geht. Ob Backend oder Frontend zuerst angefasst wird, ergibt sich aus der Messung, nicht aus einer Faustregel.
  • Eigenes JavaScript und der Hauptthread: große Skriptpakete, umfangreiche DOM-Strukturen und aufwendige Layoutberechnungen verschlechtern den INP-Wert genauso wie fremder Code.
  • Drittanbieter-Skripte: eine ehrliche Bestandsaufnahme aller eingebundenen Tools, von Tracking-Skripten über Chat-Widgets bis zu eingebetteten Karten, denn jedes davon lädt eigenen Code nach, der den Hauptthread blockieren kann.
  • Schriftarten: wenige Schriftschnitte, das Format WOFF2, Subsetting auf tatsächlich benötigte Zeichen, eine passende font-display-Strategie und, wo möglich, metrisch ähnliche Fallback-Schriften. Wahllos viele Schriften vorab zu laden verschlechtert die Lage eher, als sie zu verbessern.
  • Monitoring nach der Optimierung: ein Performance-Budget oder laufendes Real-User-Monitoring, damit das nächste eingebaute Chat-Widget den erzielten Gewinn nicht wieder auffrisst.

Weil Google mit einem rollierenden 28-Tage-Fenster arbeitet, werden Verbesserungen zwar täglich in kleinen Schritten sichtbar, vollständig ausgetauscht ist der alte Messzeitraum aber erst nach 28 Tagen. Wer bei den Bildern und externen Verbindungen tiefer einsteigen will, findet dazu bereits eine technische Vertiefung zu Resource Hints wie preload, prefetch und preconnect.

Wie schnell ist Ihre Website wirklich, und für wen?

Ein PageSpeed-Score sagt wenig darüber aus, wie die eigene Website sich für jemanden mit einem günstigen Smartphone in einem schwachen Mobilfunknetz tatsächlich anfühlt. Die Felddaten kommen dieser Antwort näher, auch wenn selbst sie nur einen Ausschnitt der Besucherschaft erfassen. Wer diese Frage einmal ehrlich beantwortet hat, hört auf, über eine einzelne Zahl zu diskutieren, und fängt an, über die Menschen zu sprechen, die tatsächlich warten.

Quellen

  1. Chrome for Developers / Google web.dev: Largest Contentful Paint, Interaction to Next Paint,   Cumulative Layout Shift und Lighthouse-Performance-Scoring
  2. An, Daniel / Meenan, Pat (Google, 2016/2017, teils gemeinsam mit SOASTA Research): Mobile Page Speed: New Industry Benchmarks, Think with Google
  3. Portent (2022): Site Speed is (Still) Impacting Your Conversion Rate
  4. web.dev / Google, Fallstudien Vodafone Italien, NDTV, Nykaa: The business impact of Core Web Vitals
  5. Google Search Central: About PageSpeed Insights und Understanding Core Web Vitals and Google Search results
  6. Jariyal, Rasam, Humaira, Grogg (HTTP Archive; Datenbasis Juli 2025, veröffentlicht 15.1.2026):   Performance, The 2025 Web Almanac, Kapitel 7

Mehr zum Thema

 alt=

Ein Score allein löst kein Problem.

Eine belastbare Performance-Analyse liest Feld- und Labordaten zusammen und weiß, wo in einem konkreten System tatsächlich Zeit verloren geht, nicht nur, wo eine Checkliste es vermuten lässt.
Marian Feiler, Projektmanager