Ich habe meine eigene Website von 85 auf 100 PageSpeed-Score optimiert. Keine Theorie — nur Techniken, die wirklich funktionieren. In diesem Guide zeige ich dir Schritt für Schritt, wie du dieselben Werte erreichst.

Was sich 2026 geändert hat

Im März 2026 hat Google ein Core Update ausgerollt, das die Schwellenwerte für die Core Web Vitals verschärft hat. Konkret:

  • Die LCP-Schwelle wurde von 2,5 s auf 2,0 s abgesenkt
  • INP (Interaction to Next Paint) ist jetzt gleichwertiges Ranking-Signal neben LCP und CLS
  • Sites, die zuvor knapp durchkamen, sind seither in der gelben oder roten Zone

Eine wichtige Klarstellung: FID gibt es nicht mehr. Google hat First Input Delay bereits im März 2024 durch INP ersetzt. Wenn ein Artikel oder Tool 2026 noch von FID spricht, ist er veraltet.

Was Performance konkret bringt, ist seit Jahren belegt — die Klassiker:

  • Amazon hat berechnet, dass 100 ms zusätzliche Ladezeit ungefähr 1 % Umsatz kosten (interne Amazon-Studie, oft zitiert)
  • Walmart meldete: jede Sekunde schnellere Ladezeit = rund 2 % mehr Conversions
  • Eine Portent-Studie zeigt: Eine Seite, die in 1 s lädt, hat eine Conversion-Rate von 3,05 % — eine 6-Sekunden-Seite kommt auf 1,08 %

Du musst nicht alle Maxime der großen Studien glauben. Aber die Richtung ist eindeutig: schneller bedeutet messbar mehr Conversions, weniger Bounce-Rate und besseres Ranking.

Die drei größten Performance-Killer

1. Render-Blocking CSS

Das Problem: Der Browser lädt deine style.css (oft 50–200 KB) komplett, bevor er irgendetwas anzeigen kann. Bei langsamer Verbindung können das schnell 500–1.000 ms weiße Seite sein.

Die Lösung: Critical CSS inline + Rest asynchron laden.

Schritt 1: Critical CSS extrahieren

Nur das CSS, das für „above the fold“ (sichtbarer Bereich beim ersten Aufruf) nötig ist:

  • Navigation
  • Hero-Section
  • Erste 600–800 px Viewport-Höhe

Das lässt sich entweder manuell extrahieren oder über Tools wie Critical von Addy Osmani automatisieren.

Schritt 2: CSS inline im <head>

<head>
    <style>
        /* Critical CSS hier (~2-5 KB) */
        .nav { /* Navigation Styles */ }
        .hero { /* Hero Styles */ }
    </style>
</head>

Ergebnis: Navigation und Hero rendern sofort — ohne Warten auf eine externe Datei.

Schritt 3: Restliches CSS asynchron laden

<link rel="preload" href="style.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="style.css"></noscript>

Was passiert: style.css wird im Hintergrund geladen, ohne den Render zu blockieren. Der <noscript>-Fallback sorgt dafür, dass auch ohne JavaScript alles funktioniert.

2. Font-Loading

Das Problem: Externe Fonts blockieren entweder den Render oder verursachen FOIT (Flash of Invisible Text) bzw. FOUT (Flash of Unstyled Text).

Die Lösung: Self-Hosted Fonts + Preload + passendes font-display.

Schritt 1: Fonts lokal ausliefern

Keine Google-Fonts-CDN, keine Adobe-Typekit-Server. Das hat zwei Vorteile: keine externe Verbindung (= keine Latenz) und keine DSGVO-Probleme.

@font-face {
    font-family: 'Manrope';
    src: url('/fonts/manrope-v20-latin-regular.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: optional;
}

Schritt 2: Kritische Fonts preloaden

<link rel="preload" href="/fonts/manrope-regular.woff2"
      as="font" type="font/woff2" crossorigin>

Nur zwei bis drei Fonts preloaden, nicht alle Varianten. Sonst kannibalisiert sich der Effekt selbst.

Schritt 3: Das richtige font-display wählen

Hier eine Lektion aus eigener Erfahrung: font-display: swap ist die häufigste Empfehlung, hat aber einen Nachteil. Beim Tausch vom Fallback- zum Custom-Font kann ein Cumulative Layout Shift entstehen, wenn die beiden Schriften unterschiedlich breit sind. Das kann den CLS-Wert massiv verschlechtern.

Alternativen, je nach Anwendungsfall:

  • swap: Zeigt sofort Fallback-Font, tauscht später zum Custom Font. Riskant für CLS.
  • optional: Browser entscheidet, ob er den Custom Font überhaupt nutzt. Wenn die Verbindung langsam ist, bleibt der Fallback. Beste Wahl, wenn CLS Priorität hat.
  • fallback: Kurzer Block-Phase (100 ms), dann Fallback, dann Tausch wenn schnell genug. Mittelweg.

Für Sites, bei denen CLS unter Druck steht, ist optional oft die bessere Wahl — auch wenn das heißt, dass manche Besucher den Fallback-Font sehen.

3. JavaScript-Bloat

Das Problem: Moderne Websites laden oft 500 KB+ JavaScript — auch für simple Landing Pages.

Die Lösung: defer, async, Framework-Wahl überdenken.

defer für alle nicht-kritischen Scripts

<script src="script.js" defer></script>

defer: Script lädt parallel zum HTML-Parsing, führt aber erst nach DOM-Aufbau aus. Reihenfolge bleibt erhalten.

Kein Framework für statische Inhalte

React, Vue oder Next.js für eine reine Portfolio-Site oder einen Onepager? Meist Overkill. Vanilla JS oder Alpine.js (~15 KB minified) reichen für 90 % der Use Cases im KMU-Bereich.

Code-Splitting für größere Apps

Wenn du tatsächlich eine React-/Vue-App baust: Lade nur das JS, das auf der aktuellen Seite gebraucht wird.

// Dynamic Import für schwere Features
const module = await import('./heavy-feature.js');

Die Quick-Wins-Checkliste

Diese Optimierungen dauern zusammen unter zwei Stunden und bringen meistens spürbare Verbesserungen:

  1. Bilder zu WebP konvertieren — meist 30–70 % kleinere Dateigröße bei vergleichbarer Qualität
  2. Lazy Loading aktivieren — <img loading="lazy"> für alle Bilder unter dem Fold
  3. Favicon aufräumen — ein PNG-Favicon plus optional ein Apple-Touch-Icon reicht meist
  4. Gzip/Brotli-Kompression — serverseitig aktivieren (bei Manitu, ALL-INKL und IONOS standardmäßig dabei)
  5. Browser-Caching — lange Cache-Headers (z. B. 1 Jahr) für statische Assets
  6. Ungenutztes CSS entfernen — Tools wie PurgeCSS oder UnCSS
  7. Bilder mit korrekten width/height-Attributen — verhindert Layout-Shifts (CLS)

Testing und Monitoring

PageSpeed-Score ist nur ein Indikator. Was zählt, sind die echten Werte deiner echten Besucher. Die Tools, die ich nutze:

  • PageSpeed Insights — Googles offizielles Tool, zeigt sowohl Lab- als auch Field-Daten (CrUX)
  • WebPageTest — detaillierte Waterfall-Analyse, gut zum Verstehen von Ladereihenfolgen
  • Chrome DevTools — Lighthouse + Performance-Tab für lokale Tests
  • Google Search Console — Core-Web-Vitals-Report mit echten Nutzerdaten

Wichtiger Hinweis: Optimiere nicht nur für PageSpeed Insights. Ein 100er-Score mit synthetischen Tests bedeutet wenig, wenn deine echten Nutzer auf einem alten Smartphone und 4G drei Sekunden warten. Die Field-Daten aus der Search Console sind realistischer.

Häufige Fragen

Wie lange dauert die Optimierung?

Für eine typische KMU-Site: ein bis zwei Tage für 90+ Score. Die letzten Punkte bis 100 sind Feinschliff und können nochmal ein bis zwei Tage dauern — mit immer kleinerem Ertrag pro Stunde Aufwand.

Muss ich alle Optimierungen umsetzen?

Nein. Fang mit den Quick Wins und Critical CSS an. Das bringt 80 % der Verbesserung in 20 % der Zeit. Die letzten 5–10 Punkte sind oft nicht den Aufwand wert — außer du brauchst sie aus SEO-Gründen in einem stark umkämpften Markt.

Funktioniert das auch mit WordPress?

Teilweise. Critical CSS und Font-Optimization gehen, aber Standard-WordPress-Setups mit Theme und Plugin-Stack schaffen die neuen Schwellenwerte selten. Realistisch sind 85–95 mit ordentlichem Hosting, leichtem Theme und Performance-Plugin (WP Rocket, NitroPack). 100 ist mit WordPress sehr schwer.

Welche Tools brauchst du?

Keine teuren Tools nötig. Chrome DevTools, PageSpeed Insights und ein Code-Editor reichen. Für Bildoptimierung empfehle ich Squoosh (kostenlos, im Browser).