PageSpeed & Performance

PageSpeed Performance Checkliste: Schritt-für-Schritt-Härtung

Eine schnelle Ladezeit ist das Fundament einer erfolgreichen Webpräsenz. Sie entscheidet über Benutzerakzeptanz, Konversionsraten und die Platzierung in den Google-Suchergebnissen. Nutzen Sie diese Performance-Checkliste, um die Ladegeschwindigkeit und die Core Web Vitals Ihrer Website Schritt für Schritt zu analysieren und systematisch zu optimieren.

Bevor Sie eine einzige Massnahme umsetzen, sollten Sie den Ist-Zustand messen – sonst optimieren Sie blind. Erst eine Messung zeigt, ob Ihr Engpass beim TTFB, beim LCP oder bei der Interaktivität liegt. Arbeiten Sie die Checkliste anschliessend in der Reihenfolge des grössten Hebels ab.

1. Bilder & Medien

Bilder machen oft den grössten Teil der Seitengrösse aus und blockieren den LCP (Largest Contentful Paint).

  • Moderne Formate: Werden Bilder ausschliesslich in AVIF oder WebP ausgeliefert?
  • Skalierung: Sind die Bilder auf die tatsächliche Darstellungsgrösse herunterskaliert (keine Kamera-Originale)?
  • Sicherstellen der Layoutstabilität (CLS): Haben alle <img>-Tags feste width und height Attribute?
  • Lazy Loading: Ist loading="lazy" für alle Bilder ausserhalb des sichtbaren Bereichs (Below the Fold) aktiv?
  • Kein Lazy-Loading im Header: Werden Logo und Hero-Bilder im sichtbaren Bereich (Above the Fold) direkt geladen (loading="eager" oder preloading)?

2. Server & Netzwerk (Latenz)

Eine geringe Server-Reaktionszeit (TTFB) beschleunigt den gesamten Ladevorgang.

  • Caching: Ist ein aggressives serverseitiges Caching (Page Caching) und Object Caching aktiv?
  • Browser-Caching: Senden Server den Cache-Control-Header mit einer max-age von 1 Jahr (31536000) für statische Assets?
  • Komprimierung: Ist die Inhaltskomprimierung via Brotli (oder Gzip als Fallback) auf dem Webserver aktiv?
  • Protokolle: Werden moderne Übertragungsprotokolle wie HTTP/2 oder HTTP/3 unterstützt?
  • CDN-Einsatz: Werden globale Assets über ein Content Delivery Network (CDN) geografisch nah am Nutzer ausgeliefert?

3. CSS & Stylesheets

Stylesheets blockieren standardmässig das Rendern der Seite.

  • Critical CSS: Ist das kritische CSS für den sichtbaren Bereich inline im HTML eingebettet?
  • Asynchrones Laden: Werden nicht-kritische CSS-Dateien asynchron geladen?
  • Minifizierung: Sind alle CSS-Dateien minifiziert (ohne Kommentare und Leerzeichen)?
  • Imports vermeiden: Wurde auf die verlangsamende @import-Anweisung in CSS-Dateien verzichtet?

4. JavaScript & Interaktivität

JavaScript belastet die CPU und blockiert den Haupt-Thread (INP).

  • Script-Attribute: Werden externe Skripte mit defer (App-Skripte) oder async (Analytics-Skripte) geladen?
  • Minifizierung: Ist der JS-Code vollständig minifiziert und komprimiert?
  • Ungenutztes JS entfernen: Werden ungenutzte Bibliotheken über Tree-Shaking und Code-Splitting aussortiert?
  • No-Code-Ansatz: Werden statische Seiten (wie in Astro 6) standardmässig mit 0 KB Client-seitigem JS ausgeliefert?

5. Schriftarten (Fonts)

Schriftarten verzögern die Textdarstellung und führen zu FOUT/FOIT.

  • Lokales Hosten: Werden Schriftarten datenschutzkonform lokal im schnellen WOFF2-Format gehostet (keine CDN-Google-Fonts)?
  • font-display swap: Ist font-display: swap; in den @font-face Definitionen deklariert?
  • Preloading: Werden die primären Schriftschnitte im HTML-Header preloaded?

Priorisierung nach Aufwand und Wirkung

Nicht jede Massnahme lohnt sich gleichermassen. Die folgende Tabelle hilft, die Reihenfolge nach dem Verhältnis von Aufwand zu Wirkung zu bestimmen:

MassnahmeWirkungAufwandBetroffene Metrik
Bilder zu WebP/AVIFsehr hochgeringLCP, CLS
Server-Caching / niedrigere TTFBsehr hochmittelTTFB, LCP
Render-blockierendes CSS auflösenhochmittelLCP, FCP
Ungenutztes JavaScript entfernenhochmittel–hochINP, TBT
Schriftarten lokal + font-displaymittelgeringCLS, FCP
Brotli-Komprimierung aktivierenmittelgeringTransfergrösse

Die ersten beiden Zeilen liefern bei den meisten Websites bereits den Grossteil der Verbesserung. Erst danach lohnen sich die feineren Eingriffe bei CSS, JavaScript und Schriftarten.


Praxisbeispiel: Vorher/Nachher einer Optimierung

Ein mittelständischer Online-Shop arbeitet die Checkliste systematisch ab. Die Core Web Vitals entwickeln sich dabei wie folgt:

MetrikVorherNachherMassnahme
LCP4,8 s2,1 sHero-Bild als AVIF + fetchpriority="high"
TTFB850 ms180 msserverseitiges Page-Caching aktiviert
CLS0,280,02feste width/height an allen Bildern
Lighthouse-Score4794Summe aller Massnahmen

Entscheidend war die Reihenfolge: Zuerst wurde das grösste Bild (LCP-Element) optimiert und das Caching aktiviert, was den grössten Sprung brachte. Die Layout-Stabilisierung (CLS) und die JavaScript-Entschlackung folgten als Feinschliff. Nach drei Wochen bestätigten die Felddaten in der Search Console den Erfolg auch für echte Nutzer.

[!TIP] Ein strukturiertes Abarbeiten dieser Checkliste führt in den meisten Fällen direkt zu einem grünen Scoring bei den Core Web Vitals. Testen Sie die Leistung Ihrer Website live mit dem PageSpeed Check auf balou.tools.

Häufig gestellte Fragen (FAQ)

Welche Einzelmassnahme bringt den grössten Geschwindigkeits-Vorteil?

Für die meisten Websites ist die Bildkomprimierung (Wechsel zu WebP/AVIF) und die Aktivierung von serverseitigem Caching (Senkung der TTFB) der wirksamste Hebel.

Warum schadet ein schlechter PageSpeed dem Google-Ranking?

Google möchte seinen Nutzern die besten Suchergebnisse liefern. Da langsame Ladezeiten zu Frustration und hohen Absprungraten führen, stuft Google langsame Seiten in den Rankings ab.

In welcher Reihenfolge sollte ich die Checkliste abarbeiten?

Beginnen Sie immer mit einer Messung, um Engpässe zu kennen. Priorisieren Sie danach nach Aufwand-Nutzen-Verhältnis: zuerst Server-Antwortzeit (TTFB) und Bildoptimierung, dann render-blockierendes CSS/JS, zuletzt Feinheiten bei Schriftarten. So erzielen Sie mit wenigen Eingriffen den grössten Sprung bei den Core Web Vitals.

Reicht ein gutes Ergebnis im Labortest aus?

Nein. Ein guter Labor-Score ist nur ein Zwischenziel. Entscheidend für das Ranking sind die Felddaten echter Nutzer aus dem Chrome User Experience Report. Validieren Sie jede Optimierung deshalb nach einigen Wochen erneut anhand der Felddaten in der Search Console.