PageSpeed Insights über 90: 12 Hebel die wirklich messbar wirken
Performance 7 Min. Lesezeit

PageSpeed Insights über 90: 12 Hebel die wirklich messbar wirken

Konkrete PageSpeed-Optimierungen mit nachweisbarer Wirkung: Bildoptimierung, Font Loading, Code Splitting, Caching-Header, CDN, Third-Party-Scripts — von technisch bis konfigurativ.

Arnold Wender

Arnold Wender

Webdesigner & Geschaeftsfuehrer

Inhaltsverzeichnis

PageSpeed Insights >90 ist kein Selbstzweck — aber es ist ein guter Proxy für eine schnelle, nutzungsfreundliche Website. Wer 90+ erreicht, hat die meisten Performance-Probleme gelöst, die auch echte Nutzer betreffen.

Dieser Artikel listet die 12 Maßnahmen, die in der Praxis messbar wirken — nicht theoretische Empfehlungen, sondern Eingriffe mit bekanntem Effektgröße.

Vorab: Labor- vs. Felddaten

PageSpeed Insights zeigt zwei Datensätze:

  1. Felddaten (CrUX): Echte Nutzer-Messungen der letzten 28 Tage. Das ist, was Google für Rankings verwendet.
  2. Labordaten (Lighthouse): Simulierter Test auf Googles Servern mit gedrosseltem Netz und CPU.

Ein Lighthouse-Score von 95 bei schlechten CrUX-Werten bedeutet: Das Problem liegt bei Ihren echten Nutzern, nicht im Test. Häufige Ursache: Third-Party-Skripte die im Test nicht feuern (Chat-Widgets, CMP, A/B-Tests).

Ziel: Beide Datensätze im grünen Bereich.

Die 12 wirksamsten Hebel

Hebel 1: Hero-Bild korrekt ausliefern

Das LCP-Element ist fast immer das Hero-Bild. Drei Fehler häufen sich:

<!-- Falsch: kein fetchpriority, lazy statt eager -->
<img src="/hero.png" loading="lazy" />

<!-- Richtig: sofort laden, höchste Priorität -->
<img
  src="/hero.webp"
  loading="eager"
  fetchpriority="high"
  decoding="async"
  width="1200"
  height="630"
  alt="Webdesigner Sachsen Hero"
/>

Erwarteter Effekt auf LCP: -0,5 bis -1,5 Sekunden. Dieser einzelne Fix ist oft der größte LCP-Gewinn.

Hebel 2: WebP/AVIF konvertieren

Bilder sind typischerweise 50–70% der übertragenen Bytes. Format-Umstellung:

FormatGrößen-Reduktion vs. JPEG
WebP25–35% kleiner
AVIF40–55% kleiner

Tool-Chain für Batch-Konvertierung:

# Alle JPEGs in WebP und AVIF konvertieren (sharp CLI)
npx sharp-cli --input "public/images/**/*.jpg" --output "public/images/" --format webp
npx sharp-cli --input "public/images/**/*.jpg" --output "public/images/" --format avif

Für Astro: die <Image>-Komponente aus astro:assets wandelt automatisch in optimale Formate um.

Hebel 3: Responsive Images mit srcset

<img
  src="/images/hero-400.webp"
  srcset="
    /images/hero-400.webp 400w,
    /images/hero-800.webp 800w,
    /images/hero-1200.webp 1200w
  "
  sizes="(max-width: 768px) 100vw, 1200px"
  loading="eager"
  fetchpriority="high"
  alt="..."
/>

Mobil-Nutzer laden so die 400px-Version statt die 1200px-Version — 70% kleiner.

Hebel 4: Webfont-Loading-Strategie

<!-- Preload kritische Schriften -->
<link
  rel="preload"
  href="/fonts/inter-var.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap; /* Sofort Fallback zeigen, dann wechseln */
  font-weight: 100 900;
}

Was font-display-Werte bedeuten:

  • swap: Fallback sofort, dann wechseln → minimaler FOUT, kein FOIT
  • optional: Lädt nur wenn bereits im Cache → kein Layout Shift, aber Schrift fehlt ggf.
  • block: Browser wartet → FOIT bis zu 3 Sekunden → schlecht für LCP

Für die meisten KMU-Websites: font-display: swap mit vorgeladener Schrift.

Hebel 5: CSS Critical Path

CSS blockiert das Rendering. Die Lösung: kritisches CSS inline laden, restliches CSS asynchron:

<head>
  <!-- Kritisches CSS inline (Above-the-fold, max 5KB) -->
  <style>
    /* Hero, Nav, erste Sektion */
    .nav { ... }
    .hero { ... }
  </style>
  
  <!-- Restliches CSS nicht-blockierend laden -->
  <link rel="preload" href="/styles/main.css" as="style" onload="this.rel='stylesheet'" />
  <noscript><link rel="stylesheet" href="/styles/main.css" /></noscript>
</head>

Astro macht das automatisch mit inlineStylesheets: 'auto' in astro.config.mjs.

Hebel 6: Caching-Header für statische Assets

# netlify.toml
[[headers]]
  for = "/images/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

[[headers]]
  for = "/fonts/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

[[headers]]
  for = "/_astro/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

Erwarteter Effekt: -0,3 bis -0,8 Sekunden bei Wiederholungsbesuchen. Für First-Visit kein direkter Effekt, aber wichtig für Real User Monitoring.

Hebel 7: Third-Party-Skripte async/defer

<!-- Schlecht: synchron, blockiert Parsing -->
<script src="https://www.googletagmanager.com/gtm.js"></script>

<!-- Gut: async -->
<script async src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>

<!-- Besser für INP: nach Nutzer-Interaktion laden (Tag-Manager Delayed Init) -->
<script>
  window.addEventListener('click', function loadGTM() {
    window.removeEventListener('click', loadGTM);
    const s = document.createElement('script');
    s.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXX';
    document.head.appendChild(s);
  }, { once: true });
</script>

Erwarteter Effekt auf INP: -50 bis -150ms je nach Anzahl Third-Party-Skripte.

Hebel 8: Render-blockierende Ressourcen eliminieren

Lighthouse zeigt „Render-blocking resources” als Diagnose. Häufige Ursachen:

  • Synchrones CSS von externen CDNs (Google Fonts, Font Awesome)
  • Plugins die CSS im <head> injizieren (WordPress)
  • Analytics-Skripte ohne async

Für WordPress: WP Rocket → „Render-Blocking CSS/JS eliminieren” aktivieren, dann selektiv durch Perfmatters deaktivieren wo Konflikte auftreten.

Hebel 9: Layout Shift durch Bildabmessungen verhindern

<!-- Immer width + height angeben — Browser reserviert Platz -->
<img
  src="/images/team-photo.webp"
  width="600"
  height="400"
  alt="Team Wender Media"
/>

Für CSS aspect-ratio als modernere Alternative:

.hero-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Hebel 10: JavaScript Code Splitting

Bei modernen Framework-Projekten: nur den Code laden, der auf der aktuellen Seite gebraucht wird.

Für Astro: automatisch via client:idle und client:visible Islands:

<!-- Lädt nur wenn Nutzer scrollt und Element sichtbar wird -->
<ContactForm client:visible />

<!-- Lädt nach Browser-Idle — nicht für above-the-fold -->
<Newsletter client:idle />

Für React/Next.js: React.lazy() + Suspense für page-level code splitting.

Hebel 11: CDN und globale Verteilung

Netlify und Vercel haben automatisches CDN. Für selbst gehostetes WordPress:

# nginx Caching für statische Dateien
location ~* \.(jpg|jpeg|png|gif|webp|avif|ico|css|js|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Erwarteter Effekt auf TTFB: -100 bis -300ms je nach geografischer Entfernung.

Hebel 12: Preconnect für externe Ressourcen

<!-- DNS-Lookup + TCP-Verbindung vorab aufbauen -->
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="dns-prefetch" href="https://www.googletagmanager.com" />

Für jede externe Domain die Ressourcen liefert: preconnect (wenn kritisch) oder dns-prefetch (wenn non-critical).

Messung und Iteration

Nach jeder Maßnahme messen:

# Lighthouse CLI für konsistente Messungen
npx lighthouse https://ihre-domain.de \
  --only-categories=performance \
  --form-factor=mobile \
  --throttling-method=applied \
  --output=json \
  --output-path=./lighthouse-report.json

Wichtig: Lighthouse-Scores variieren zwischen Läufen bis zu ±5 Punkte. Mindestens 3 Messungen machen und den Median nehmen.

Für eine systematische Performanceprüfung Ihrer Website: unser SEO-Audit-Tool gibt eine erste Einschätzung ohne Tool-Installation. Die Detailanalyse mit Lighthouse und Chrome DevTools führen wir im Rahmen unserer Performance-Optimierungsleistungen durch.

Typische Ergebnisse nach Optimierung

Aus unserer Erfahrung mit KMU-Projekten in Sachsen:

AusgangssituationNach Optimierung
WordPress ohne Caching: LCP 4–6sWordPress mit WP Rocket + Optimierungen: LCP 2–2,5s
Astro ohne Bildoptimierung: LCP 2,5–3sAstro mit WebP + Preload: LCP 0,8–1,3s
PageSpeed-Score 40–60PageSpeed-Score 85–98

Core Web Vitals verbessern sich in der Regel deutlich — besonders LCP reagiert stark auf die Bildoptimierungs-Maßnahmen (Hebel 1-3).

Fazit: Systematisch statt zufällig

PageSpeed-Optimierung ist kein einmaliger Sprint, sondern ein kontinuierlicher Prozess. Die 12 Hebel in diesem Artikel decken 80% der häufigsten Probleme ab. Die restlichen 20% liegen in projekt-spezifischen Besonderheiten — dafür hilft Chrome DevTools Performance Panel und echtes User Monitoring.

Weiterlesen: Core Web Vitals 2026: LCP, INP und CLS für die theoretische Grundlage der Metriken.

Schlagworte

#PageSpeed #Core Web Vitals #Performance #LCP #Optimierung #Lighthouse
Arnold Wender, SEO-Experte

Webdesigner & Geschaeftsfuehrer

Arnold Wender ist Gruender und Inhaber von Wender Media. Er entwickelt seit 2007 professionelle Websites fuer Unternehmen in Sachsen und Sachsen-Anhalt.

Profil anzeigen