PageSpeed Score 95+: So wird Ihre Website wirklich schnell

Was misst der PageSpeed Score überhaupt?

PageSpeed Insights zeigt zwei verschiedene Dinge, die ständig verwechselt werden. Oben stehen, sofern genug Traffic vorhanden ist, die Felddaten: echte Messwerte echter Besucher aus dem Chrome User Experience Report, ausgewertet als Core Web Vitals (LCP für die Ladezeit des Hauptinhalts, INP für die Reaktionszeit auf Eingaben, CLS für Layout-Springen). Darunter steht der Labortest mit dem bekannten Score von 0 bis 100: eine simulierte Messung auf einem gedrosselten Mittelklasse-Smartphone. Für Google-Rankings zählen die Felddaten; der Labor-Score ist das Diagnose-Werkzeug, mit dem man Probleme findet, bevor echte Nutzer sie erleben. Warum die Web Vitals über Rankings und Conversion mitentscheiden, haben wir im Beitrag Core Web Vitals: Warum Ladezeiten über Ihren Erfolg entscheiden ausführlich behandelt.

Wichtig für realistische Erwartungen: Der Mobile-Score ist der strenge; ein Desktop-Wert von 95+ sagt wenig. Und ab etwa 90 Punkten aufwärts wird jeder weitere Punkt exponentiell teurer. Der Sprung von 55 auf 85 bringt Besuchern mehr als der von 95 auf 100.

Die größten Hebel: Bilder und Schriften

In der Praxis geht bei kleinen Unternehmens-Websites der Löwenanteil der Ladezeit auf Bilder zurück: das 4-MB-Teambild direkt von der Kamera, der Slider mit acht Vollbild-Fotos. Die Behebung ist Handwerk: moderne Formate (WebP oder AVIF statt JPEG/PNG), Auslieferung in der tatsächlich angezeigten Größe statt in Originalauflösung, feste Breiten- und Höhenangaben gegen Layout-Springen, Lazy Loading für alles unterhalb des sichtbaren Bereichs, aber ausdrücklich nicht für das Hauptbild oben, das im Gegenteil mit hoher Priorität geladen werden sollte, weil es meist den LCP-Wert bestimmt. Moderne Frameworks und gute CMS-Setups erledigen das automatisch; bei klassischen WordPress-Themes muss es ein Plugin oder die Agentur richten. Die Systemfrage dahinter behandelt unser Vergleich WordPress oder individuelle Webentwicklung.

Zweiter Klassiker sind Webfonts: vier Schriftschnitte von einem externen Dienst, geladen bevor irgendein Text erscheint. Besser: maximal zwei bis drei Schnitte, als WOFF2 vom eigenen Server (das erspart auch den DSGVO-Streitpunkt Google Fonts), mit font-display: swap, damit Text sofort mit einer Systemschrift erscheint und nicht auf die Schrift wartet.

Der unterschätzte Hebel: Drittanbieter-Skripte

Wer nach Bildern und Schriften immer noch bei Score 70 hängt, findet den Grund fast immer in der Skript-Liste: Analytics, Tag Manager, Chat-Widget, Karten-Einbettung, Social-Media-Pixel, Video-Player. Jedes für sich „nur ein Snippet“, zusammen oft mehr Ladevolumen als die gesamte eigentliche Website. Hier hilft nur Inventur: Welche Skripte erzeugen nachweislich Nutzen? Ein Chat-Widget, das nie jemand nutzt, kostet jeden Besucher Ladezeit. Was bleibt, wird nachgeladen, wenn es gebraucht wird: die Karten-Einbettung erst beim Klick auf „Karte anzeigen“, der Video-Player erst beim Abspielen, das Consent-abhängige Marketing-Skript erst nach Einwilligung. Nebenbei: Eine Analyse ohne Cookie-Banner spart das Banner und dessen Skript-Gewicht gleich mit. Mehr dazu im Beitrag Webanalyse ohne Cookie-Banner.

Fundament: Hosting, Caching, Technik-Basis

Unterhalb der Inhalte entscheidet die Infrastruktur. Die Zeit bis zum ersten Byte (TTFB) sollte unter etwa 0,8 Sekunden liegen. Ein überlastetes 3-€-Shared-Hosting schafft das oft nicht, und keine Bildoptimierung der Welt gleicht das aus. Dazu gehören serverseitiges Caching (bei WordPress ein ordentliches Caching-Plugin oder Managed Hosting), ein CDN für statische Dateien, HTTP/2 oder HTTP/3 und Komprimierung. Auf der Code-Seite gilt: ungenutztes CSS und JavaScript raus, der häufigste Fund bei Baukasten- und Theme-Websites, die für jede Eventualität Bibliotheken mitladen; warum gerade Eigenbau-Seiten hier regelmäßig zurückfallen, rechnet unser Beitrag Website selbst erstellen oder Agentur durch. Bei einem Neubau ist der Unterschied architektonisch: Statisch generierte Seiten, wie sie moderne Frameworks erzeugen, liefern HTML direkt vom CDN aus und starten dadurch mit Werten, die nachträglich optimierte Systeme selten erreichen. Das ist einer der Gründe, die wir in Next.js für kleine Unternehmen beschreiben.

Wie Sie vorgehen und wann Schluss ist

Die sinnvolle Reihenfolge: erst messen (PageSpeed Insights, mobil, mehrere Unterseiten, nicht nur die Startseite), dann die Befunde nach Effekt sortieren, dann die drei größten Posten beheben, dann erneut messen. Genauso wichtig ist das Aufhören: Wenn die Felddaten aller drei Core Web Vitals grün sind und der Mobile-Score stabil über 90 liegt, bringt weitere Optimierung Besuchern fast nichts mehr. Ab da ist Performance eine Frage der Pflege, nicht der Projekte. Neue Plugins, neue Marketing-Skripte und ungeprüfte Bild-Uploads holen jeden Score wieder ein; deshalb gehört ein Performance-Blick in jede laufende Wartung.

Fazit

Ein PageSpeed-Score von 95+ entsteht nicht durch Tool-Tricks, sondern durch vier Hebel in absteigender Wirkung: Bilder (WebP/AVIF, passende Größen, Lazy Loading außer beim Hauptbild), Schriften (wenige Schnitte, selbst gehostet, font-display: swap), Drittanbieter-Skripte (Inventur, Nachladen bei Bedarf statt bei Seitenstart) und Infrastruktur (Hosting mit TTFB unter 0,8 s, Caching, CDN). Maßgeblich für Rankings sind die Felddaten der Core Web Vitals, also LCP, INP und CLS, nicht der Labor-Score; gemessen wird mobil und auf mehreren Unterseiten. Sind alle drei Vitals im grünen Bereich und der Mobile-Score stabil über 90, ist weitere Optimierung Kosmetik, dann zählt nur noch, das Niveau im laufenden Betrieb zu halten.