Wie du einen PageSpeed-Score von 100 erreichst, und was er wirklich bedeutet.

Eine 100 in PageSpeed Insights ist eine der wenigen Zahlen in der Webentwicklung, die du bis zu einem echten, buchstäblichen Maximum treiben kannst — genau deshalb jagen Teams ihr hinterher, es ist ein Score, kein Gefühl. Für sich genommen ist es aber ein reiner Laborwert: ein simulierter Seitenaufruf, auf einem festen Gerät und Netzwerkprofil, einmal ausgeführt. Sie zu erreichen ist eine echt nützliche Disziplin, die reale Fixes erzwingt. Sie als Ziellinie zu behandeln, ist der Fehler, den fast jeder macht, der ihr nachjagt. Hier ist, woraus die Zahl tatsächlich besteht, was jeden Teil davon bewegt, und was noch zu prüfen ist, sobald der Laborwert 100 zeigt.

Woher die 100 Punkte tatsächlich kommen

Der Score ist ein gewichteter Durchschnitt aus fünf Metriken, und die Gewichte sind alles andere als gleich. Wähl eine Metrik aus und sieh, was sie misst, was sie bewegt und wie viel deines Scores an ihr hängt.

Die fünf Metriken hinter der Zahl

TBT und LCP zusammen sind 55 % des Scores. Teams, die zuerst Hero-Bilder reparieren und erst danach JavaScript, weil Bilder wie der offensichtliche Übeltäter wirken, sehen oft einen kleineren Sprung als erwartet — die größere Zahl wartete hinter dem Script-Tag.

Woraus der Score tatsächlich besteht

Der 0–100-Score ist ein gewichteter Durchschnitt aus fünf Metriken, jede auf ihrer eigenen Kurve bewertet und dann kombiniert: Total Blocking Time mit 30 %, Largest Contentful Paint mit 25 %, Cumulative Layout Shift mit 25 %, First Contentful Paint mit 10 % und Speed Index mit 10 %. TBT allein trägt dreimal so viel Gewicht wie FCP, weshalb zwei Seiten mit demselben „fühlt sich schnell an“-Ersteindruck 20 Punkte auseinanderliegen können — eine blockiert den Hauptthread zwei Sekunden lang nach genau diesem ersten Rendering, und der Score bestraft exakt das.

Jede Metrik wird nicht linear bewertet. Chromes eigene Dokumentation legt die Kurve auf eine log-normale Verteilung, aufgebaut aus echten HTTP-Archive-Daten, mit zwei festen Punkten: Das 25. Perzentil echter Seiten erhält den Score 50, das 8. Perzentil erhält 90. Zwischen etwa 50 und 92 ist der Zusammenhang nahezu linear — Zeit von einer langsamen Metrik abzuschneiden kauft eine vorhersagbare Anzahl Punkte. Über 96 nicht mehr: Dieselbe eingesparte Zeit kauft einen Bruchteil eines Punkts, der mathematische Grund, warum die letzten Punkte bis zur 100 unverhältnismäßig mehr Arbeit kosten als die ersten sechzig.

Warum der Hauptthread den größten Schaden anrichtet

TBT misst jede Zeitspanne, in der der Hauptthread länger als 50 Millisekunden zwischen First Contentful Paint und dem Moment blockiert ist, in dem die Seite interaktiv wird, alles zusammengerechnet. Selten ist es eine einzelne langsame Sache — meist sind es ein Dutzend kleine: ein Bundle, das geparst und ausgeführt wird, bevor irgendetwas anderes laufen kann, ein Chat-Widget oder Analytics-Tag, das eifrig lädt, eine Karussell-Bibliothek, die DOM-Arbeit für etwas erledigt, zu dem noch niemand gescrollt hat. Jede für sich wirkt harmlos in einem Code-Review. Übereinandergestapelt sind sie das, was ein Besucher als Seite erlebt, die fertig aussieht und nicht reagiert, wenn man sie antippt.

Der Fix heißt selten „schnelleren Code schreiben“ — meistens geht es um Reihenfolge. Alles aufschieben, was für den ersten Rendering-Vorgang nicht gebraucht wird, große Bundles aufteilen, damit der Browser nicht gezwungen ist, Code für Funktionen zu parsen, zu denen noch niemand gescrollt hat, und Drittanbieter-Skripte — Chat, Werbung, Marketing-Pixel — erst nach der ersten Interaktion laden statt beim Seitenaufruf, da keines von ihnen der Grund ist, warum jemand auf die Seite gekommen ist. Eine gezielte Performance-Optimierung ist meist genau diese Liste, einmal richtig gemacht, statt ein Neubau.

Warum sich der Score zwischen Durchläufen bewegt, selbst auf derselben Seite

Ein einzelner Lighthouse-Lauf ist eine Stichprobe, keine Messung — Chromes eigene Scoring-Dokumentation listet A/B-Tests, Änderungen bei der Werbeauslieferung, wechselnde Internet-Routen, Geräteauslastung, Browser-Erweiterungen und Antivirensoftware als normale Quellen für Schwankungen zwischen Durchläufen, zusätzlich zu allem, was dein eigenes Deployment geändert hat. Ein Score von 94 in einer Minute und 88 in der nächsten ist meist keine Regression; es ist dieselbe Seite, unter leicht anderen Bedingungen gemessen. Beurteile einen Trend über mehrere Durchläufe, nicht eine einzelne Zahl, die für einen Bericht als Screenshot festgehalten wurde.

Desktop und Mobil sind auch nicht derselbe Test mit anderem Etikett. Seit Lighthouse v6 laufen sie auf getrennten Scoring-Kurven, kalibriert auf unterschiedliche reale Daten, und Mobil wird absichtlich auf ein langsameres, stärker eingeschränktes Profil gedrosselt — es soll ein Mittelklasse-Handy in einem echten Netz abbilden, nicht die Glasfaserverbindung, auf der der Test zufällig läuft. Eine Seite, die auf Desktop 100 und auf Mobil 74 erreicht, ist kein Bug im Tool; es ist das Tool, das genau das tut, wofür es gedacht ist.

Die Lücke zwischen 100 im Labor und „gut“ für echte Besucher

PageSpeed Insights zeigt Labor- und Felddaten nebeneinander, und Google ist ausdrücklich, dass sie nicht kombiniert werden: Der 0–100-Score basiert vollständig auf dem Labor-Lauf, und Felddaten — echte Besuche, aggregiert aus dem Chrome UX Report — werden separat gemeldet, ohne diese Zahl zu berühren. Die eigene Dokumentation sagt es unumwunden: Gute Labordaten bedeuten nicht zwangsläufig, dass auch die Erfahrungen echter Nutzer gut sind. Eine 100 sagt dir, dass der simulierte Ladevorgang auf dem getesteten Gerät und Netzwerk exzellent war. Sie sagt dir nicht, was auf einem drei Jahre alten Android-Handy mit wackligem 4G passiert ist — und dort liegt ein erheblicher Teil des echten Traffics.

Hier kommen auch Core Web Vitals als eigene, in mancher Hinsicht wichtigere Zahl ins Spiel — Felddaten, bewertet am 75. Perzentil echter Besuche über ein rollierendes Fenster, und genau das, worauf Googles Ranking-Systeme tatsächlich schauen. Eine Seite kann im Labor eine 100 halten und trotzdem bei den Core Web Vitals im Feld durchfallen, wenn ihr echtes Publikum eher ältere Geräte oder langsamere Verbindungen nutzt, als der Labortest simuliert. Prüf beides. Sie beantworten unterschiedliche Fragen.

Die Metrik, die der Score überhaupt nicht misst

Es gibt einen Core Web Vital, den der Performance-Score in keiner Form enthält: Interaction to Next Paint. INP hat First Input Delay am 12. März 2024 als Core Web Vital abgelöst und hört anders als FID nicht bei der ersten Interaktion auf — es beobachtet die Latenz jedes Klicks, Taps und Tastendrucks über die gesamte Dauer eines Besuchs und meldet einen einzigen Wert, der den schlechtesten davon repräsentiert. Gut sind 200 Millisekunden oder weniger im 75. Perzentil echter Besuche; über 500 Millisekunden gilt als schlecht.

Ein Labordurchlauf kann diese Zahl nicht ehrlich erzeugen, weil ein Labordurchlauf nicht mit der Seite interagiert — er lädt sie und hört auf. Chromes eigene Dokumentation sagt ausdrücklich, dass ein Labor-INP-Wert vollständig davon abhängt, welche Interaktionen während der Messung ausgeführt wurden, und dass viele Laborwerkzeuge gar keinen melden. Total Blocking Time ist der nächstliegende Laborersatz, deckt aber nur das Fenster rund um den Seitenaufbau ab. Die praktische Folge ist ein sehr verbreiteter Fehlerfall: Eine Seite erreicht 100, und dann braucht ein Menü auf einem Mittelklasse-Handy 600 Millisekunden zum Öffnen, weil ein Event-Handler pro Tap zu viel Arbeit erledigt. Der Score hat das nie gesehen, weil niemand etwas angetippt hat.

Die Reihenfolge, in der die Fixes tatsächlich kommen

Der Score belohnt eine bestimmte Abfolge, und sie in falscher Reihenfolge abzuarbeiten ist der Grund, warum Teams bei 70 hängen bleiben. Fang damit an, mehrere Durchläufe zu messen statt einen, damit du eine Bandbreite optimierst und keinen Ausreißer. Nimm dann zuerst Total Blocking Time, weil sie 30 % des Scores ausmacht und fast immer der größte Einzelverlust ist: Prüfe, was vor dem ersten Rendering lädt, schiebe alles auf, was dafür nicht gebraucht wird, teile das Bundle so auf, dass Code für Funktionen unterhalb des Folds nicht vorab geparst wird, und halte Drittanbieter-Skripte — Chat, Analytics, Pixel — bis nach der ersten Interaktion zurück. Bevor du all das angehst, prüf, ob nicht der Server die Obergrenze setzt — was dein Server mit deinem PageSpeed-Score macht behandelt die Schicht unter diesen Fixes.

LCP kommt als zweites: Finde heraus, was das größte Element tatsächlich ist (häufig eine Überschrift in einem Webfont, nicht das Hero-Bild, das alle vermuten), dann komprimieren, in einem modernen Format ausliefern, vorladen und aus der Warteschlange hinter anderen Requests herausnehmen. CLS ist das dritte und meist das billigste der drei — explizite Breite und Höhe auf jedem Bild und Embed, reservierter Platz für alles, was spät eingefügt wird, und eine Font-Ladestrategie, die die Seite nicht umbricht. Erst wenn diese drei grün sind, lohnt der letzte Kilometer — die Lücke von 94 auf 100 — überhaupt jemandes Zeit, und dann sind es meist zwei oder drei konkrete Punkte statt eines Projekts.

Wann sich die buchstäbliche 100 lohnt, und wann nicht

Die log-normale Kurve bedeutet, dass die letzten Punkte mit großem Abstand die teuersten auf der ganzen Seite sind — was 100 zum richtigen Ziel für eine kleine Gruppe von Seiten macht und zu einem echt verschwenderischen für den Rest der Seite. Die Seiten, die die letzte Meile wert sind, sind die mit kommerziellem Gewicht: die Startseite, die wichtigsten Landingpages, auf die Werbetraffic trifft, alles, worauf eine bezahlte Kampagne zeigt. Ein Blogartikel zwei Klicks tief wird die Stunden, die man in das Schließen einer 94-zu-100-Lücke steckt, sehr wahrscheinlich nicht wieder hereinholen.

Neunzig ist, wo der praktische Ertrag meist endet, und Chromes eigene Farbcodierung stimmt zu — 90 und darüber gilt als „gut“, Punkt, ohne Unterscheidung zwischen 90 und 100. Verbring die zusätzliche Stunde lieber an der Seite, die noch niemand repariert hat, statt an der, die schon grün ist.

Wie wir das in der Praxis angehen

Eine technische Analyse ist, wo das beginnt — sie sagt dir, welche der fünf Metriken dich auf deinen kommerziell wichtigen Seiten tatsächlich Punkte kostet, statt aus einem einzelnen Lighthouse-Lauf zu raten. Von dort repariert eine gezielte Performance-Optimierung die konkrete Liste statt einer generischen.

Bei einem Neubau ist das kein separater Posten — ein Business-Website-Projekt wird auf einem modernen Stack gebaut, genau damit der Score vom ersten Tag an nah an diesem Bereich liegt, statt etwas, das man ein Jahr später nachrüsten muss, sobald Templates und die Liste der Drittanbieter-Skripte beide über den Punkt hinausgewachsen sind, an dem die Reparatur noch günstig ist.

Die Navigationen, die der Score nie sieht

Alles bisher dreht sich um den ersten Seitenaufruf. Chromes eigene Nutzungsdaten weisen aber 1 von 10 Navigationen am Desktop und 1 von 5 mobil als Vor- oder Zurück-Navigation aus — und die sind, wenn du es zulässt, gar keine Ladevorgänge. Der Back/Forward-Cache hält einen pausierten Schnappschuss der Seite im Speicher und stellt ihn fast sofort wieder her, ganz ohne Netzwerk. PageSpeed Insights wird dir das nie zeigen. Es ist kein Teil des Scores — in keinem Durchlauf, mit keiner Gewichtung.

Es ist aber ein großer Teil davon, ob sich die Seite schnell anfühlt, und es geht vor allem darum, sich nicht selbst zu disqualifizieren. Die Blocker sind eindeutig und leicht zu prüfen: Nutze niemals das unload-Event — web.dev sagt das so unmissverständlich, wie Dokumentation überhaupt etwas sagen kann. Cache-Control: no-store kann eine Seite ausschließen. Offene IndexedDB-, fetch-, WebSocket- oder WebRTC-Verbindungen und ein window.opener, der nicht null ist, halten dich ebenfalls draußen. Die Chrome DevTools testen eine Seite und nennen den Grund für das Scheitern. Die Reparatur besteht meist darin, etwas zu löschen statt etwas zu bauen — damit ist es die günstigste Performance-Arbeit auf der Liste, und sie ist für die Zahl, die du optimiert hast, vollkommen unsichtbar.

Quellen

Die Scoring-Gewichte, die Methodik und die Labor-/Felddaten-Unterscheidung oben stammen aus diesen Quellen, geprüft im August 2026.

• Chrome for Developers — Lighthouse performance scoring ↗

  Aktuelle Metrik-Gewichte (TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 %, SI 10 %), die log-normale Scoring-Kurve, kalibriert auf HTTP-Archive-Daten (25. Perzentil = 50, 8. Perzentil = 90), und die Quellen für Score-Schwankungen zwischen Durchläufen.

• Google for Developers — About PageSpeed Insights ↗

  Stellt klar, dass der angezeigte Score nur auf Labordaten basiert, dass Feld- und Labordaten separat statt kombiniert gezeigt werden, und dass „gute Labordaten nicht zwangsläufig bedeuten, dass auch die Erfahrungen echter Nutzer gut sind“.

• Chrome for Developers — CrUX methodology ↗

  Wie die Eignung für Felddaten funktioniert, und warum sie echte Besuchsbedingungen widerspiegeln statt eines einzelnen simulierten Ladevorgangs.

• web.dev — Interaction to Next Paint (INP) ↗

  INP beobachtet die Latenz aller Klick-, Tap- und Tastatur-Interaktionen über die gesamte Dauer eines Besuchs. Schwellenwerte: gut bei 200 Millisekunden oder weniger, verbesserungswürdig zwischen 200 und 500, schlecht über 500. Hält außerdem fest, dass ein Labor-INP-Wert davon abhängt, welche Interaktionen ausgeführt wurden, und dass manche Laborwerkzeuge ihn gar nicht melden.

• web.dev — Interaction to Next Paint becomes a Core Web Vital on March 12 ↗

  Bestätigt, dass INP First Input Delay am 12. März 2024 als Core Web Vital abgelöst hat.

• web.dev — Back/forward cache ↗

  Chrome-Nutzungsdaten zeigen: 1 von 10 Navigationen am Desktop und 1 von 5 mobil sind Vor- oder Zurück-Navigationen. Das unload-Event, Cache-Control: no-store, offene Verbindungen und ein nicht-leerer window.opener können eine Seite ausschließen.