Zum Hauptinhalt springen
H
HESSENKAMP MEDIA
Performance PageSpeed Optimierung Tutorial Core Web Vitals

100/100 PageSpeed Score erreichen: Komplette Anleitung für schnellere Websites

Jascha Hessenkamp
15 Min. Lesezeit
100/100 PageSpeed Score erreichen: Komplette Anleitung für schnellere Websites

Ihre Website ist langsam? Das kostet Sie bares Geld. Studien zeigen: 40% der Besucher verlassen Websites, die länger als 3 Sekunden laden. Jede Sekunde Ladezeit reduziert Ihre Conversion-Rate um durchschnittlich 7%.

Dieser Leitfaden zeigt Ihnen Schritt für Schritt, wie Sie einen perfekten PageSpeed-Score erreichen – und dadurch mehr Umsatz generieren, bessere Google-Rankings erzielen und Ihre Besucher begeistern.

💰 Warum PageSpeed Ihrem Unternehmen direkt Geld bringt

Der Business Case für schnelle Websites

Echte Zahlen aus der Praxis:

Ladezeit-VerbesserungConversion-SteigerungUmsatz-Impact (bei 50.000€/Monat)
5s → 3s+20%+10.000€/Monat
3s → 2s+15%+7.500€/Monat
2s → 1s+10%+5.000€/Monat

Google-Ranking-Effekte:

  • Core Web Vitals sind seit 2021 Ranking-Faktor
  • Schnellere Websites ranken im Schnitt 3-5 Plätze höher
  • Mobile PageSpeed hat noch stärkere Auswirkung (Mobile-First Indexing)

Praxisbeispiel Hannover:
Ein lokales E-Commerce-Unternehmen steigerte durch PageSpeed-Optimierung (von 45 auf 98 Punkte) die Conversion-Rate von 1,8% auf 2,4% – das entspricht einem Umsatz-Plus von 23.000€ pro Monat.

📊 Core Web Vitals verstehen: Die 3 kritischen Google-Metriken

Google nutzt drei Kern-Metriken als direkte Ranking-Faktoren:

1. Largest Contentful Paint (LCP)

Ziel: < 2,5 Sekunden
Misst: Wann das größte sichtbare Element geladen ist

Typische LCP-Elemente:

  • Hero-Images (Startseiten-Banner)
  • Video-Thumbnails
  • Große Textblöcke in der Hauptspalte

Business-Impact: Bestimmt den ersten Eindruck – kritisch für Absprungrate!

2. First Input Delay (FID) / Interaction to Next Paint (INP)

Ziel: < 100ms (FID) / < 200ms (INP)
Misst: Reaktionszeit auf erste Nutzer-Interaktion

Beispiele:

  • Klick auf „Jetzt kaufen”-Button
  • Öffnen eines Menüs
  • Eingabe in ein Formular

Business-Impact: Frustrierte Nutzer = verlorene Kunden

3. Cumulative Layout Shift (CLS)

Ziel: < 0,1
Misst: Visuelle Stabilität (unerwartete Layout-Verschiebungen)

Klassischer Fehler:
Sie wollen auf einen Button klicken, aber ein nachladendes Bild verschiebt ihn - extrem frustrierend!

Business-Impact: Schlechte User Experience = schlechtere Conversion

🚀 Die 7 kritischen Optimierungen (nach Impact sortiert)

1. Bildoptimierung (70% Impact!) 📸

Bilder sind in 80% der Fälle der größte Performance-Killer.

Modern Formats nutzen (AVIF/WebP):

<picture>
  <!-- Moderne Browser: AVIF (70% kleiner als JPG!) -->
  <source type="image/avif" 
    srcset="hero-320.avif 320w, hero-1280.avif 1280w" 
    sizes="(max-width: 768px) 100vw, 1280px" />
  
  <!-- Fallback: WebP (30% kleiner als JPG) -->
  <source type="image/webp" 
    srcset="hero-320.webp 320w, hero-1280.webp 1280w" />
  
  <!-- Fallback für alte Browser -->
  <img src="hero.jpg" width="1280" height="600" 
       loading="lazy" alt="Hero Image" />
</picture>

Automatisierung mit Sharp (Node.js):

const sharp = require('sharp');

async function optimizeImage(inputPath, outputPath) {
  await sharp(inputPath)
    .resize(1280, null, { withoutEnlargement: true })
    .avif({ quality: 75 })
    .toFile(outputPath);
    
  console.log(`Gespeichert: ${outputPath}`);
}

// Batch-Verarbeitung aller Bilder
optimizeImage('hero.jpg', 'hero.avif');

Lazy Loading richtig einsetzen:

  • Above the fold (sofort sichtbar): loading="eager" oder fetchpriority="high"
  • Below the fold: loading="lazy"
  • LCP-Image: ZUSÄTZLICH preloaden!
<head>
  <!-- LCP-Bild vorab laden (kritisch!) -->
  <link rel="preload" href="/hero.avif" as="image" 
        type="image/avif" fetchpriority="high" />
</head>

Checkliste Bildoptimierung:

  • Alle Bilder < 100 KB (Desktop) / < 50 KB (Mobile)
  • AVIF + WebP + JPG Fallback
  • Width/Height-Attribute gesetzt (verhindert CLS!)
  • Lazy Loading aktiviert (außer LCP-Bild)
  • Responsive Sizes definiert

2. JavaScript minimieren (20% Impact) ⚡

Zu viel oder schlecht optimiertes JavaScript blockiert das Rendering.

Code Splitting:

// ❌ FALSCH: Alles auf einmal laden
import HeavyChart from './HeavyChart';
import VideoPlayer from './VideoPlayer';

// ✅ RICHTIG: Nur laden, wenn benötigt
const HeavyChart = lazy(() => import('./HeavyChart'));
const VideoPlayer = lazy(() => import('./VideoPlayer'));

Tree Shaking (Bundle-Größe reduzieren):

// ❌ FALSCH: Gesamte Lodash-Bibliothek (71 KB!)
import _ from 'lodash';
const result = _.debounce(fn, 300);

// ✅ RICHTIG: Nur die benötigte Funktion (2 KB)
import debounce from 'lodash/debounce';
const result = debounce(fn, 300);

Bundle Analyzer nutzen:

# Next.js
npm install @next/bundle-analyzer
ANALYZE=true npm run build

# Vite
npm install rollup-plugin-visualizer

Ergebnis: Sehen Sie genau, was Ihr Bundle so groß macht!

3. Critical CSS inline laden (10% Impact) 🎨

Externe CSS-Dateien blockieren das Rendering. Die Lösung: Critical CSS inline im <head>.

Was ist Critical CSS?
Nur die Styles, die für den above-the-fold-Bereich nötig sind.

<head>
  <!-- Critical CSS direkt inline -->
  <style>
    /* Nur Styles für alles, was sofort sichtbar ist */
    body { 
      margin: 0; 
      font-family: 'Inter', sans-serif; 
      background: #fff;
    }
    .hero { 
      min-height: 100vh; 
      display: flex;
      align-items: center;
    }
    header { 
      position: fixed; 
      top: 0; 
      width: 100%;
    }
  </style>
  
  <!-- Rest der Styles asynchron laden -->
  <link rel="preload" href="/styles.css" as="style" 
        onload="this.rel='stylesheet'" />
  <noscript><link rel="stylesheet" href="/styles.css"></noscript>
</head>

Tools zur Extraktion:

4. Font Optimization (5% Impact) 🔤

Web Fonts können das Rendering massiv verzögern.

Best Practice:

<head>
  <!-- 1. Preconnect zu Font-Server -->
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
  
  <!-- 2. Font-Datei preloaden -->
  <link rel="preload" href="/fonts/inter-var.woff2" 
        as="font" type="font/woff2" crossorigin />
  
  <!-- 3. Font-Face mit font-display: swap -->
  <style>
    @font-face {
      font-family: 'Inter';
      src: url('/fonts/inter-var.woff2') format('woff2');
      font-display: swap; /* KRITISCH! Zeigt Fallback-Font sofort */
      font-weight: 100 900; /* Variable Font */
    }
  </style>
</head>

font-display Optionen:

  • swap: Empfohlen! Zeigt Fallback sofort, tauscht dann Font aus
  • optional: Nutzt Font nur, wenn er schnell genug lädt
  • block: ❌ Wartet auf Font – schlecht für Performance!

Variable Fonts nutzen:
Eine Variable-Font-Datei ersetzt 10+ einzelne Font-Dateien (Light, Regular, Bold, etc.)

5. Third-Party Scripts verzögern (3% Impact) 📦

Analytics, Chat-Widgets, Social-Media-Buttons – alles verzögert Ihre Website.

Delayed Loading Pattern:

let scriptsLoaded = false;

// Erst nach User-Interaktion laden
['click', 'scroll', 'mousemove'].forEach(event => {
  window.addEventListener(event, () => {
    if (!scriptsLoaded) {
      loadThirdPartyScripts();
      scriptsLoaded = true;
    }
  }, { once: true });
});

function loadThirdPartyScripts() {
  // Analytics
  const analyticsScript = document.createElement('script');
  analyticsScript.src = 'https://analytics.example.com/script.js';
  analyticsScript.defer = true;
  document.head.appendChild(analyticsScript);
  
  // Chat-Widget
  const chatScript = document.createElement('script');
  chatScript.src = 'https://chat.example.com/widget.js';
  chatScript.defer = true;
  document.head.appendChild(chatScript);
}

Resultat: Initiale Ladezeit massiv verbessert, Scripts laden trotzdem!

6. Server Response Time optimieren (2% Impact) 🖥️

Ziel: Time To First Byte (TTFB) < 200ms

Maßnahmen:

  • Static Site Generation nutzen (Astro, Next.js, etc.)
  • CDN aktivieren (Cloudflare, Vercel Edge, CloudFront)
  • Brotli Compression statt Gzip (20% kleiner!)
  • HTTP/2 oder HTTP/3 aktivieren

CDN-Effekt:
Statt von einem Server in Frankfurt auszuliefern, liefert das CDN von 50+ weltweiten Standorten aus → User in Hamburg bekommt Daten aus Hamburg!

7. Layout Shift Prevention (ult. Wichtig für CLS!) 📐

Die Regel: Reservieren Sie immer den Platz für nachladende Inhalte!

<!-- ✅ RICHTIG: Width & Height angeben -->
<img src="/product.jpg" width="800" height="600" 
     alt="Produktbild" loading="lazy" />

<!-- ✅ RICHTIG: Aspect Ratio für iFrame -->
<div style="aspect-ratio: 16/9; position: relative;">
  <iframe src="https://youtube.com/embed/..." 
          style="position: absolute; width: 100%; height: 100%;">
  </iframe>
</div>

<!-- ✅ RICHTIG: Platzhalter für Ads -->
<div style="min-height: 250px; background: #f0f0f0;">
  <!-- Ad lädt hier rein -->
</div>

✅ Pre-Launch Checkliste

Bevor Sie Ihre optimierte Website live schalten:

Bilder

  • Alle Bilder < 100 KB (Desktop) / < 50 KB (Mobile)
  • AVIF/WebP mit JPG-Fallback
  • Lazy Loading für alle Bilder außer LCP
  • LCP-Bild mit rel="preload" geladen
  • Width/Height-Attribute gesetzt

JavaScript

  • Bundle-Größe < 200 KB (gzip)
  • Code Splitting aktiviert
  • Third-Party-Scripts verzögert geladen
  • Keine Render-Blocking Scripts

CSS

  • Critical CSS inline (< 15 KB)
  • Unused CSS entfernt
  • CSS-Bundle < 50 KB

Fonts

  • Fonts preloaded
  • font-display: swap gesetzt
  • Variable Fonts statt viele einzelne Dateien

Server

  • CDN aktiviert
  • Brotli/Gzip Compression enabled
  • TTFB < 200ms
  • HTTP/2 oder HTTP/3

🔧 Debugging: Häufige PageSpeed-Probleme lösen

Problem: “Reduce unused JavaScript”

Diagnose:

# Bundle analysieren
npx source-map-explorer build/**/*.js

Lösungen:

  • Große Dependencies ersetzen (z.B. Moment.js → date-fns)
  • Lazy Loading für nicht-kritische Components
  • Tree Shaking prüfen

Problem: “Eliminate render-blocking resources”

Lösung:

<!-- CSS async laden -->
<link rel="preload" href="/styles.css" as="style" 
      onload="this.rel='stylesheet'" />

<!-- JavaScript defer -->
<script defer src="/app.js"></script>

Problem: “Properly size images”

Lösung: Responsive Images:

<img srcset="small.jpg 320w, 
             medium.jpg 768w, 
             large.jpg 1280w" 
     sizes="(max-width: 768px) 100vw, 50vw"
     src="medium.jpg" alt="..." />

🤖 Automation: PageSpeed kontinuierlich überwachen

Lighthouse CI in GitHub Actions:

# .github/workflows/lighthouse.yml
name: Lighthouse Performance Check
on: [push, pull_request]

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v9
        with:
          urls: |
            https://ihredomain.de
            https://ihredomain.de/leistungen
            https://ihredomain.de/kontakt
          budgetPath: ./lighthouse-budget.json
          uploadArtifacts: true

Performance Budget definieren:

{
  "path": "/*",
  "timings": [
    {
      "metric": "interactive",
      "budget": 3000,
      "tolerance": 500
    },
    {
      "metric": "first-contentful-paint",
      "budget": 1500
    }
  ],
  "resourceSizes": [
    {
      "resourceType": "script",
      "budget": 200
    },
    {
      "resourceType": "image",
      "budget": 300
    },
    {
      "resourceType": "total",
      "budget": 800
    }
  ]
}

Ergebnis: Build schlägt fehl, wenn Performance-Budget überschritten wird!

📈 Real-World Beispiel: Diese Website

Ausgangssituation:

  • PageSpeed Score: 72/100
  • LCP: 3,8s
  • FID: 180ms
  • CLS: 0,24

Durchgeführte Optimierungen:

  1. Alle Bilder → AVIF/WebP (durchschn. 85% kleiner!)
  2. Contact Form → client:visible (Astro)
  3. Fonts → Preload + font-display: swap
  4. Critical CSS → Inline (12 KB)
  5. Vercel Edge CDN → TTFB von 580ms auf 95ms

Ergebnis nach Optimierung:

  • PageSpeed Score: 100/100 ✅
  • LCP: 0,9s ✅ (4x schneller!)
  • INP: 11ms ✅
  • CLS: 0,001 ✅
  • Conversion-Rate: +18% 🎉

💡 Fazit: Priorisierung nach ROI

Impact-Ranking:

  1. Bilder optimieren (70% Impact, 2-4h Aufwand)
  2. JavaScript reduzieren (20% Impact, 4-8h Aufwand)
  3. Critical CSS (5% Impact, 2h Aufwand)
  4. Fonts optimieren (3% Impact, 1h Aufwand)
  5. Third-Party verzögern (2% Impact, 1h Aufwand)

Realität: Ein PageSpeed-Score von 95+ ist oft wertvoller als 100, wenn es schneller erreicht wird. Google rankt nach Core Web Vitals, nicht nach dem Score!

Die wichtigste Metrik: Ihre Conversion-Rate und Umsatz. PageSpeed ist Mittel zum Zweck, nicht Selbstzweck.

🚀 Nächste Schritte

1. Kostenloser Performance-Check

Lassen Sie uns Ihre Website analysieren und konkrete Optimierungs-Potenziale identifizieren.

▶️ Jetzt kostenlosen PageSpeed-Check anfordern

2. Professionelle Optimierung

Sie möchten sich auf Ihr Kerngeschäft konzentrieren? Ich optimiere Ihre Website auf 95+ PageSpeed – mit Erfolgsgarantie.

📞 Performance-Optimierung anfragen

3. Weiterlesen

🚀 Bereit für 100/100 PageSpeed?

Haben Sie Fragen zur Website-Optimierung? Ich helfe Ihnen gerne – mit messbaren Ergebnissen und klarem ROI!

📞 Jetzt Performance-Optimierung anfragen

Artikel teilen:

Mehr Artikel