PageSpeed Insights richtig lesen: warum 69 Punkte wenig sagen und welcher Wert wirklich zählt

„Google gibt unserer Website 69 Punkte. Ist das jetzt gut oder schlecht?" So oder so ähnlich klingt eine Frage, die wir regelmäßig bekommen, meist mit einem Bildschirmfoto von PageSpeed Insights im Anhang, auf dem ein orangefarbener Kreis prangt. Die ehrliche Antwort lautet: Die Zahl im Kreis sagt darüber erstaunlich wenig. Der Teil des Berichts, der etwas sagt, steht auf derselben Seite, nur weiter oben.

Wir haben am 29. September 2026 zwei Websites mobil durch PageSpeed Insights geschickt: unsere eigene Startseite und zum Vergleich handwerk.de. Beide bekamen exakt 69 Punkte. Ja, auch wir: Eine Webagentur, die anderen schnelle Websites baut, landet mit der eigenen Startseite im orangefarbenen Bereich. Das ist ungefähr so, als würde die Fahrlehrerin beim Einparken den Bordstein mitnehmen. Verstecken hilft da nichts, also nehmen wir unsere eigene Seite in diesem Beitrag vor allen auseinander.

Bei handwerk.de erleben echte Besucher trotz der 69 eine schnelle Seite, bei uns kann das niemand sagen, und in unserem Bericht steht eine Baustelle, an der ihr sehr gut sehen könnt, wie man ihn liest.

Dieser Beitrag setzt voraus, dass ihr eure Adresse dort schon einmal eingegeben habt, und geht den Bericht in der Reihenfolge durch, in der ihr ihn braucht: messen, oben lesen, unten nachsehen, handeln. Alle Aussagen zum Werkzeug stammen aus Googles eigener Dokumentation zu PageSpeed Insights, Lighthouse und den Core Web Vitals, abgerufen am 29. September 2026. Wo die deutsche Hilfe fehlerhaft übersetzt ist, haben wir die englische Fassung genommen und sagen es dazu.

Kurz gesagt (Stand September 2026)

Lest in PageSpeed Insights zuerst den oberen Bereich „So sieht die Leistung auf der Nutzerseite aus", nicht die Punktzahl. Nur dort stehen echte Besucher der letzten 28 Tage, und nur daraus ergibt sich, ob eure Core Web Vitals bestanden sind. Die Punktzahl stammt aus einem einzigen simulierten Testlauf auf einem gebremsten Handy: Bei handwerk.de zeigte das Labor 69 Punkte und 7,4 Sekunden, echte Besucher sahen das größte Element nach 1,4 Sekunden. Steht oben „Keine Daten", arbeitet mit dem Laborwert für den Largest Contentful Paint, nicht mit der Punktzahl.

Richtig messen: Mobil zuerst, fünf Läufe, der mittlere Wert zählt

Messt auf pagespeed.web.dev immer zuerst die Ansicht „Mobil" und verlasst euch nie auf einen einzigen Lauf. Die Oberfläche zeigt die Handy-Auswertung von selbst zuerst, der Reiter „Computer" liegt daneben. Der Handy-Test ist der strengere, weil er ein gebremstes Gerät nachstellt. Vorsicht bei Werkzeugen, die über die Schnittstelle von PageSpeed Insights messen: Dort ist laut Dokumentation Desktop voreingestellt, wenn niemand etwas anderes angibt.

Unsere eigene Startseite am 29. September 2026: oben der Umschalter Mobil / Computer (1), darunter der Bereich für echte Besucher mit „Keine Daten" (2), die Kategorien mit 69 Punkten für Leistung, 97, 100, 100 und Agentisches Browsing 1/2 (3) und die Labormesswerte mit 8,4 Sekunden für den Largest Contentful Paint (4).

Im Labor stellt PageSpeed Insights mobil ein Mittelklasse-Handy nach. Im Bericht steht dazu Emulation eines Moto G Power with Lighthouse 13.5.0 und Langsame 4G-Drosselung. Laut Lighthouse-Dokumentation bedeutet diese Drosselung 150 Millisekunden Latenz, 1,6 Megabit pro Sekunde im Download und 750 Kilobit im Upload, dazu wird der Prozessor vierfach gebremst. Ältere Anleitungen nennen dafür noch den alten Namen Fast 3G.

Google selbst rät, Schlüsse nie aus einem einzelnen Lauf zu ziehen. Die Lighthouse-Dokumentation empfiehlt Zusammenfassungen wie den Median und nennt den Median aus fünf Läufen doppelt so stabil wie einen Einzellauf. Wir machen es deshalb so: fünfmal messen, jedes Mal Punktzahl und Largest Contentful Paint notieren, die fünf Werte sortieren und den mittleren nehmen.

Schreibt zu jeder Messung das Datum dazu, das oben unter „Datum des Berichts" steht, und sichert den Bericht über „Link kopieren". Messt nicht nur die Startseite, sondern auch die Seite, über die bei euch die meisten Anfragen kommen, meist eine Leistungsseite. Legt euch heute eine kleine Tabelle mit diesen beiden Adressen an.

So messen wir im Studio: Handy zuerst, fünf Läufe, der mittlere Wert, dann erst lesen und vergleichen.

Oben echte Besucher, unten ein Testlauf: welcher Bereich zählt

Entscheidet nach dem oberen Bereich, sobald dort Werte stehen, und benutzt den unteren zur Fehlersuche. Oben, unter „So sieht die Leistung auf der Nutzerseite aus", zeigt PageSpeed Insights Daten aus dem Chrome-UX-Bericht, also von echten Chrome-Nutzern aus den letzten 28 Tagen. Unten, unter „Leistungsprobleme diagnostizieren", läuft Lighthouse ein einziges Mal in einer simulierten Umgebung über die Seite. Widersprechen sich beide, soll man sich laut Google an den Felddaten ausrichten.

Wie groß dieser Widerspruch sein kann, zeigt handwerk.de. Oben stand am 29. September 2026 Core Web Vitals-Bewertung: bestanden, mit 1,4 Sekunden für den Largest Contentful Paint, 112 Millisekunden für Interaction to Next Paint und einem Cumulative Layout Shift von 0. Im selben Bericht weiter unten: Leistung 69, Largest Contentful Paint 7,4 Sekunden. Dieselbe Seite am selben Tag, einmal mit echten Menschen gemessen und einmal mit einem nachgestellten Handy.

handwerk.de, oberer Bereich: der Umschalter Diese URL / Ursprung (1), die bestandene Bewertung (2), die drei Core Web Vitals mit LCP 1,4 s, INP 112 ms und CLS 0 (3) und die Angaben zum Zeitraum von 28 Tagen aus dem Chrome-UX-Bericht (4).

Derselbe Bericht weiter unten: Leistung 69 (1) und ein Largest Contentful Paint von 7,4 Sekunden (2). Die Vorschau zeigt einen Cookie-Banner über der Seite (3), die Testbedingungen (4) erklären, warum das Labor so viel langsamer ist als die echten Besucher.

Die Punktzahl ist also nicht das Erlebnis eurer Besucher. Google schreibt selbst, dass gute Laborwerte nicht automatisch gute Erfahrungen echter Nutzer bedeuten, und handwerk.de zeigt, dass es auch umgekehrt gilt.

Zwei Feinheiten im oberen Bereich lohnen den Blick. Der Umschalter „Diese URL" und „Ursprung" wechselt zwischen der einzelnen Seite und der ganzen Website, und fehlen für die Seite genug Daten, weicht PageSpeed Insights laut Google von selbst auf die ganze Website aus. Der Wert über den farbigen Balken ist das 75. Perzentil, drei Viertel der Besuche waren also mindestens so schnell. Schaut bei eurer Seite zuerst auf „Diese URL" und wechselt zu „Ursprung", wenn dort nichts steht.

Die beiden Bereiche eines Berichts nebeneinander: oben echte Besucher, unten ein einzelner Testlauf, mit dem Beispiel handwerk.de vom 29. September 2026.

Drei Grenzwerte, die ihr kennen müsst: LCP, INP und CLS

Merkt euch drei Zahlen: 2,5 Sekunden, 200 Millisekunden und 0,1. Das sind die Grenzen für „gut" bei den drei Core Web Vitals, und die Bewertung gilt als bestanden, wenn alle drei beim 75. Perzentil darunter liegen. Der Largest Contentful Paint misst, wann das größte sichtbare Element steht, meist ein Titelbild oder eine große Überschrift. Interaction to Next Paint misst, wie schnell die Seite auf Tippen und Klicken reagiert, Cumulative Layout Shift, wie stark Inhalte beim Laden verrutschen.

Darüber wird es erst verbesserungswürdig, dann schlecht: beim Largest Contentful Paint über 4 Sekunden, bei Interaction to Next Paint über 500 Millisekunden, beim Cumulative Layout Shift über 0,25. Die Grenzen haben wir aus der englischen Dokumentation übernommen. In der deutschen Fassung stehen in zwei Zeilen falsche Klammern, und dieselbe Stufe heißt dort einmal „Verbesserung erforderlich" und einmal „Optimierung erforderlich".

Die Grenzwerte aus der englischen Dokumentation von PageSpeed Insights. Über „bestanden" entscheiden nur die ersten drei Zeilen.

First Contentful Paint und Time to First Byte stehen im oberen Bereich unter „ANDERE WICHTIGE MESSWERTE" und zählen für die Bewertung nicht mit. Fehlen genug Daten für Interaction to Next Paint, reichen laut Google gute Werte bei LCP und CLS zum Bestehen. Prüft bei eurer Seite als Erstes, welcher der drei Werte über seiner Grenze liegt, denn an genau dem hängt das Ergebnis.

Woher die 69 kommen: die Punktzahl in fünf Teilen nachrechnen

Klickt unter dem Kreis auf „Siehe Rechner." und schaut, welcher Messwert euch die meisten Punkte kostet. Die Leistungspunktzahl setzt sich aus fünf Laborwerten zusammen: Total Blocking Time zählt 30 Prozent, Largest Contentful Paint und Cumulative Layout Shift je 25, First Contentful Paint und Speed Index je 10. Google nennt diese Gewichte für Lighthouse 10, und in unserer Messung mit Lighthouse 13.5.0 waren sie unverändert. Unter dem Kreis steht dazu: „Die Werte sind geschätzt und können variieren. Die Leistungsbewertung wird direkt aus diesen Messwerten berechnet."

Bei unserer Startseite verteilen sich die 69 Punkte so: Total Blocking Time mit 20 Millisekunden bringt volle 30 Punkte, Cumulative Layout Shift mit 0 volle 25. Speed Index mit 3,9 Sekunden bringt 8 von 10, First Contentful Paint mit 2,9 Sekunden 5 von 10. Der Largest Contentful Paint mit 8,4 Sekunden bringt 1 von 25 Punkten, von den 31 fehlenden Punkten gehen also 24 auf sein Konto.

Unsere 69 Punkte vom 29. September 2026, aufgeteilt auf die fünf Messwerte. Ein einziger Wert, der Largest Contentful Paint, kostet fast die gesamte Differenz zur 100.

Wie aus Sekunden Punkte werden, hat Google an echten Websites festgemacht. Grundlage sind Messdaten aus dem HTTP Archive: Wer bei einem Messwert so schnell ist wie das 25. Perzentil dieser Websites, bekommt dafür 50 Punkte, wer so schnell ist wie das 8. Perzentil, bekommt 90. Mobil und Desktop haben eigene Kurven, eine 69 auf dem Handy ist also etwas anderes als eine 69 am Computer.

Wichtig für eure Prioritäten: Nur diese fünf Messwerte zählen, nicht die Hinweise weiter unten, die wirken laut Google nur indirekt über die Messwerte. Und 100 Punkte erwartet Google ausdrücklich nicht, der Schritt von 99 auf 100 kostet laut Dokumentation etwa so viel Verbesserung wie der von 90 auf 94. Grün beginnt bei 90. Sucht euch den Messwert mit dem größten Punkteverlust und arbeitet zuerst nur an dem.

Warum die Punktzahl schwankt, obwohl ihr nichts geändert habt

Vergleicht nur Mediane aus mehreren Läufen, nie zwei einzelne Messungen. Google schreibt, dass sich Lighthouse-Punktzahlen durch die Unbeständigkeit von Web und Netz ändern, auch ohne jede Änderung am Code. Als Gründe nennt die Dokumentation unter anderem wechselnde Werbung und A/B-Tests, geänderte Wege im Internet und schwankende Serverlast. Kleine Websites auf geteiltem Hosting sind laut Lighthouse-Dokumentation für Serverschwankungen typischerweise anfälliger.

Wir haben das am 29. September 2026 selbst erlebt. Eine zweite Messung unserer Startseite am selben Tag fiel deutlich anders aus als die 69 aus der Oberfläche, an der Seite hatte sich nichts geändert. Hätten wir nur die zweite Zahl gesehen, hätten wir hier eine andere Geschichte erzählt. Deshalb steht in unseren Protokollen nie ein einzelner Wert.

Auch der Ort des Tests ist nicht fest: PageSpeed Insights meldet laut Google einen Lauf aus Nordamerika, Europa oder Asien. Schwankt euer Median über mehrere Tage stark, schaut euch euer Hosting an, bevor ihr an der Seite selbst schraubt. Und wenn ihr nach einer Änderung vergleichen wollt, messt vorher und nachher je fünfmal, möglichst zu einer ähnlichen Tageszeit.

„Keine Daten": was ihr tut, wenn echte Nutzerdaten fehlen

Steht oben „Keine Daten", ist das bei kleinen Betrieben der Normalfall und kein Fehler. Für Felddaten braucht eine Seite oder Website eine Mindestzahl an Besuchen, und die nennt Google nicht. Gezählt werden nur bestimmte Chrome-Nutzer auf Desktop und Android, Chrome auf dem iPhone ist ausdrücklich ausgenommen.

Unsere eigene Startseite gehört dazu, am 29. September 2026 stand im oberen Bereich nur „Keine Daten". In unserem Kölner Handwerks-Website-Report vom 11. September 2026 hatten von 734 gemessenen Handwerks-Websites nur 89 überhaupt echte Chrome-Felddaten. Für die große Mehrheit kleiner Betriebe bleibt der obere Bereich also leer, die Zahlen dazu stehen im Kölner Handwerks-Website-Report.

Öffnet in diesem Fall den Bericht „Core Web Vitals" in der Google Search Console. Er nutzt dieselbe Datenquelle, fasst aber ähnliche Seiten zu Gruppen zusammen, deshalb weichen seine Werte manchmal von einer einzelnen Adresse in PageSpeed Insights ab. Auch dort kann „Keine Daten verfügbar" stehen, laut Google entweder weil die Property neu ist oder weil der Chrome-UX-Bericht zu wenige Daten hat. Wie ihr euch in der Search Console zurechtfindet, erklären wir im Beitrag Google Search Console richtig nutzen.

Bleibt auch die Search Console leer, arbeitet ihr mit dem Laborteil, aber mit dem richtigen Wert. Wir nehmen dann den Largest Contentful Paint aus dem Labor als Leitgröße und nicht die Punktzahl, weil er zeigt, wie lange ein Besucher auf das Wichtigste wartet. Im Kölner Report lag der Median dieses Werts bei 6,0 Sekunden, nur 12,5 Prozent der Seiten schafften höchstens 2,5 Sekunden. Der Median der Leistungspunktzahl lag bei 69, genau dort, wo auch wir und handwerk.de gelandet sind.

Der Schuster und seine Schuhe: unsere eigene Startseite im Test

Öffnet im Laborteil die Statistik „LCP-Aufschlüsselung", dort steht, welches Element euren Largest Contentful Paint auslöst. Bei unserer Startseite war es ein Foto, im Code angelegt mit 4160 × 6240 Pixeln. Das ist die Auflösung einer Kamera, weit mehr als der nachgestellte Handybildschirm im Test anzeigt. Unser System liefert zwar verkleinerte Fassungen aus, trotzdem schätzt PageSpeed Insights bei Bildübermittlung verbessern eine mögliche Einsparung von 1.073 KiB.

Die Aufschlüsselung zeigt vier Teilzeiten: Time to First Byte 10 Millisekunden, Verzögerung beim Laden der Ressourcen 300 Millisekunden, Dauer des Ressourcenladevorgangs 130 Millisekunden und Verzögerung beim Rendering des Elements 200 Millisekunden. Rechnet diese Teilzeiten nicht gegen die 8,4 Sekunden auf, denn der Wert oben ist laut Bericht für ein gedrosseltes Handy geschätzt. Lest daran ab, wo der größte Block liegt: In diesem Lauf war es die Wartezeit, bevor das Bild überhaupt geladen wird, der Server antwortet schnell. Google schreibt dazu, dass im Idealfall der größte Teil der Zeit auf das Laden selbst entfällt und nicht auf Verzögerungen.

Unsere Hausaufgabe im Bild: die LCP-Aufschlüsselung mit ihren vier Teilzeiten (1), das auslösende Element, ein Foto mit 4160 × 6240 Pixeln (2), und darunter die Diagnose mit 125 KiB ungenutztem JavaScript, fehlender width und height, 2,0 Sekunden JavaScript-Ausführung und 3,4 Sekunden Hauptthread (3).

Wir haben das Foto am 29. September 2026 verkleinert, stolz nachgemessen, und der Laborwert auf dem Handy blieb gleich. Aus 4160 × 6240 Pixeln und 3,5 MB wurden 2000 × 3000 Pixel und 0,87 MB. Vorher zeigte PageSpeed Insights in unseren Messungen 58 Punkte und einen Largest Contentful Paint von 11,9 Sekunden, danach 57 Punkte und 11,7 bis 12,1 Sekunden. Den Grund zeigt die Liste der geladenen Dateien: Das Handy im Test hatte schon vorher nur eine verkleinerte Fassung von rund 120 KB geladen, weil unser Baukasten passende Größen selbst ausliefert. Gewonnen haben Besucher an Computern mit hochauflösendem Bildschirm, die bisher bis zu 3,2 MB für dieses eine Bild geladen haben.

In den späteren Läufen lag die Zeit bei der Verzögerung beim Rendering, nicht beim Bild. Diese Teilzeit betrug nach dem Tausch jedes Mal 1,6 bis 1,9 Sekunden, das Laden des Bildes selbst 0,1 bis 0,5 Sekunden. Noch deutlicher sind die ungebremst aufgezeichneten Zeiten, die im Rohbericht stehen: Das Dokument war nach 0,8 Sekunden eingelesen, gezeichnet wurde der erste Inhalt aber erst nach 2,3 Sekunden, und das Foto erschien im selben Moment. Solange eine Seite gar nichts zeichnet, hilft auch das kleinste Bild nicht.

Als Nächstes stand der Einblend-Effekt des Fotos unter Verdacht, er hatte ein Alibi. Das Bild gleitet beim Laden nach oben und startet dafür unsichtbar. Wir haben eine Kopie der Startseite ohne diesen Effekt je dreimal gegen das Original gemessen, beide zeichneten nach 2,3 Sekunden.

Überführt haben wir am Ende das Übersetzungsskript für die englische Fassung. Es blendete die Seite aus, bis die Übersetzung stand, auch auf der deutschen Startseite, die gar nicht übersetzt wird. Seit dem 30. September 2026 wartet es nur noch auf den englischen Seiten. In fünf Läufen danach zeichnete die Seite dreimal früher, nach 0,3 bis 1,3 Sekunden statt nach 2,3, zweimal blieb es bei 2,3 bis 2,6 Sekunden. Der Laborwert für den Largest Contentful Paint lag im Median bei 11,8 statt 12,0 Sekunden, die Punktzahl bei 60 statt 57.

Die Punktzahl reagiert also kaum, obwohl die Seite in drei von fünf Läufen über eine Sekunde früher zu sehen war. Genau deshalb lohnt der Blick in die Aufschlüsselung und in die aufgezeichneten Zeiten mehr als der Blick auf die Zahl im Kreis. Und ja, wir bleiben an unserer eigenen 60 dran, der nächste Stand kommt in diesen Beitrag.

Für euch heißt das: Schaut in der Aufschlüsselung nicht nur, welches Element genannt wird, sondern welche der vier Teilzeiten am größten ist. Ist es das Laden, lohnt sich ein kleineres Bild. Ist es die Verzögerung beim Rendering, liegt die Bremse in Skripten, Schriften oder Effekten, die vor dem ersten Zeichnen laufen. Schaut heute bei eurer Startseite nach.

„Statistiken" und „Diagnose": welche Zeilen ihr zuerst anfasst

Filtert die Liste über „Prüfungen anzeigen, die für folgende Messwerte relevant sind" auf den Messwert, der euch die meisten Punkte kostet. Bei uns ist das LCP, also klicken wir auf den Filter LCP und sehen nur noch Hinweise, die den Largest Contentful Paint betreffen. Seit dem Umbau von Lighthouse heißen diese Hinweise auf Deutsch „Statistiken", die früheren „Empfehlungen" gibt es als eigene Gruppe nicht mehr.

Unter „Statistiken" standen bei uns am 29. September 2026 unter anderem Effiziente Verweildauer im Cache verwenden mit geschätzten 85 KiB, Anfragen zum Blockieren des Renderings mit geschätzten 620 Millisekunden und Bildübermittlung verbessern mit 1.073 KiB. Dazu kamen Einträge ohne Zahl, etwa LCP-Anfrageerkennung und Netzwerkabhängigkeitsbaum mit einer Warnung wegen mehr als vier preconnect-Links. Die geschätzten Einsparungen geben euch eine brauchbare Reihenfolge für den Anfang.

Der untere Teil unseres Berichts: die Testbedingungen mit Moto G Power, Langsamer 4G-Drosselung und Lighthouse 13.5.0 (1), der Filmstreifen des Ladevorgangs (2), der Filter nach Messwerten (3) und die drei Statistiken mit geschätzter Einsparung: 85 KiB Cache, 620 ms blockierende Anfragen, 1.073 KiB Bilder (4).

Die Gruppe „Diagnose" darunter lest ihr zuletzt. Dort steht wörtlich: „Diese Angaben haben keinen direkten Einfluss auf die Leistungsbewertung." Egal sind sie trotzdem nicht, denn viel JavaScript macht eine Seite auf schwachen Handys träge. Wer aber nur eine Stunde hat, verbringt sie bei den Statistiken, die zum schlechtesten Messwert gehören.

Die Statistiken, die wir bei kleinen Websites am häufigsten sehen, übersetzt in das, was dahintersteckt, und wer es beheben kann.

Die drei Baustellen, die wir bei kleinen Websites fast immer finden

Fangt bei den Bildern an, dann kommen blockierende Dateien, dann Drittanbieter. Diese Reihenfolge ist unsere Erfahrung aus Messungen kleiner Websites, und sie passt zu dem, was Google zu den einzelnen Statistiken schreibt. Bilder sind meist der schnellste Gewinn, weil ihr sie selbst austauschen könnt. Blockierende Dateien und Drittanbieter brauchen öfter eine Entscheidung oder technische Hilfe.

Bilder: Die Statistik Bildübermittlung verbessern meldet laut Google Bilder, deren kürzere Downloadzeit den Largest Contentful Paint verbessern kann. In der Praxis sind das Handyfotos in Originalgröße, große Galerien und Fotos im PNG-Format. Dazu gehört LCP-Anfrageerkennung: Google rät, das Bild für den Largest Contentful Paint direkt im HTML auffindbar zu machen und es nicht verzögert zu laden. Wer das Titelbild mit loading="lazy" ausstattet, bremst genau das Element, nach dem gemessen wird.

Blockierende Dateien: Hinter Anfragen zum Blockieren des Renderings stecken Stylesheets und Skripte, auf die der Browser wartet, bevor er überhaupt etwas zeigt. Google schlägt vor, sie aufzuschieben oder direkt in die Seite einzubetten, damit sie aus dem kritischen Pfad verschwinden. Bei kleinen Websites sind das oft Plugins, Schriftdienste und der Cookie-Banner im Kopf der Seite. Bei uns schätzt PageSpeed Insights hier 620 Millisekunden Einsparung, das ist nach dem Titelbild unser zweiter Punkt.

Drittanbieter: Die Statistik Drittanbieter listet Code, der nicht von eurem eigenen Server kommt. Google empfiehlt, solchen Code zu reduzieren und später zu laden, damit eure eigenen Inhalte Vorrang haben. Typisch sind Tracking, Karten, eingebettete Videos, Chat-Fenster, Bewertungs-Widgets und der Cookie-Banner selbst. Geht die Liste durch und fragt bei jedem Eintrag, ob er euch noch Anfragen bringt.

Cookie-Banner: Das Labor sieht nur den ersten Besuch

Rechnet damit, dass der Labortest eure Seite vor der Cookie-Einwilligung misst, und prüft das Verhalten nach dem Zustimmen gesondert. Google schreibt auf web.dev, dass die meisten Testwerkzeuge wie Lighthouse ohne besondere Einstellung nur Erstbesucher messen, die auf den Cookie-Hinweis noch nicht reagiert haben. Genau das sieht man in beiden Berichten vom 29. September 2026: Die Vorschau zeigt bei uns und bei handwerk.de jeweils einen Cookie-Banner über der Seite. Die passende Testbedingung heißt im Bericht Erster Seitenaufbau.

Für Websites nach deutschem Datenschutzrecht hat das eine Folge. Tracking und Marketing-Skripte laden meist erst nach der Zustimmung, also misst das Labor sie in der Regel gar nicht. Echte Besucher, die zustimmen, bekommen sie trotzdem, und laut Google sind Cookie-Hinweise oft ein Grund für hohe INP-Werte, weil nach der Zustimmung viele Skripte von Drittanbietern nachladen. Eine ordentliche Punktzahl kann also eine Seite verdecken, die nach dem Klick auf Zustimmen träge wird.

Der Banner selbst kostet ebenfalls. Google nennt Cookie-Hinweise eine sehr häufige Quelle für Layout-Verschiebungen und schreibt, dass Banner von Drittanbietern in der Regel stärker bremsen als selbst gebaute. Öffnet eure Seite in einem privaten Fenster, stimmt zu und achtet darauf, ob Scrollen und Tippen danach haken. Wenn ja, gehört die Liste der nachgeladenen Dienste auf den Tisch, nicht die Punktzahl.

Was Google zum Ranking wörtlich sagt

Behandelt die Core Web Vitals als ein Signal unter vielen und die Punktzahl nicht als Rankingfaktor. Google schreibt auf der deutschen Seite zur Nutzerfreundlichkeit, zuletzt aktualisiert am 24. September 2026: „Core Web Vitals werden von unseren Rankingsystemen genutzt." Im selben Text steht aber auch: „Gute Ergebnisse in Berichten wie dem Core Web Vitals-Bericht der Search Console oder Drittanbietertools können nicht garantieren, dass deine Seiten ganz oben in den Google-Suchergebnissen angezeigt werden."

Noch deutlicher wird Google hier: „Wahrscheinlich hast du Wichtigeres zu tun, als nur der SEO wegen einen perfekten Wert anzustreben." Als Datenbasis für diesen Rankingfaktor nennt Google den Chrome-UX-Bericht, also die Felddaten aus dem oberen Bereich. Eine Google-Aussage, dass die Lighthouse-Punktzahl aus dem Labor ins Ranking eingeht, haben wir nicht gefunden, und wie stark die Core Web Vitals gewichtet werden, nennt Google ebenfalls nicht.

Für kleine Betriebe heißt das: Ohne Felddaten gibt es für eure Seite gar keine Core Web Vitals-Bewertung, die man bestehen oder verfehlen könnte. Schneller werden lohnt sich trotzdem, wegen der Besucher, die auf dem Handy warten. Und Relevanz geht vor, denn laut Google versucht die Suche immer, die relevantesten Inhalte zu zeigen, auch wenn die Nutzerfreundlichkeit einer Seite in mancher Hinsicht unterdurchschnittlich ist. Steckt eure Zeit zuerst in Inhalte, die Fragen eurer Kunden beantworten, und in einen schnellen Largest Contentful Paint.

Barrierefreiheit, Best Practices, SEO und Agentisches Browsing in fünf Minuten

Lest die übrigen Kreise als Liste offensichtlicher Fehler, nicht als Gütesiegel. Unsere Startseite hatte am 29. September 2026 Barrierefreiheit 97, Best Practices 100 und SEO 100, handwerk.de 96, 96 und 100. Diese Werte haben mit den Core Web Vitals nichts zu tun, sie stammen aus eigenen Prüfungen von Lighthouse, bei Best Practices etwa in Gruppen wie „Vertrauen und Sicherheit" und „Browserkompatibilität". Klickt bei jedem Kreis unter 100 auf die fehlgeschlagenen Prüfungen und behebt, was sich schnell beheben lässt.

Bei Barrierefreiheit sagt Lighthouse selbst, dass die automatische Erkennung nicht alle Probleme findet und manuelle Tests empfohlen werden. Eine 97 heißt also nicht, dass eure Seite barrierefrei ist. Bei SEO schreibt Lighthouse, dass es nur grundlegende Empfehlungen prüft und viele Faktoren, die das Ranking beeinflussen können, gar nicht bewertet. Eine 100 dort ist eine Grundlage, keine Platzierung.

Neu ist die Kategorie „Agentisches Browsing". Sie kam im Mai 2026 mit Lighthouse 13.3 dazu und war in unserer Oberfläche am 29. September 2026 sichtbar, bei uns mit 1/2, bei handwerk.de mit 2/2. Die Kategorie beschreibt sich selbst als noch in der Entwicklungsphase, sie kann sich also ändern. Schaut hinein, notiert den Wert und wartet mit Umbauten, bis Google genauer beschreibt, was dort zählt.

Handgriffe für Wix, Jimdo und WordPress, die ihr selbst erledigen könnt

Verkleinert jedes große Foto vor dem Hochladen auf die Breite, in der es auf der Seite erscheint. Fotos aus einer Handykamera haben oft mehrere tausend Pixel Kantenlänge, unser eigenes Titelbild war mit 4160 × 6240 Pixeln angelegt. Das spart Datenmenge für alle Besucher, den Largest Contentful Paint verbessert es aber nur, wenn in der Aufschlüsselung das Laden die größte Teilzeit ist. Speichert Fotos als JPG oder WebP statt als PNG, und fangt mit dem Titelbild der Startseite an.

Räumt Einbettungen auf, die ihr nicht mehr braucht. Karten, Videos, Social-Media-Feeds, Chat-Fenster und Bewertungs-Widgets laden in der Regel Code von Drittanbietern, und genau den zeigt euch die Statistik „Drittanbieter". Bei Wix und Jimdo sind das oft Apps oder Elemente, die irgendwann einmal hinzugefügt und dann vergessen wurden. Wo eine Karte nur den Weg zeigen soll, reicht oft ein Bild mit einem Link zum Routenplaner.

Bei WordPress mistet ihr Plugins aus und prüft das verzögerte Laden des ersten Bildes. Jedes Plugin, das Skripte oder Stylesheets in den Kopf der Seite schreibt, kann unter „Anfragen zum Blockieren des Renderings" auftauchen. Wenn ein Plugin Bilder verzögert lädt, nehmt das Titelbild davon aus, weil Google vom verzögerten Laden beim LCP-Bild abrät. Setzt fetchpriority="high" höchstens auf dieses eine Bild, denn laut Google hilft die hohe Priorität nicht mehr, wenn man sie mehr als einem oder zwei Bildern gibt.

Bei allen Systemen gilt: wenige Schriftschnitte, und wo die Einstellungen es erlauben, font-display auf swap, das empfiehlt Google in der Statistik Schriftart-Anzeige. Die Cache-Laufzeit aus Effiziente Verweildauer im Cache verwenden hängt dagegen am Hosting, bei Baukästen könnt ihr sie meist nicht selbst ändern, bei WordPress fragt ihr euren Hoster. In unserem Kölner Vergleich lagen die Mediane der Leistungspunktzahl bei WordPress 64, Wix 70, Jimdo 69 und TYPO3 69, die Details stehen im Ladezeit-Vergleich von WordPress, Wix, Jimdo und TYPO3. Das System entscheidet also weniger als das, was ihr hineinpackt.

Fazit: was heute, was diese Woche, was später

Heute messt ihr eure Startseite und eure wichtigste Leistungsseite je fünfmal mobil und notiert den Median von Punktzahl und Largest Contentful Paint. Dann lest ihr den oberen Bereich: Steht dort eine Bewertung, zählt sie, steht dort „Keine Daten", schaut ihr in der Search Console nach. Zum Schluss öffnet ihr die LCP-Aufschlüsselung und schreibt auf, welches Element dort genannt wird.

Die Reihenfolge aus diesem Beitrag: heute messen und lesen, diese Woche Titelbild und Drittanbieter, später die Themen, für die ihr vielleicht Hilfe braucht.

Diese Woche tauscht ihr das Titelbild gegen eine passend verkleinerte Fassung, nehmt es aus dem verzögerten Laden heraus und geht die Liste der Drittanbieter durch. Prüft außerdem in einem privaten Fenster, wie sich die Seite nach dem Zustimmen im Cookie-Banner verhält. Danach messt ihr wieder fünfmal und vergleicht die Mediane.

Später kommen die Themen, für die ihr vielleicht Hilfe braucht: blockierende Dateien, Schriften, Cache und Hosting. Habt ihr Felddaten, braucht eine Verbesserung bis zu 28 Tage, bis sie oben vollständig sichtbar ist, weil dort immer die letzten 28 Tage zusammengefasst werden. Wer Handy und Computer ohne eigene Tabelle im Blick behalten will, kann unseren kostenlosen Speed-Check nutzen, der über dieselbe PageSpeed-Schnittstelle misst, Handy und Computer nebeneinander zeigt und die Werte erklärt.

Wer das nicht selbst machen will, bekommt es bei uns zum Festpreis. Das Speed-Paket für 95 € netto ist für Unternehmenswebsites bis 15 Unterseiten gedacht: Bilder verkleinern und in modernen Formaten ausliefern, Caching und Komprimierung einrichten, unnötige Skripte und Plugins entfernen, Schriften lokal einbinden, das Titelbild vorladen, dazu ein Vorher-nachher-Bericht mit Googles Werten. Das Speed-Paket Plus für 295 € netto richtet sich an Shops und größere Seiten bis 60 Unterseiten, mit Hosting-Prüfung, allen Vorlagen statt nur der Startseite und drei Monaten Überwachung. Beim Plus gilt: Steigt der Handy-Wert nicht um mindestens 20 Punkte, zahlt ihr nichts, ausgenommen Baukästen wie Wix oder Jimdo.

Wir wissen, wie das nach dem Abschnitt über unsere eigene Startseite klingt. Genau deshalb messen wir vorher und nachher und schicken euch den Bericht, statt euch eine schöne Zahl zu versprechen.

Was sich geändert hat und was das für euch heißt

12. März 2024: Interaction to Next Paint hat First Input Delay als Core Web Vital ersetzt. Für euch heißt das: Ratgeber, die FID erklären, sind veraltet, und für die Reaktionszeit gibt es im Labor keinen direkten Messwert, Total Blocking Time dient dort nur als Ersatz. Aus der Search Console verschwand FID sofort, PageSpeed Insights bekam eine Übergangszeit von sechs Monaten.

28. April 2025: Google kündigte an, die bisherigen Lighthouse-Prüfungen durch Insights zu ersetzen, auf Deutsch „Statistiken". Für euch heißt das: Die Gruppe „Empfehlungen" aus älteren Anleitungen gibt es so nicht mehr, ihr findet die Hinweise unter „Statistiken" und „Diagnose".

10. Oktober 2025: Lighthouse 13 entfernte die alten Prüfungen aus Bericht und Daten, PageSpeed Insights sollte laut Google innerhalb einer Woche folgen. Für euch heißt das: Bildschirmfotos von vor diesem Datum zeigen oft Einträge, die ihr nicht mehr findet. Die Gewichtung der Punktzahl blieb gleich, bei TBT 30, LCP 25, CLS 25, FCP 10 und Speed Index 10.

7. Mai 2026: Lighthouse 13.3 brachte die Kategorie „Agentisches Browsing". Für euch heißt das: Im Bericht steht ein zusätzlicher Wert, der sich selbst noch als in Entwicklung bezeichnet. Notiert ihn, aber baut nichts danach um.

18. September 2026: Lighthouse 13.5 ist erschienen, am 29. September 2026 lief PageSpeed Insights bei unseren Messungen mit Lighthouse 13.5.0. Für euch heißt das: Notiert bei jeder Messung die Version aus den Testbedingungen, damit ihr später wisst, was ihr miteinander vergleicht.

24. September 2026: Google hat die deutsche Seite zur Nutzerfreundlichkeit zuletzt aktualisiert, aus dieser Fassung stammen die Ranking-Zitate oben. Für euch heißt das: Core Web Vitals zählen, eine perfekte Punktzahl muss es nicht sein. Die Grenzwerte für LCP, INP und CLS selbst haben sich seit März 2024 nicht geändert. Stand dieser Fassung: 30. September 2026.

Wollt ihr wissen, was eure Seite wirklich bremst?

Schreibt uns, wir lesen den Bericht mit euch und sagen euch, welche zwei oder drei Punkte sich zuerst lohnen. Meistens sind es ein zu großes Titelbild, ein paar Einbettungen, die niemand mehr braucht, und ein Cookie-Banner, der mehr nachlädt als nötig. Bei uns war es, wie ihr gelesen habt, ein Übersetzungsskript, man lernt nie aus. Vorher könnt ihr eure Seite in einer Minute mit dem Speed-Check messen.

Eine kurze Nachricht über unser Kontaktformular genügt, eure Domain reicht uns als Einstieg. Wir antworten innerhalb von 24 Stunden, persönlich und ohne Vertriebsgespräch.