So verbessern Sie Ihren Google PageSpeed Score im Jahr 2026

Eine Punktzahl von 92, die 42 hätte sein sollen

Letzten Monat habe ich drei Stunden damit verbracht, das Laden der Schriftarten einer Kundenwebsite zu optimieren — Subsetting, Preloading, Umstellung auf font-display: swap, das ganze Programm. Endlicher PageSpeed Score: 92.

Der Kunde fragte, ob wir das eigentliche Problem behoben hätten. Wie sich herausstellte, war das Hero-Bild 4,2 MB groß. Ein <picture>-Tag und eine AVIF-Konvertierung später fielen wir von 92 auf 58 — weil Lighthouse jetzt tatsächlich sehen konnte, wie langsam der Rest der Seite war.

Das passiert, wenn man über PageSpeed Scores nachdenkt. Sie verraten dir nicht, was tatsächlich langsam ist. Sie verraten dir, was Lighthouse für langsam hält. Und manchmal sind das zwei sehr unterschiedliche Dinge.

Was PageSpeed tatsächlich misst

Google PageSpeed Insights gibt dir einen Score von 0-100 auf Basis von Lab-Daten aus Lighthouse. Er ist selbst kein Ranking-Faktor, korreliert aber mit den Core Web Vitals — und die sind Ranking-Faktoren.

Was ich Kunden sage: Wenn dein Score unter 50 liegt, hast du echte Probleme. Bei 50-89 bist du im Bereich „die offensichtlichen Dinge beheben". Bei 90+ solltest du noch nicht feiern — schau dir stattdessen deine tatsächliche Ladezeit in den Chrome DevTools an.

Die fünf Dinge, die den Unterschied wirklich machen

Nach der Prüfung von über 200 Websites ist das, was durchgängig den größten Unterschied macht:

Bilder. Immer Bilder. Ich habe noch nie eine Website mit einem Score unter 70 geprüft, bei der Bilder nicht das Hauptproblem waren. Keine ausgefallene JavaScript-Optimierung, kein kritisches CSS — Bilder.

JavaScript-Ausführungszeit. Das hier ist tückisch, weil es in Lighthouse-Audits nicht immer auftaucht. Deine Seite könnte 95 erreichen und trotzdem 3 Sekunden Main-Thread-Blockierung haben. Prüfe den Performance-Tab in den DevTools, nicht nur Lighthouse.

Server-Antwortzeit. Wenn dein TTFB über 800 ms liegt, ist alles andere egal. Aus meiner Erfahrung gibt es Websites mit perfekten Bildern und null JavaScript, die trotzdem langsam laden, weil der Server 2 Sekunden für die Antwort braucht.

Caching. Das Geschenk, das immer weiter gibt. Einmal eingerichtet, und jeder wiederkehrende Besucher profitiert davon.

CDN. Wenn dein Publikum global ist und dein Server an einem Ort steht, ist ein CDN keine Option mehr.

Wenn PageSpeed dich belügt

Letztes Quartal habe ich einen Shopify-Store geprüft. PageSpeed Score: 98. Tatsächliche Ladezeit: 4,2 Sekunden. Der Store hatte 47 Tracking-Skripte, ein Chat-Widget, ein Popup und drei Empfehlungs-Engines. Lighthouse war das egal — es testete eine saubere Version ohne all das.

Das passiert ständig. PageSpeed testet deine Seite in einer Laborumgebung. Deine echten Nutzer haben Adblocker, langsame Handys und Netzwerkbedingungen, die kein Labor simulieren kann.

Mein tatsächlicher Workflow (keine Checkliste)

Was ich tue, wenn mich jemand bittet, seinen PageSpeed Score zu verbessern:

Schritt 1: DevTools öffnen, nicht PageSpeed Insights. Ich will den tatsächlichen Network-Waterfall sehen. Wie groß ist die Seite? Wie viele Requests? Was dauert am längsten?

Schritt 2: Die größten Übeltäter prüfen. Meist sind es Bilder, aber manchmal ist es ein 2 MB großes JavaScript-Bundle, das absolut nichts Nützliches tut. Aus meiner Erfahrung sind Analytics-Skripte größer als ganze Landing Pages.

Schritt 3: Bilder reparieren. Das ist fast immer der erste Erfolg. Zu WebP konvertieren, srcset hinzufügen, Below-the-Fold-Inhalte lazy loaden. Dauert 15 Minuten und bringt meist 10-20 Punkte.

Schritt 4: Unbenutztes JavaScript entfernen. Öffne den Coverage-Tab in den DevTools. Du wirst wahrscheinlich feststellen, dass 60-80% deines JavaScript nie ausgeführt wird. Entferne es.

Schritt 5: Nicht überoptimieren. Aus meiner Erfahrung verbringen Entwickler Tage damit, aus einem 95er Score noch 3 Punkte herauszukitzeln. Diese Zeit ist besser investiert, um echte User-Experience-Probleme zu beheben.

Die WebP-Falle

Jeder sagt dir, du sollst Bilder zu WebP konvertieren. Das habe ich auf einer Kundenwebsite gemacht, und ihr Score ging tatsächlich nach unten. Warum? Weil sie WebP an Safari-Nutzer mit älteren iOS-Versionen ausgeliefert haben, die es nicht unterstützen. Das Fallback-JPEG war dreimal so groß.

Jetzt teste ich immer mit <picture>-Tags und mehreren Quellen:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image">
</picture>

Es ist mehr Code, aber es funktioniert überall.

Schriftarten, die das Rendering nicht blockieren

Ich dachte früher, font-display: swap sei die Allzweckwaffe. Dann wurde mir klar, dass es nur bedeutet „unsichtbaren Text kurz anzeigen, dann die echte Schrift einblenden". Das ist für Fließtext in Ordnung, aber bei Überschriften sieht es kaputt aus.

Mein aktueller Ansatz: Systemschriften für Fließtext verwenden und bei Markenschriften nur die Schriftstärken vorladen, die du wirklich nutzt. Ich habe kürzlich eine Website geprüft, die 12 Schriftstärken lud, obwohl nur 3 verwendet wurden.

Die 80/20-Regel (diesmal wirklich wahr)

Von allen Optimierungen, die du vornehmen könntest, bringen dich diese drei 80% des Weges:

1. Bilder komprimieren und verkleinern. Nutze Squoosh.app. Es ist kostenlos. Dauert 5 Minuten pro Bild.
2. Unbenutztes JavaScript entfernen. Nutze den Coverage-Tab. Sei gnadenlos.
3. Caching aktivieren und ein CDN nutzen. Wenn du auf Vercel oder Netlify bist, ist das bereits erledigt.

Alles andere — kritisches CSS, Schriftoptimierung, Preloading — ist Feinschliff. Erledige zuerst die großen Drei.

Wann man mit dem Optimieren aufhören sollte

Ich hatte einen Kunden, der besessen davon war, 100 zu erreichen. Wir kamen auf 99 und verbrachten 8 Stunden damit, den letzten Punkt zu finden. Es war ein 12 KB großes Analytics-Skript, das bereits asynchron war.

Meine ehrliche Faustregel: Wenn du über 90 liegst und deine tatsächliche Ladezeit unter 2 Sekunden beträgt, hör auf. Deine Zeit ist mehr wert als diese letzten 10 Punkte.

Schnelle Erfolge, bevor du gehst

Bevor du den nächsten PageSpeed-Test ausführst, probiere Folgendes:

- Schicke deine URL durch den AuditMe — er kombiniert PageSpeed-Daten mit tatsächlichen Traffic-Kennzahlen

- Prüfe dein größtes Bild. Wenn es über 200 KB groß ist, komprimiere es

- Öffne DevTools → Network → aktiviere „Disable cache" → lade neu. Wenn deine Seite über 2 MB groß ist, stimmt etwas nicht

- Schau dir dein JavaScript-Bundle an. Wenn es über 500 KB groß ist, hast du ungenutzten Code

Das Fazit

PageSpeed Scores sind nützlich, aber sie erzählen nicht die ganze Geschichte. Aus meiner Erfahrung gibt es Websites mit perfekten Scores, die schmerzhaft langsam sind, und Websites mit Scores in den 60ern, die schneller laden als alles andere.

Konzentriere dich auf die tatsächliche Nutzererfahrung. Wenn deine Seite in unter 2 Sekunden lädt und deine Core Web Vitals grün sind, machst du es besser als die meisten.

Führe einen kostenlosen SEO-Audit durch, um zu sehen, wie deine Website tatsächlich performt.