PageSpeed 100 von 100 in 2026: wie und warum

„Wir haben 38 Punkte auf Mobile" – der häufigste Satz, mit dem Kunden nach einem SEO-Audit zu mir kommen. PageSpeed ist kein „Modewort", sondern seit 2021 ein echter Ranking-Faktor. In diesem Artikel: was Core Web Vitals sind, ein realistischer Plan, wie man eine Website von 40 auf 90+ in einer Woche bringt, und warum man nicht zwingend 100/100 anstreben muss.

Warum die Website überhaupt beschleunigen

Drei pragmatische Gründe – ohne Ideologie nach dem Motto „weil Google es so sagt".

• SEO-Faktor. Google berücksichtigt Core Web Vitals seit 2021 als Ranking-Faktor. Bei wettbewerbsintensiven Keywords schlägt eine schnelle Website eine langsame, bei sonst gleichen Bedingungen.
• Conversion. Jede zusätzliche Sekunde Ladezeit reduziert die Conversion um 5-7%. Im E-Commerce mehr. Direkte Geldverluste.
• Werbekosten. Google Ads gewährt einen CPC-Rabatt für schnelle Landing-Pages und bestraft langsame umgekehrt. Das wirkt sich real auf das Budget aus.

Core Web Vitals: LCP, INP, CLS

Das sind drei Metriken, die Google über Chrome (CrUX-Daten) bei echten Nutzern misst. Seit 2021 sind sie Teil des Ranking-Algorithmus.

LCP (Largest Contentful Paint)

Wie schnell das größte Element im sichtbaren Bereich erscheint – meist das Hauptbild oder eine große Überschrift. Gut: < 2.5s. Schlecht: > 4s.

Die Hauptursachen für schlechtes LCP: schwere Hero-Bilder ohne `fetchpriority="high"`, fehlendes `preload`, langsamer Server (TTFB), blockierende Scripts im head.

INP (Interaction to Next Paint)

Ersetzte 2024 den FID. Misst, wie schnell die Seite auf Klick/Tap/Tastendruck reagiert. Gut: < 200ms. Schlecht: > 500ms.

Die Hauptursachen für schlechtes INP: schweres JS im Main Thread, synchrone Event-Handler, lange `setTimeout`-Ketten. Das ist das „moderne" Kopfweh: selbst wenn die Seite schnell geladen wurde, kann sie beim Klick „hängen bleiben" wegen schlechtem JS.

CLS (Cumulative Layout Shift)

Die Summe der „Sprünge" im Layout während des Ladens. Wenn ein Banner oben nachgeladen wird – und der gesamte Text nach unten rutscht = schlechter CLS. Gut: < 0.1. Schlecht: > 0.25.

Die Hauptursachen: Bilder ohne angegebene width/height, Schriften, die ihre Größe beim Nachladen ändern, Werbeblöcke, dynamisch eingefügte Elemente.

7 Haupt-Geschwindigkeitsfaktoren

Das ist eine Basis-Checkliste. In 90% der Fälle bringen genau diese Punkte 70-90% des PageSpeed-Zuwachses.

• Bilder in WebP/AVIF + Lazy Load. 80% des „Gewichts" einer Seite sind Bilder. Die Konvertierung von PNG/JPG zu WebP bringt -40-60% Größe. AVIF ist noch besser, aber etwas schlechter unterstützt.
• Minifizierung und Kompression (Brotli). CSS/JS müssen minifiziert sein. Der Server sollte mit Brotli ausliefern (oder zumindest gzip). Cloudflare macht das automatisch.
• Ungenutztes CSS/JS entfernen. Jedes `bootstrap.css` oder `jquery.js`, das nicht zu mindestens 30% genutzt wird – entfernen. PurgeCSS + Tree-Shaking im Bundler.
• Schriften mit font-display: swap. Ohne das sieht der Nutzer einen weißen Bildschirm, während die Schrift 1-2 Sekunden lädt. Mit swap – zuerst die Systemschrift, dann wird sie ausgetauscht.
• Preload des Haupt-Hero-Bildes + preconnect zum CDN. `` reduziert das LCP um 0.5-1.5 Sekunden.
• CDN (Cloudflare). Wenn die Website in Russland gehostet wird und Kunden aus der EU kommen – ohne CDN lädt die Seite 3-5 Sekunden nur wegen der Geografie. Cloudflare löst dieses Problem kostenlos.
• HTTP/2 oder HTTP/3. Modernes Protokoll mit Multiplexing. Wird mit einem Klick beim Hosting oder in Cloudflare aktiviert. Ohne das lädt der Browser Dateien sequenziell statt parallel.

Optimierungs-plan für eine Woche

Realistischer Zeitplan, um eine Website von 40-50 Punkten Mobile auf 90+ zu beschleunigen:

1. AuditTag 1
2. BilderTag 2-3
3. CSS/JSTag 4
4. CDN/HTTPTag 5
5. FinishTag 6-7

Tag 1 – Audit. Durchlauf durch PageSpeed Insights + Lighthouse in den DevTools. Sie notieren die aktuellen LCP/INP/CLS, TBT, Seitengröße. Das ist die Ausgangsbasis für Messungen. Parallel – WebPageTest für die Waterfall-Analyse.

Tag 2-3 – Bilder. Alle JPG/PNG werden in WebP konvertiert (massenweise über `cwebp` CLI oder Squoosh.app). `width`/`height`-Attribute zu allen `` hinzufügen (gegen CLS). Hero-Bild – mit `fetchpriority="high"` und preload im ``. Die übrigen – `loading="lazy"`.

Tag 4 – CSS/JS. Minifizierung (falls noch nicht erfolgt). Entfernung von ungenutztem CSS via PurgeCSS. Scripts, die im First-Screen nicht benötigt werden – mit `defer`. Analytics und Counter – asynchron oder nach `DOMContentLoaded`.

Tag 5 – CDN und HTTP/3. Sie verbinden Cloudflare (falls noch nicht vorhanden) – kostenlos, 5 Minuten. Sie aktivieren Brotli, HTTP/3, Auto Minify, Rocket Loader (vorsichtig – kann JS brechen). Sie richten Cache-Regeln für statische Inhalte ein (1 Jahr für Assets mit Hash im Namen).

Tag 6-7 – Finish. Wiederholter PageSpeed-Durchlauf. Punktuelle Korrekturen verbleibender Probleme: Third-Party-Scripts in iframe, Schriften mit font-display, Entfernung unnötiger preconnects. Finale Messung. Wenn 90+ Mobile – Ziel erreicht.

7 typische Fehler

Diese Fehler sehe ich regelmäßig – bei Kunden, die vorher mit anderen Dienstleistern gearbeitet haben oder es selbst versucht haben.

1. Desktop optimieren, Mobile vergessen. Mobile-First-Indexing seit 2019. Google rankt auf Basis der mobilen Version. Desktop 95 + Mobile 45 = wird wie 45 gerankt.
2. Nur in Lighthouse testen, keine Field-Data anschauen. Lighthouse sind Labordaten. Die Search Console zeigt echte CWV bei echten Nutzern. Sie können sich unterscheiden.
3. „Das WP-Optimize-Plugin hilft, installieren wir". Optimierungs-Plugins kollidieren oft, machen Unvorhersehbares. Besser ein gut konfiguriertes als drei, die sich gegenseitig „helfen".
4. Lazy Load auf Hero-Bilder. Der größte Fehler. Lazy Load für ein Bild above the fold = LCP-Erhöhung. Lazy Load – nur für Bilder unterhalb des First Screens.
5. Schwere Schriften ohne preload und font-display. Schrift mit Gewicht 800 und Unterstützung für 5 Sprachen = 200KB. Ohne font-display: swap – weißer Bildschirm 1-2 Sekunden. Mit preload – LCP verkürzt sich.
6. Third-Party-Scripts im head. Yandex.Metrika + Google Analytics + Facebook Pixel + Hotjar + ... synchron im head – TBT (Total Blocking Time) rutscht in die rote Zone. Verschieben in den Footer oder asynchron.
7. Server-Side-Performance ignorieren. TTFB (Time to First Byte) – oft ein serverseitiges Problem: langsames PHP, nicht optimierte SQL-Abfragen, fehlendes Server-Caching. Nur die Client-Optimierung hilft nicht, wenn der Server selbst 2 Sekunden braucht, um zu antworten.

Häufige Fragen