Google PageSpeed Insights gehört zu den bekanntesten Werkzeugen zur Analyse der Performance einer Website. Du gibst eine URL ein und erhältst Messwerte, Bewertungen und technische Hinweise zur untersuchten Seite.
Die eigentliche Herausforderung besteht jedoch nicht darin, einen PageSpeed-Test zu starten. Entscheidend ist, die angezeigten Ergebnisse richtig zu interpretieren.
Ein Performance-Score von 100 bedeutet nicht automatisch, dass eine Website perfekt ist. Umgekehrt bedeutet ein niedrigerer Score nicht, dass du jeden angezeigten Hinweis sofort umsetzen solltest.
In dieser Anleitung zeigen wir dir, wie du Google PageSpeed Insights sinnvoll verwendest, welche Bereiche besonders wichtig sind und wie du aus den Ergebnissen konkrete Optimierungsmaßnahmen ableitest.
Kurz erklärt: PageSpeed Insights ist ein Diagnosewerkzeug. Nutze es, um Performance-Probleme zu erkennen und zu priorisieren – nicht als Wettbewerb um möglichst viele grüne Punkte.
Was ist Google PageSpeed Insights? #
PageSpeed Insights, kurz PSI, ist ein Analysewerkzeug von Google für die Performance von Webseiten auf mobilen Geräten und Desktop-Systemen.
PSI kombiniert dabei zwei grundsätzlich unterschiedliche Arten von Daten:
Felddaten
→ Erfahrungen echter Nutzer
Labordaten
→ kontrollierter Lighthouse-Test
Zusätzlich liefert die Analyse technische Diagnosen und Hinweise, mit denen sich mögliche Performance-Probleme untersuchen lassen.
PageSpeed Insights aufrufen #
Öffne PageSpeed Insights unter:
Gib anschließend die vollständige URL der Seite ein, die du untersuchen möchtest.
Beispiel:
Starte danach die Analyse.
Praxis-Tipp: Teste nicht automatisch nur deine Startseite. Wenn du wissen möchtest, weshalb beispielsweise eine Produktseite langsam ist, musst du genau diese Produktseite analysieren.
Welche URL sollte ich testen? #
Eine Website besteht häufig aus unterschiedlichen Seitentypen mit völlig unterschiedlichen technischen Anforderungen.
Eine Startseite kann beispielsweise schnell sein, während eine Produktseite zahlreiche Bilder, Varianten und zusätzliche Scripts lädt.
Je nach Website solltest du deshalb mehrere repräsentative URLs untersuchen.
Das können beispielsweise sein:
Startseite
wichtige Leistungsseite
Landingpage
Blogartikel
Shop-Kategorieseite
Produktseite
Checkout
Damit erhältst du ein wesentlich realistischeres Bild als durch einen einzelnen Test der Startseite.
Mobile und Desktop getrennt betrachten #
PageSpeed Insights unterscheidet zwischen mobilen Geräten und Desktop-Systemen.
Die Ergebnisse können deutlich voneinander abweichen.
Das liegt unter anderem daran, dass sich die Testbedingungen und die verfügbare Rechenleistung unterscheiden können.
Eine Website, die auf einem leistungsfähigen Desktop-System problemlos verarbeitet wird, kann auf einem schwächeren mobilen Gerät deutlich stärker gefordert sein.
Wichtig: Ignoriere die mobile Analyse nicht, nur weil der Desktop-Score besser aussieht. Für viele Websites ist die mobile Nutzung ein wesentlicher Teil des tatsächlichen Besucherverkehrs.
Die zwei wichtigsten Datenbereiche verstehen #
Bei PageSpeed Insights solltest du grundsätzlich zwischen Felddaten und Labordaten unterscheiden.
Felddaten
→ reale Nutzung in der Vergangenheit
Labordaten
→ aktueller synthetischer Test unter definierten Bedingungen
Diese Daten beantworten unterschiedliche Fragen und können deshalb unterschiedliche Ergebnisse liefern.
Was sind die Felddaten in PageSpeed Insights? #
Die Felddaten stammen aus dem Chrome User Experience Report, kurz CrUX.
Sie basieren auf anonymisierten Messungen realer Chrome-Nutzer unter unterschiedlichen Geräte- und Netzwerkbedingungen.
Die angezeigten Felddaten bilden einen rollierenden Zeitraum der vergangenen 28 Tage ab.
Damit zeigen sie nicht einfach, wie die Seite genau in diesem Moment funktioniert, sondern wie reale Nutzer sie über einen längeren Zeitraum erlebt haben.
Welche Werte zeigt der Felddatenbereich? #
Zu den dort relevanten Kennzahlen gehören unter anderem:
LCP → Largest Contentful Paint
INP → Interaction to Next Paint
CLS → Cumulative Layout Shift
FCP → First Contentful Paint
TTFB → Time to First Byte
Die eigentlichen Core Web Vitals sind:
LCP
INP
CLS
Diese drei Kennzahlen erklären wir ausführlich unter Core Web Vitals erklärt: LCP, INP und CLS.
Warum werden manchmal keine Felddaten angezeigt? #
Nicht jede URL verfügt über ausreichend CrUX-Daten.
Das kann insbesondere bei neuen Websites, wenig besuchten Seiten oder URLs mit zu wenig geeigneten Messdaten vorkommen.
PageSpeed Insights kann dann möglicherweise keine belastbaren Felddaten für diese URL darstellen.
Das bedeutet nicht, dass die Seite nicht analysiert werden kann.
Die Lighthouse-Labordaten können weiterhin für die technische Diagnose verwendet werden.
Wichtig: „Keine Daten“ bedeutet nicht „schlechte Performance“. Es bedeutet zunächst nur, dass für die betreffende Auswertung nicht genügend reale Nutzungsdaten vorliegen.
URL-Daten und Ursprungsdaten unterscheiden #
Je nach Datenverfügbarkeit kann PageSpeed Insights Informationen für die konkret getestete URL oder aggregierte Daten für den Ursprung der Website darstellen.
Das ist ein wichtiger Unterschied.
Vereinfacht:
URL-Daten
→ Erfahrungen mit genau dieser Seite
Origin-/Ursprungsdaten
→ aggregierte Erfahrungen mit Seiten
derselben Website-Herkunft
Achte deshalb darauf, auf welcher Datenbasis die angezeigten Werte beruhen.
Was bedeutet „Core Web Vitals: bestanden“? #
Für die Bewertung der Core Web Vitals betrachtet Google die Werte für LCP, INP und CLS.
Die Bewertung basiert auf dem 75. Perzentil der realen Nutzungsdaten.
Die Schwellenwerte für eine gute Bewertung sind:
| Messwert | Gut |
|---|---|
| LCP | ≤ 2,5 s |
| INP | ≤ 200 ms |
| CLS | ≤ 0,1 |
Für eine bestandene Core-Web-Vitals-Bewertung müssen bei ausreichender Datenbasis die relevanten Messwerte im 75. Perzentil im guten Bereich liegen.
Was bedeutet das 75. Perzentil? #
Das 75. Perzentil verhindert, dass eine Website nur anhand besonders schneller Einzelaufrufe beurteilt wird.
Vereinfacht bedeutet es:
Mindestens 75 Prozent der gemessenen Erfahrungen erreichen einen Wert, der diesem Wert entspricht oder besser ist.
Wenn beispielsweise der LCP am 75. Perzentil bei:
2,3 Sekunden
liegt, hatten mindestens 75 Prozent der berücksichtigten Erfahrungen einen LCP von höchstens ungefähr diesem Wert.
Was sind die Labordaten? #
Unterhalb der realen Nutzungsdaten führt PageSpeed Insights eine Lighthouse-Analyse durch.
Dabei wird die Seite unter definierten beziehungsweise simulierten Bedingungen geladen und technisch untersucht.
Diese Labordaten eignen sich besonders für die Diagnose.
Du kannst beispielsweise eine Änderung an deiner Website durchführen und anschließend erneut testen, um zu prüfen, wie sich die Änderung auf die Lighthouse-Messung auswirkt.
Was bedeutet der Performance-Score? #
Lighthouse fasst verschiedene gewichtete Performance-Messwerte zu einem Score zwischen 0 und 100 zusammen.
Die Bereiche werden grundsätzlich folgendermaßen eingeordnet:
| Score | Bewertung |
|---|---|
90–100 | Gut |
50–89 | Verbesserungspotenzial |
0–49 | Schlecht |
Der Score ist hilfreich für eine schnelle Orientierung. Er ist aber kein Prozentsatz der Geschwindigkeit deiner Website.
Ein Wert von:
Performance 82
bedeutet also nicht:
Die Website ist zu 82 % schnell.
Warum schwankt der Performance-Score? #
Wenn du denselben Test mehrmals durchführst, können unterschiedliche Scores entstehen.
Das ist grundsätzlich normal.
Messungen können beispielsweise durch Netzwerkbedingungen, verfügbare Ressourcen des Testsystems, externe Dienste und unterschiedliche Antwortzeiten beeinflusst werden.
Deshalb solltest du aus einer einzelnen Messung keine weitreichenden Schlussfolgerungen ziehen.
Mehrmals testen #
Führe eine Analyse mehrmals durch und achte darauf, ob sich ein wiederkehrendes Muster ergibt.
Beispiel:
Test 1 → 83
Test 2 → 86
Test 3 → 84
→ relativ konsistentes Ergebnis
Bei folgendem Ergebnis solltest du dagegen genauer hinsehen:
Test 1 → 85
Test 2 → 51
Test 3 → 87
Hier wäre interessant, weshalb eine Messung so stark von den anderen abweicht.
Felddaten und Labordaten können sich widersprechen #
Es kann vorkommen, dass die realen Nutzungsdaten gut aussehen, während der aktuelle Lighthouse-Test Probleme zeigt – oder umgekehrt.
Das ist nicht zwangsläufig ein Fehler.
Die Daten betrachten unterschiedliche Zeiträume und Bedingungen:
Felddaten
→ reale Nutzer
→ unterschiedliche Geräte
→ unterschiedliche Netzwerke
→ vergangene 28 Tage
Labordaten
→ einzelner synthetischer Test
→ definierte Bedingungen
→ aktueller Zeitpunkt
Deshalb solltest du nicht versuchen, beide Bereiche zwangsläufig auf identische Werte zu bringen.
Welchen Daten soll ich mehr vertrauen? #
Beide Datenarten sind wertvoll, aber für unterschiedliche Aufgaben.
Wenn du wissen möchtest, wie reale Nutzer deine Website tatsächlich erleben, sind Felddaten besonders relevant.
Wenn du einen konkreten technischen Engpass untersuchen oder eine Änderung unmittelbar testen möchtest, sind Labordaten sehr hilfreich.
Die sinnvollste Analyse verwendet beide Perspektiven.
Die Performance-Kennzahlen im Lighthouse-Bereich #
PageSpeed Insights zeigt im Labortest mehrere Performance-Kennzahlen an.
Je nach aktueller Lighthouse-Version kann sich die genaue Darstellung beziehungsweise Gewichtung verändern.
Zu den typischen Kennzahlen gehören unter anderem:
First Contentful Paint
Largest Contentful Paint
Total Blocking Time
Cumulative Layout Shift
Speed Index
Diese Werte beschreiben unterschiedliche Aspekte des Ladevorgangs und der Darstellung.
First Contentful Paint – FCP #
FCP beschreibt, wann der Browser erstmals Inhalt aus dem Dokument darstellt.
Ein guter FCP kann dem Besucher früh signalisieren, dass die Seite tatsächlich lädt.
FCP sagt jedoch noch nicht, wann der wichtigste Hauptinhalt sichtbar ist.
Largest Contentful Paint – LCP #
LCP betrachtet das Rendern des größten relevanten Inhaltselements im sichtbaren Bereich.
Wenn beispielsweise ein großes Hero-Bild das LCP-Element ist, können dessen Dateigröße, Ladepriorität und technische Einbindung einen erheblichen Einfluss haben.
Wie du Bilder richtig vorbereitest, erklären wir unter Bilder für das Web optimieren: Dateigröße, Format und SEO.
Total Blocking Time – TBT #
Total Blocking Time ist eine Laborkennzahl, die vereinfacht betrachtet, wie stark der Hauptthread während eines bestimmten Abschnitts des Seitenaufbaus durch längere Aufgaben blockiert wird.
JavaScript kann dabei eine wichtige Rolle spielen.
Ein hoher TBT kann darauf hinweisen, dass der Browser längere Zeit mit Aufgaben beschäftigt ist und dadurch nicht unmittelbar auf andere Arbeiten reagieren kann.
TBT und INP sind nicht dasselbe #
TBT ist eine Laborkennzahl. INP basiert auf tatsächlichen Interaktionen und gehört zu den Core Web Vitals.
Die beiden Werte stehen thematisch im Zusammenhang mit Reaktionsfähigkeit, dürfen aber nicht gleichgesetzt werden.
Wichtig: Ein guter TBT-Wert im Lighthouse-Test ersetzt keine realen INP-Daten.
Cumulative Layout Shift – CLS #
CLS bewertet unerwartete Layoutverschiebungen.
Ein typisches Beispiel ist ein Text oder Button, der während des Ladens plötzlich seine Position verändert, weil oberhalb nachträglich ein Element Platz beansprucht.
Mögliche Auslöser können beispielsweise Bilder ohne geeignete Größeninformationen oder dynamisch eingefügte Inhalte sein.
Speed Index #
Der Speed Index beschreibt vereinfacht, wie schnell die sichtbaren Inhalte einer Seite während des Ladevorgangs dargestellt werden.
Er ist eine Laborkennzahl und sollte gemeinsam mit den anderen Messwerten betrachtet werden.
Was bedeuten die farbigen Werte? #
PageSpeed Insights verwendet Farben, um die Einordnung von Messwerten zu erleichtern.
Grün
→ guter Bereich
Orange / Gelb
→ Verbesserung erforderlich
Rot
→ schlechter Bereich
Diese Farben sind hilfreich zur Orientierung, sollten aber nicht dazu führen, dass du jede gelbe oder rote Meldung ohne Priorisierung bearbeitest.
Der wichtigste Bereich: Diagnosen und Optimierungshinweise #
Unterhalb der Kennzahlen zeigt Lighthouse verschiedene technische Hinweise.
Dort liegt für die praktische Optimierung häufig der größte Nutzen des Werkzeugs.
PageSpeed Insights kann beispielsweise auf folgende Probleme hinweisen:
unnötig große Bilder
ineffizient ausgelieferte Bilder
render-blockierende Ressourcen
ungenutztes JavaScript
ungenutztes CSS
lange Aufgaben im Hauptthread
große Netzwerk-Nutzlasten
Probleme beim LCP-Element
Caching-Probleme
Layoutverschiebungen
Welche Hinweise tatsächlich erscheinen, hängt von der analysierten Seite und der verwendeten Lighthouse-Version ab.
Nicht jede Empfehlung hat dieselbe Priorität #
Eine lange Liste von Hinweisen kann zunächst dramatisch aussehen.
Du solltest sie aber nicht einfach von oben nach unten abarbeiten.
Prüfe zuerst:
Welcher Messwert ist tatsächlich schlecht?
↓
Welche Ressource beeinflusst ihn?
↓
Wie groß ist das mögliche Verbesserungspotenzial?
↓
Kann die Maßnahme ohne Funktionsverlust umgesetzt werden?
↓
Ist der Aufwand im Verhältnis zum Nutzen sinnvoll?
Geschätzte Einsparungen richtig verstehen #
Bei bestimmten Prüfungen zeigt Lighthouse eine geschätzte mögliche Einsparung an.
Eine solche Schätzung ist kein Versprechen, dass deine reale Website anschließend exakt um diesen Wert schneller wird.
Sie hilft vielmehr dabei, das mögliche Optimierungspotenzial einer Maßnahme einzuordnen.
Beispiel: Bilder sind zu groß #
Angenommen, PageSpeed Insights meldet, dass ein großes Bild effizienter ausgeliefert werden könnte.
Dann solltest du zunächst die betreffende Datei identifizieren.
Prüfe anschließend:
Welche Pixelabmessungen besitzt das Bild?
Wie groß wird es tatsächlich dargestellt?
Welche Dateigröße besitzt es?
Welches Format wird verwendet?
Ist die Qualitätsstufe angemessen?
Danach kannst du gezielt eine optimierte Variante erstellen.
Die Unterschiede zwischen den wichtigsten Formaten erklären wir unter WebP, AVIF, JPG und PNG: Welches Bildformat verwenden?.
Beispiel: Render-blockierende Ressourcen #
Bestimmte CSS- oder JavaScript-Ressourcen können die Darstellung einer Seite beeinflussen, bevor wichtige sichtbare Inhalte gerendert werden können.
PageSpeed Insights kann solche Ressourcen identifizieren.
Das bedeutet jedoch nicht, dass du jede angezeigte CSS- oder JavaScript-Datei einfach entfernen oder verzögert laden solltest.
Sie kann für das Layout oder eine wichtige Funktion erforderlich sein.
Achtung: Performance-Optimierungen an CSS und JavaScript können die Funktion oder Darstellung einer Website verändern. Erstelle vor größeren Änderungen ein Backup und teste die Website anschließend sorgfältig.
Beispiel: Ungenutztes JavaScript #
Eine Website kann JavaScript laden, von dem beim untersuchten Seitenaufruf nur ein Teil benötigt wird.
Das kann beispielsweise bei umfangreichen Themes, Plugins oder externen Bibliotheken auftreten.
Die Meldung „ungenutztes JavaScript“ bedeutet aber nicht automatisch, dass die komplette betreffende Datei gelöscht werden kann.
Ein Script kann beispielsweise auf einer anderen Seite oder erst nach einer bestimmten Benutzeraktion benötigt werden.
Beispiel: Ungenutztes CSS #
Ähnliches gilt für CSS.
Ein Stylesheet kann Regeln enthalten, die auf der gerade getesteten Seite nicht verwendet werden, auf anderen Bereichen der Website aber notwendig sind.
Automatisches Entfernen ohne Prüfung kann deshalb zu Darstellungsfehlern führen.
Beispiel: LCP-Element untersuchen #
Wenn der LCP auffällig ist, solltest du herausfinden, welches Element als LCP-Element erkannt wurde.
Das kann beispielsweise sein:
Hero-Bild
große Überschrift
Banner
großer Inhaltsblock
Ist ein Bild betroffen, kannst du unter anderem dessen Abmessungen, Dateigröße, Format und Ladeverhalten untersuchen.
Ist Text betroffen, können andere Ressourcen wie Webfonts oder render-blockierende Styles eine Rolle spielen.
Beispiel: Layoutverschiebungen #
Bei einem auffälligen CLS solltest du nicht einfach nach einer allgemeinen „CLS-Optimierung“ suchen.
Ermittle zuerst, welche Elemente sich tatsächlich unerwartet verschieben.
Mögliche Kandidaten sind beispielsweise:
Bilder ohne reservierten Platz
Werbeelemente
Cookie-Banner
nachgeladene Inhalte
Webfonts
dynamische Widgets
Erst danach sollte die konkrete Ursache behoben werden.
Netzwerk-Nutzlasten beurteilen #
Lighthouse kann auf große übertragene Datenmengen hinweisen.
Das ist besonders bei Seiten mit vielen Bildern, Videos, Fonts oder umfangreichen Scripts interessant.
Eine große Gesamtmenge allein sagt allerdings noch nicht, welche Ressource unnötig ist.
Eine Fotogalerie benötigt naturgemäß mehr Daten als eine reine Textseite.
Untersuche deshalb die einzelnen Ressourcen.
Drittanbieter-Code erkennen #
Externe Dienste können einen erheblichen Anteil an JavaScript und Netzwerkanfragen verursachen.
Dazu können beispielsweise gehören:
Analytics
Tag-Manager
Werbenetzwerke
Social-Media-Widgets
Chat-Systeme
externe Videos
Maps
Marketing-Tools
Wenn ein Drittanbieter einen großen Performance-Einfluss besitzt, musst du abwägen, welchen geschäftlichen Nutzen der Dienst bringt und ob er anders eingebunden werden kann.
Nicht jedes externe Script einfach entfernen #
Ein Analyse- oder Marketing-System kann für eine Website geschäftlich wichtig sein.
Performance-Optimierung bedeutet deshalb nicht automatisch, sämtliche externen Dienste zu löschen.
Die bessere Frage lautet:
Brauchen wir diesen Dienst, und wenn ja, können wir ihn effizienter einsetzen?
Warum 100 Punkte nicht das eigentliche Ziel sind #
Ein Score von 100 sieht hervorragend aus, ist aber kein Qualitätszertifikat für die gesamte Website.
PageSpeed Insights bewertet bestimmte technische Aspekte. Das Werkzeug beurteilt beispielsweise nicht, ob dein Angebot verständlich ist, deine Texte hilfreich sind oder Besucher ihr Ziel erreichen.
Auch bei der Performance kann ein sehr guter Lab-Score nicht garantieren, dass jeder reale Besucher dieselbe Erfahrung hat.
Praxis-Tipp: Wenn deine Core Web Vitals gut sind, die Website für reale Besucher schnell und stabil funktioniert und keine bedeutenden Performance-Probleme bestehen, ist die Jagd von 97 auf 100 Punkte häufig weniger wichtig als die Verbesserung echter Inhalte oder Funktionen.
Ein grüner Score bedeutet nicht „nichts mehr tun“ #
Auch das Gegenteil gilt.
Eine Website mit einem Score über 90 kann einzelne Probleme besitzen, die für reale Besucher relevant sind.
Beispielsweise kann eine bestimmte Produktseite, ein Formular oder eine Interaktion problematisch sein, obwohl die getestete Startseite einen guten Score erreicht.
PageSpeed Insights ist ein Seitentest #
Wenn du eine URL analysierst, untersucht Lighthouse diese konkrete Seite.
Das Ergebnis darf nicht automatisch auf die gesamte Website übertragen werden.
Wenn die Startseite:
Performance 95
erreicht, bedeutet das nicht, dass jede andere URL ebenfalls 95 Punkte erreicht.
Vorher-Nachher-Vergleiche durchführen #
PageSpeed Insights eignet sich gut, um eine konkrete Optimierung zu kontrollieren.
Ein sinnvoller Ablauf:
URL testen
↓
mehrere Messungen durchführen
↓
Werte dokumentieren
↓
eine konkrete Optimierung durchführen
↓
Cache berücksichtigen
↓
dieselbe URL erneut testen
↓
mehrere Messungen durchführen
↓
Ergebnisse vergleichen
Wie du Performance-Messungen grundsätzlich sauber vergleichst, erklären wir unter Website-Ladezeit messen und richtig beurteilen.
Immer nur eine nachvollziehbare Änderung bewerten #
Wenn du fünf Performance-Maßnahmen gleichzeitig umsetzt, kannst du anschließend kaum beurteilen, welche davon tatsächlich geholfen hat.
Bei der Fehlersuche ist ein kontrolliertes Vorgehen besser.
Beispiel:
Ausgangsmessung
↓
Hero-Bild optimieren
↓
erneut messen
↓
Ergebnis dokumentieren
↓
nächste Maßnahme
Warum sich ein Ergebnis trotz unveränderter Website ändern kann #
Lighthouse-Messungen besitzen eine gewisse natürliche Variabilität.
Netzwerk, Testumgebung, externe Ressourcen und andere Faktoren können einzelne Durchläufe beeinflussen.
Deshalb solltest du kleine Unterschiede nicht überinterpretieren.
Ein Unterschied zwischen beispielsweise 91 und 93 Punkten beweist allein noch keine relevante Performance-Verbesserung.
PageSpeed nach einem Relaunch richtig verwenden #
Nach einem Website-Relaunch ist PageSpeed Insights besonders hilfreich.
Teste nicht nur die neue Startseite, sondern wichtige Seitentypen.
Prüfe beispielsweise:
Startseite
wichtigste Landingpages
Blogartikel
Kontaktseite
Produktseiten
Shop-Seiten
Bei einer neuen oder stark veränderten Website können die Felddaten zunächst noch die vergangenen 28 Tage widerspiegeln beziehungsweise für neue URLs nicht ausreichend verfügbar sein.
Für unmittelbare technische Prüfungen sind deshalb zunächst die aktuellen Labordaten besonders hilfreich.
Nach einer Optimierung ändern sich Felddaten nicht sofort #
Dieser Punkt ist besonders wichtig.
Wenn du heute eine Performance-Verbesserung durchführst, spiegeln die CrUX-Felddaten diese Änderung nicht sofort vollständig wider.
Sie betrachten einen rollierenden Zeitraum von 28 Tagen.
Die Labordaten können eine technische Änderung dagegen unmittelbar bei einer neuen Messung erfassen.
Änderung heute
↓
Lighthouse-Labtest
→ Effekt sofort messbar
CrUX-Felddaten
→ verändern sich schrittweise
mit neuen realen Nutzungsdaten
PageSpeed Insights und SEO #
PageSpeed Insights wird häufig als „SEO-Test“ betrachtet. Das ist zu stark vereinfacht.
Das Werkzeug kann technische Hinweise liefern und enthält Lighthouse-Prüfungen aus verschiedenen Kategorien. Ein Performance-Score ist aber kein direkter Google-Ranking-Score.
Ein Wechsel von:
Performance 82 → 95
bedeutet deshalb nicht automatisch eine entsprechend große Rankingverbesserung.
Die Core Web Vitals sind Teil der von Google betrachteten Page-Experience-Signale, aber Suchmaschinenranking hängt von wesentlich mehr Faktoren ab.
PageSpeed nicht mit Google Search Console verwechseln #
PageSpeed Insights analysiert eine angegebene URL hinsichtlich technischer Performance-Aspekte.
Google Search Console zeigt dagegen unter anderem Informationen darüber, wie Google deine Website in der Suche verarbeitet und wie sie in den Suchergebnissen performt.
Beide Werkzeuge ergänzen sich, erfüllen aber unterschiedliche Aufgaben.
Die Einrichtung der Search Console behandeln wir unter Google Search Console einrichten und Website bestätigen.
Was tun bei einem schlechten PageSpeed-Ergebnis? #
Ein schlechter Score ist zunächst ein Ausgangspunkt für die Diagnose.
Gehe nicht sofort davon aus, dass eine komplette Website neu gebaut oder das Hosting gewechselt werden muss.
Untersuche zuerst die größten Auffälligkeiten.
Schlechter Score
↓
Welche Kennzahl ist auffällig?
↓
Welche Diagnose erklärt das Problem?
↓
Welche Ressource ist betroffen?
↓
Ursache überprüfen
↓
gezielte Maßnahme
↓
erneut messen
Die systematische Ursachenanalyse behandeln wir unter Langsame Website: Ursachen systematisch finden.
Typische Priorisierung von Problemen #
Es gibt keine universelle Reihenfolge für jede Website. Als Grundprinzip kannst du jedoch zuerst Probleme betrachten, die einen großen Einfluss auf wichtige Kennzahlen besitzen und sich ohne Funktionsverlust sinnvoll beheben lassen.
Beispielsweise:
großes LCP-Problem
↓
LCP-Element identifizieren
sehr große Bilder
↓
Bildoptimierung prüfen
hohe JavaScript-Belastung
↓
verursachende Scripts untersuchen
starke Layoutverschiebungen
↓
auslösende Elemente identifizieren
Änderungen an produktiven Websites vorsichtig durchführen #
Performance-Einstellungen können tief in die technische Auslieferung einer Website eingreifen.
Das betrifft beispielsweise:
JavaScript-Verzögerung
CSS-Optimierung
Minifizierung
Caching
Preloading
Lazy Loading
Entfernen von Ressourcen
Eine falsche Konfiguration kann Menüs, Formulare, Shops, Cookie-Banner oder andere Funktionen beeinträchtigen.
Achtung: Erstelle vor größeren technischen Performance-Änderungen ein Backup und prüfe danach nicht nur den PageSpeed-Score, sondern die tatsächliche Website auf Desktop und Smartphone.
Nach jeder Optimierung die Website selbst benutzen #
Ein besserer Score ist wertlos, wenn anschließend eine wichtige Funktion nicht mehr funktioniert.
Teste nach Änderungen beispielsweise:
Navigation
Formulare
Buttons
Slider
Cookie-Banner
Suche
Login
Warenkorb
Checkout
mobile Darstellung
Welche Funktionen relevant sind, hängt selbstverständlich von deiner Website ab.
Wann ist eine PageSpeed-Meldung weniger wichtig? #
Manche Hinweise betreffen nur eine sehr kleine mögliche Einsparung.
Wenn die Umsetzung gleichzeitig komplex oder riskant wäre, kann eine andere Maßnahme eine deutlich höhere Priorität besitzen.
Performance-Optimierung ist deshalb auch eine Frage der Verhältnismäßigkeit:
möglicher Nutzen
↕
Umsetzungsaufwand
↕
technisches Risiko
↕
Bedeutung für reale Besucher
PageSpeed Insights regelmäßig verwenden #
Eine Website verändert sich im Laufe der Zeit.
Neue Bilder, Plugins, Tracking-Dienste, Fonts, Videos oder andere Funktionen können die Performance beeinflussen.
Eine erneute Analyse ist deshalb besonders nach größeren Änderungen sinnvoll.
Du musst PageSpeed Insights aber nicht täglich aufrufen, wenn an der Website nichts verändert wurde und keine Probleme erkennbar sind.
PageSpeed Insights ersetzt kein Monitoring #
PageSpeed Insights ist kein System zur permanenten Überwachung der Erreichbarkeit einer Website.
Ein erfolgreicher Test zeigt dir nicht, dass die Website während der kommenden Tage rund um die Uhr verfügbar bleibt.
Für eine kontinuierliche Überwachung werden Monitoring-Systeme eingesetzt.
Das behandeln wir unter Website-Monitoring: Erreichbarkeit und Ausfälle überwachen.
PageSpeed Insights ersetzt keine vollständige Fehleranalyse #
PSI kann dir sehr wertvolle Hinweise geben, kennt aber nicht automatisch die gesamte technische Ursache eines Problems.
Wenn beispielsweise ein PHP-Prozess, eine Datenbankabfrage oder eine externe Schnittstelle zeitweise langsam ist, kann für die genaue Diagnose eine weitergehende Untersuchung notwendig sein.
PageSpeed Insights ist deshalb ein wichtiger Teil der Performance-Diagnose – aber nicht das einzige mögliche Werkzeug.
Praktischer PageSpeed-Workflow #
richtige URL auswählen
↓
mobile Analyse durchführen
↓
Desktop-Analyse durchführen
↓
Felddaten prüfen
↓
Core Web Vitals beurteilen
↓
Labordaten prüfen
↓
auffällige Kennzahl bestimmen
↓
Diagnosen ansehen
↓
betroffene Ressource identifizieren
↓
Maßnahme nach Nutzen priorisieren
↓
eine Änderung durchführen
↓
Website funktional testen
↓
erneut PageSpeed messen
↓
Ergebnis dokumentieren
Häufige Fehler bei PageSpeed Insights #
nur auf den Performance-Score schauen
unbedingt 100 Punkte erreichen wollen
nur Desktop testen
nur die Startseite testen
Felddaten und Labordaten verwechseln
fehlende Felddaten als Fehler interpretieren
jede Empfehlung ungeprüft umsetzen
CSS oder JavaScript blind entfernen
mehrere Änderungen gleichzeitig durchführen
kleine Score-Schwankungen überbewerten
nach einer Änderung sofort neue CrUX-Werte erwarten
PageSpeed mit einem Google-Ranking-Score verwechseln
nach der Optimierung die Website-Funktionen nicht testen
Checkliste: PageSpeed-Ergebnis richtig beurteilen #
Ist die richtige URL getestet?
↓
Mobil und Desktop geprüft?
↓
Felddaten vorhanden?
↓
URL- oder Origin-Daten?
↓
Core Web Vitals bestanden?
↓
Welcher Messwert ist auffällig?
↓
Was zeigen die Labordaten?
↓
Welche Diagnose ist dafür relevant?
↓
Welche konkrete Ressource verursacht das Problem?
↓
Ist die vorgeschlagene Maßnahme sinnvoll?
↓
Kann sie Funktionen beeinträchtigen?
↓
Änderung einzeln durchführen
↓
Website praktisch testen
↓
erneut messen
Zusammenfassung #
Google PageSpeed Insights ist ein leistungsfähiges Werkzeug zur Analyse der Website-Performance. Der größte Nutzen entsteht jedoch nicht durch den Performance-Score allein, sondern durch die Kombination aus realen Felddaten, Lighthouse-Labordaten und den dazugehörigen technischen Diagnosen.
Felddaten zeigen die Erfahrungen realer Nutzer über einen längeren Zeitraum. Labordaten ermöglichen dagegen einen kontrollierten aktuellen Test und eignen sich besonders zur technischen Fehlersuche.
Die Core Web Vitals LCP, INP und CLS solltest du getrennt betrachten und anschließend untersuchen, welche konkreten Ressourcen oder technischen Ursachen einen auffälligen Wert beeinflussen.
Nicht jede PageSpeed-Empfehlung besitzt dieselbe Priorität. Beurteile deshalb immer den möglichen Nutzen, den Aufwand und das Risiko einer Änderung.
Nach einer Optimierung solltest du nicht nur erneut messen, sondern auch kontrollieren, ob die Website auf Desktop und Smartphone weiterhin korrekt funktioniert.
PageSpeed Insights sagt dir nicht einfach, ob eine Website „gut“ oder „schlecht“ ist. Richtig eingesetzt zeigt es dir, wo du genauer hinschauen solltest – und genau darin liegt der eigentliche Wert des Werkzeugs.