Was misst dieser Score überhaupt?

Wenn du den PageSpeed-Test machst, simuliert Google im Hintergrund einen Besuch auf deiner Website. Das ist ein Labor-Test: Eine künstliche Momentaufnahme, kein echter Besucher.

Dabei bekommst du immer zwei getrennte Ergebnisse: einmal für Mobile (simuliert ein eher schwaches Handy mit mittelmäßiger Internetverbindung) und einmal für Desktop (simuliert einen Computer mit einer schnelleren Verbindung). Die beiden Werte können sich deutlich unterscheiden – meist schneidet Desktop besser ab, weil Computer in der Regel mehr Rechenleistung haben und oft über eine stabilere Internetverbindung verfügen.

So sieht das in der Praxis aus: Hier siehst du die Auswertung meiner eigenen Website. Idealerweise leuchten die Kreise grün auf – im Desktop-Test (rechts) sind es bei mir glatte 100 Punkte, in der Mobil-Variante (links) starke 99 Punkte.

Das ist hilfreich, weil du dadurch siehst, wo es technisch hakt. Aber: Der PageSpeed-Score von 0 bis 100 selbst ist kein Rankingfaktor. Für die Bewertung der Seitenerfahrung spielen stattdessen unter anderem die Core Web Vitals eine Rolle. (Mehr zur Funktionsweise: Google für Entwickler – Über PageSpeed Insights)

Und was ist mit dem Tablet? Einen eigenen Tablet-Test gibt es bei PageSpeed Insights nicht, nur Mobile und Desktop. Willst du trotzdem wissen, wie sich deine Seite auf einem Tablet schlägt, kannst du sie über die Entwicklertools deines Browsers in einer Tablet-Ansicht öffnen. In der Praxis liegt ein Tablet ohnehin meist irgendwo zwischen Mobile und Desktop – sowohl bei der Geschwindigkeit als auch bei der Darstellung.

Was Google wirklich zur Bewertung nutzt: die Core Web Vitals

Google sammelt im Hintergrund echte Daten von echten Menschen, die deine Website tatsächlich besucht haben – mit ihrem eigenen Gerät, an ihrem eigenen Ort, in ihrem eigenen WLAN oder Mobilfunknetz. Auch hier wird unterschieden: Du bekommst getrennte Werte für Mobile (Besucher mit dem Handy) und Desktop (Besucher mit dem Computer), weil sich das Nutzerverhalten und die technischen Voraussetzungen stark unterscheiden können. Diese Messwerte aus realen Besuchen nennt man Felddaten oder echte Nutzerdaten. Für die Core Web Vitals betrachtet Google dabei drei Kennzahlen, die jeweils eine andere Frage beantworten:

Jeder dieser drei Werte wird mit „gut“, „verbesserungswürdig“ oder „schlecht“ bewertet. Und das Wichtigste dabei: Für die Bewertung betrachtet Google das 75. Perzentil der gemessenen Besuche. Du musst also nicht für jeden einzelnen Besuch perfekte Werte erreichen. (Quelle: web.dev – Core Web Vitals Schwellenwerte)

Was genau bedeutet „gut“ dabei?

Google betrachtet dafür das 75. Perzentil der Besuche innerhalb der letzten 28 Tage. Vereinfacht gesagt: Mindestens 75 % der gemessenen Besuche sollten den jeweiligen Grenzwert für „gut“ erreichen oder unterschreiten. Beim LCP bedeutet das beispielsweise, dass mindestens drei von vier gemessenen Seitenaufrufen einen LCP von höchstens 2,5 Sekunden haben sollten.

So sieht die Detail-Auswertung in der Praxis aus: Da viele kleinere Websites anfangs noch gar nicht genug echte Besucher für die letzten 28 Tage haben, wirft man für die Analyse meistens einen Blick auf die Laborwerte – hier am Beispiel meiner eigenen Website. Sowohl mobil (links) als auch am Computer (rechts) sind alle relevanten Labormesswerte wie LCP und CLS tiefgrün – so sieht in diesem Testdurchlauf ein sehr gutes technisches Ergebnis aus. (Hinweis: Den Wert für den echten Nutzer-Wert INP findest du in dieser reinen Labor-Übersicht übrigens nicht direkt als Zahl, da Google dort stattdessen die „Total Blocking Time“ als technischen Richtwert nutzt).

An diesen offiziellen Schwellenwerten kannst du dich bei den echten Nutzerdaten orientieren. LCP und CLS werden zusätzlich auch im Labor gemessen. INP dagegen benötigt echte Nutzerinteraktionen und erscheint deshalb im Lighthouse-Labortest nicht direkt; dort hilft unter anderem die Total Blocking Time (TBT) bei der technischen Diagnose.

Die drei Werte einfach erklärt

Largest Contentful Paint (LCP) – wie schnell sieht man etwas?

LCP misst, wie lange es dauert, bis der größte sichtbare Inhalt auf deiner Seite fertig da ist – meist ein großes Bild, ein Titelbild oder ein großer Textblock oben auf der Seite. Also der Moment, in dem ein Besucher das Gefühl hat: „Ah, die Seite ist da.“

Häufigste Ursache bei zu hohem Wert: zu große, nicht ausreichend komprimierte Bilder oder ein Server, der zu lange braucht, um die Seite auszuliefern.

Ein schlechter LCP muss allerdings nicht automatisch bedeuten, dass das größte sichtbare Element selbst zu groß ist. Auch ein zu spät entdecktes Hero-Bild, Lazy Loading beim wichtigsten Bild, render-blockierende Dateien oder eine langsame Serverantwort können dafür sorgen, dass der größte sichtbare Inhalt zu spät erscheint. Deshalb lohnt es sich, bei einem schlechten LCP nicht nur das betroffene Element selbst, sondern auch die Ursache für seine verspätete Darstellung genauer anzusehen.

Übrigens, mit „Server, der zu lange braucht“ ist nicht automatisch dein eigenes Hosting gemeint. Das kann zwei verschiedene Ursachen haben:

Für dich heißt das: Bevor du in besseres Hosting investierst, solltest du prüfen, wodurch die Verzögerung tatsächlich entsteht. Stammt das LCP-Element von deinem eigenen Server? Wird eine externe Ressource dafür benötigt? Oder wird das Element durch CSS, JavaScript oder Lazy Loading erst verspätet dargestellt?

Interaction to Next Paint (INP) – wie schnell reagiert die Seite?

INP misst, wie schnell deine Website reagiert, wenn jemand etwas anklickt, antippt oder eintippt. Stell dir vor, du klickst auf einen Button und nichts passiert – die Seite „hängt“ einen Moment. Genau das misst INP, und zwar nicht nur beim ersten Klick, sondern während des ganzen Besuchs.

Häufigste Ursache bei zu hohem Wert: zu viele oder zu schwere Skripte im Hintergrund – zum Beispiel von Werbeanzeigen, Chat-Fenstern oder Tracking-Tools.

Cumulative Layout Shift (CLS) – bleibt alles an seinem Platz?

Das kennst du bestimmt: Du willst auf einen Button klicken, und im letzten Moment springt ein Werbebanner dazwischen, und du klickst auf etwas ganz anderes. Genau das beschreibt CLS – wie sehr sich Inhalte auf deiner Seite ungewollt verschieben, während sie lädt.

Häufigste Ursache bei zu hohem Wert: Bilder oder eingebettete Inhalte ohne reservierten Platz, nachträglich eingefügte Elemente, Cookie-Banner, die bestehenden Inhalt verschieben, oder Schriftarten, deren Wechsel das Layout sichtbar verändert.

Warum „gut“ reicht – und die letzten Punkte oft deine Zeit verschwenden

Hier kommt der Kern der Sache: Diese drei „gut“-Grenzwerte oben sind nicht willkürlich gewählt. Google hat sie so festgelegt, dass sie eine gute Nutzererfahrung abbilden und zugleich für einen großen Teil der Websites technisch erreichbar sind. Liegt dein LCP beispielsweise bei 2,4 Sekunden, erfüllt er bereits den offiziellen Grenzwert für „gut“. Eine weitere Verbesserung auf 0,8 Sekunden kann die Seite zwar noch schneller wirken lassen, bringt dir allein deshalb aber keinen garantierten Ranking- oder Geschäftsvorteil.

Ein Beispiel macht das vielleicht greifbarer. Stell dir zwei Websites vor:

Welche Website hilft dem Besucher mehr? Genau – Website A. Sie ist technisch nicht perfekt, aber „gut genug“, und alles andere stimmt: Besucher kommen schnell an und finden sich zurecht. Website B hat die makellose Punktzahl, aber wenn die Besucher trotzdem nicht finden, was sie suchen, oder die Seite vor lauter Verwirrung wieder verlassen, hilft die perfekte Ladezeit niemandem – schon gar nicht dir.

Das zeigt: Die Punktzahl allein sagt nichts darüber aus, ob eine Website ihren Zweck erfüllt. Geschwindigkeit ist eine von mehreren Voraussetzungen für eine gute Website, aber bei weitem nicht die einzige.

Was die Geschwindigkeit NICHT ersetzt

Die schnellste Website der Welt verkauft nichts, wenn …

Genau das war ja schon der Punkt im Beispiel von Website A und B: Geschwindigkeit ist eine Grundvoraussetzung, keine Erfolgsgarantie. Sie sorgt dafür, dass ein Besucher überhaupt erst bleibt, statt sofort wieder zu gehen. Aber ob er sich danach für dich entscheidet, hängt von ganz anderen Dingen ab.

Ein Besucher, der in 0,8 Sekunden eine Seite sieht, auf der er nicht versteht, was du anbietest, ist genauso schnell wieder weg wie einer, der 4 Sekunden auf eine eigentlich klare, überzeugende Seite warten musste – vermutlich sogar schneller. Geschwindigkeit verschafft dir nur die Chance, dass ein Besucher überhaupt liest, was du zu sagen hast. Was er dann liest, entscheidet, ob er bleibt, dir vertraut und am Ende Kontakt aufnimmt oder kauft.

Deshalb lohnt es sich, die Energie, die du sonst in die letzten PageSpeed-Punkte stecken würdest, lieber in diese Fragen zu investieren: Versteht ein fremder Besucher innerhalb von Sekunden, worum es bei dir geht? Findet er sich auf deiner Seite zurecht, ohne lange suchen zu müssen? Sprechen deine Texte seine Sprache und seine Probleme an? Und ist klar, was er als Nächstes tun soll, wenn er überzeugt ist?

Eine Website, die diese Fragen gut beantwortet, ist am Ende erfolgreicher als eine, die nur durch ihre Ladezeit glänzt.

Wann solltest du wirklich optimieren?

Jetzt fragst du dich vielleicht: Wie finde ich raus, ob ich überhaupt etwas tun muss? Hier eine einfache Orientierung, an der du dich entlanghangeln kannst.

Du solltest optimieren, wenn …

Du musst (noch) nicht optimieren, wenn …

Eine kleine Faustregel: Schau dir deine Werte ein- bis zweimal im Jahr an, oder immer dann, wenn du größere Änderungen an deiner Website vornimmst (neues Bildmaterial, neue Plugins, neue Tools, ein Redesign). Dazwischen brauchst du nicht ständig nachzumessen.

Warum testest du eine Unterseite – und die Werte sehen trotzdem aus wie die deiner Startseite?

Das hier verwirrt viele: Du testest zum Beispiel eine einzelne Unterseite deiner Website, aber die angezeigten Werte sehen verdächtig nach den Werten deiner Startseite aus. Das ist kein Fehler – das macht Google absichtlich.

Erinnerst du dich an die Core Web Vitals von vorhin? Die basieren auf echten Besuchern. Damit Google diese Werte für eine einzelne Seite anzeigen kann, braucht es genug Besucherdaten zu genau dieser Seite. Hat eine Unterseite – zum Beispiel ein selten besuchter Blogartikel oder eine neue Unterseite – einfach zu wenig Klicks, reicht das nicht aus, um daraus verlässliche Werte zu berechnen.

Wichtig dabei: Das betrifft ausschließlich die echten Nutzerdaten, also die Core Web Vitals. Der Labor-Test (der Lighthouse-Labortest im Diagnosebereich, von dem wir am Anfang gesprochen haben) wird davon nicht beeinflusst. Er wird bei jedem Test live und ganz konkret für genau die Unterseite berechnet, die du gerade eingegeben hast – egal, wie viel oder wenig Traffic sie hat. Nur der Bereich mit den echten Besucherdaten kann stattdessen auf die zusammengefassten Origin-Daten der gesamten Website zurückgreifen.

In diesem Fall kann PageSpeed Insights stattdessen Daten für die gesamte Website-Herkunft – die sogenannte „Origin“ – anzeigen. Dabei werden die verfügbaren realen Nutzerdaten der gesamten Origin zusammengefasst. Das sind also keine Messwerte speziell für die gerade getestete Unterseite. Bei Websites, deren Traffic stark auf wenige Seiten konzentriert ist, können besonders häufig besuchte Seiten das Gesamtbild entsprechend stark mitprägen. (Quelle: Chrome for Developers – CrUX-Daten in PageSpeed Insights) Das bedeutet für dich konkret:

Was heißt das praktisch für dich? Wenn du bei einer wenig besuchten Unterseite auffällig hohe oder niedrige Felddaten siehst, die so gar nicht zu dieser Seite passen, prüfe zunächst, ob PageSpeed Insights überhaupt Daten für genau diese URL anzeigt. Möglicherweise siehst du stattdessen die zusammengefassten Origin-Daten deiner gesamten Website. Häufig besuchte Seiten können dieses Gesamtbild stark mitprägen, es handelt sich aber nicht um die konkreten Werte deiner Startseite.

Die Lösung dafür ist einfach: Verlasse dich bei ganz neuen oder selten besuchten Seiten zunächst stärker auf den Lighthouse-Labortest im Diagnosebereich, um technische Probleme aufzuspüren. Er wird konkret für die eingegebene Seite durchgeführt und steht unabhängig davon zur Verfügung, wie viele Besucher diese Seite hat.

Wie testest du den Speed deiner Website richtig?

Du hast jetzt vielleicht Lust, gleich selbst einen Test zu starten – das kannst du direkt hier tun: pagespeed.web.dev. Bevor du das tust, noch ein paar Punkte, die dir helfen, die Ergebnisse richtig einzuordnen – denn je nachdem, wie du testest, können ganz unterschiedliche Werte herauskommen, ohne dass sich an deiner Website wirklich etwas verändert hat.

Nutze den Inkognito-Modus nur, wenn du direkt im Browser testest (z. B. via DevTools). Hier eine wichtige Unterscheidung, die oft durcheinandergeht: Wenn du den Test über PageSpeed Insights (pagespeed.web.dev) durchführst, lädt Google deine Seite auf einem eigenen Server – dein eigener Browser-Cache und deine eigenen Erweiterungen spielen dabei gar keine Rolle, egal ob du gerade im Inkognito-Modus bist oder nicht. Anders sieht es aus, wenn du die Entwicklertools deines Browsers nutzt (zum Beispiel Chrome DevTools mit dem eingebauten Lighthouse-Tab) und damit direkt in deinem eigenen Browser testest. Dann zählen dein eigener Cache und deine eigenen Erweiterungen tatsächlich mit – und genau hier macht der Inkognito-Modus Sinn: Erweiterungen wie Werbeblocker oder Passwort-Manager laufen dort meist nicht mit, was dich vor verzerrten Ergebnissen schützt. Achte aber trotzdem auf den Cache (dazu gleich mehr) – ein Inkognito-Fenster ist nicht automatisch ein „leeres“ Fenster ohne gespeicherte Dateien, wenn du die Seite kurz vorher schon einmal besucht hast.

Achte auf den Unterschied zwischen „kalt“ und „warm“. Damit ist der sogenannte Cache gemeint – ein Zwischenspeicher, in dem ein Browser bereits geladene Dateien (Bilder, Schriften, Skripte) ablegt, damit er sie beim nächsten Besuch nicht erneut herunterladen muss.

PageSpeed Insights testet standardmäßig in einer kontrollierten Testumgebung, also unabhängig davon, wie oft du selbst die Seite bereits in deinem eigenen Browser geöffnet hast. Das ist auch die Variante, die für die meisten Websites am wichtigsten ist, weil neue Besucher genau diesen ersten Eindruck bekommen.

Testest du dagegen direkt in deinem eigenen Browser (z. B. über die Entwicklertools), zählt dein eigener Cache mit – besuchst du deine Seite kurz vorher schon einmal, bekommst du beim zweiten Aufruf einen „warmen“, schnelleren Wert, der nichts mit einer echten Verbesserung deiner Website zu tun hat. Willst du das selbst sehen: Lade deine Seite zweimal direkt hintereinander im selben Tab – der zweite Aufruf wirkt meist deutlich schneller. Das liegt am Cache, nicht an deiner Website.

Teste mehrmals, nicht nur einmal. Ein einzelner PageSpeed-Test ist immer nur eine Momentaufnahme. Internetverbindung, Serverauslastung und andere Zufälligkeiten können von Test zu Test leicht schwanken. Führe den Test ruhig zwei- oder dreimal hintereinander aus und schau dir an, wo sich die Werte ungefähr einpendeln, statt dich an einem einzigen Ergebnis festzuhalten.

Verlasse dich am Ende auf die echten Nutzerdaten, nicht nur auf den Labor-Test. Wie du jetzt weißt, ist der Labor-Test nur eine Momentaufnahme unter Testbedingungen. Die Core-Web-Vitals-Felddaten zeigen dir dagegen, wie es den erfassten echten Besuchern im zurückliegenden 28-Tage-Zeitraum erging. Für die Beurteilung der realen Nutzererfahrung sind diese Werte deshalb aussagekräftiger als ein einzelner Labortest.

Warum zeigt mir derselbe Test jedes Mal andere Werte?

Das kennst du vielleicht: Du testest deine Seite, bekommst 90 Punkte, freust dich – und am nächsten Tag, ohne dass du auch nur eine Kleinigkeit verändert hast, zeigt derselbe Test plötzlich nur noch 78 Punkte an. Das verunsichert, ist aber völlig normal. Der PageSpeed-Test ist kein Maßband, das jedes Mal exakt dasselbe misst, sondern eher wie eine Verkehrsmessung: Sie hängt von vielen Dingen ab, die nichts mit deiner Website selbst zu tun haben. (Google bestätigt das übrigens selbst, siehe Google für Entwickler – Lighthouse Variability) Die wichtigsten Gründe dafür:

Ein besonders trickreicher Fall sind zustimmungsabhängige Dienste: Viele Chat-Widgets, Tracking-Tools oder Werbeskripte werden erst geladen, nachdem ein Besucher im Cookie-Banner zugestimmt hat. Ein automatischer PageSpeed-Test erteilt in der Regel keine solche Einwilligung. Er misst dann möglicherweise nur die leichtere Variante der Seite, ohne die zusätzlich nachgeladenen Skripte, und zeigt einen sehr guten Laborwert an. Stimmen reale Besucher der entsprechenden Datenverarbeitung zu, werden diese Dienste anschließend geladen und können ihre tatsächliche Nutzererfahrung beeinflussen. Das ist ein möglicher Grund dafür, dass Labor- und Felddaten deutlich voneinander abweichen.

Fazit: Verstehe, worauf es wirklich ankommt

Der PageSpeed-Score ist ein nützliches Werkzeug, um Schwachstellen zu finden – aber kein Ziel, das du um jeden Preis erreichen musst. Entscheidend für die Beurteilung der realen Nutzererfahrung sind vor allem die Felddaten der drei Core Web Vitals: LCP, INP und CLS. Schneidest du dort überall gut ab, bietet deine Website den erfassten Besuchern in diesen drei zentralen Bereichen eine gute Nutzererfahrung. Ganz egal, ob der Score am Ende 88 oder 100 anzeigt.

Du musst das alles nicht selbst im Detail technisch umsetzen können – wichtig ist vor allem, dass du verstehst, worauf es ankommt, damit du beim nächsten technischen Gespräch über deine Website nicht völlig im Nebel stehst.

Eine Website mit 95 Punkten wird nicht automatisch erfolgreicher als eine mit 85 Punkten. Eine Website, die Besucher versteht, ihre Fragen beantwortet und Vertrauen aufbaut, dagegen oft schon.