Page Speed: umfassende Optimierung der Ladezeit von Websites

Page Speed gehört zu den wirkungsstärksten Investitionen, weil sie SEO und Conversion gleichzeitig verbessert. Amazon hat errechnet, dass jede zusätzliche Verzögerung von 100 ms 1 % des Umsatzes kostet. Google bewertet die Geschwindigkeit seit 2010 als Rankingfaktor für Desktop-Suchen und seit 2018 für die mobile Suche. 2021 hat Google die Core Web Vitals als direktes Signal der Page Experience eingeführt.

zoom_in

Was ist Page Speed und wie wird sie gemessen

Page Speed ist keine einzelne Zahl, sondern eine Gruppe von Kennzahlen. Jede misst einen anderen Aspekt des Ladeerlebnisses. Das Tool PageSpeed Insights von Google kombiniert Labordaten (Lighthouse) mit Felddaten realer Nutzer aus dem Chrome User Experience Report. Die Gesamtpunktzahl von 0 bis 100 ist eine gewichtete Summe mehrerer Kennzahlen. Sie sollte nicht als einziges Optimierungsziel dienen.

Für SEO zählen die Felddaten (CrUX). Google bewertet die Core Web Vitals auf Basis des 75. Perzentils realer Chrome-Nutzer. Lighthouse hilft bei der Diagnose, ist aber kein direkter Eingangswert für den Ranking-Algorithmus.

Wichtige Geschwindigkeitskennzahlen

Jede Kennzahl betrifft einen bestimmten Aspekt der Nutzererfahrung. Die Unterschiede zu verstehen, ist die Grundlage für eine korrekte Diagnose.

Diagnose: wo Sie mit der Optimierung beginnen

Optimierung ohne Messung ist verschwendete Mühe. Die richtige Reihenfolge: zuerst messen, dann den Engpass finden, beheben und erneut messen.

1. Öffnen Sie PageSpeed Insights und testen Sie 5–10 wichtige Seiten: Startseite, Kategorien, Produktkarten, Landingpages. Achten Sie auf die Felddaten, nicht nur auf die Lighthouse-Punktzahl.
2. Gehen Sie in der Google Search Console zu Core Web Vitals. Dort sehen Sie anhand realer Nutzerdaten, welche URLs bei LCP, INP und CLS mit „Schlecht“ oder „Verbesserungsbedarf“ bewertet werden.
3. Führen Sie für eine detaillierte Analyse WebPageTest aus: Lade-Wasserfall, Filmstreifen, TTFB, Einfluss des CDN. Wählen Sie den Teststandort, der Ihrer Hauptzielgruppe am nächsten liegt.
4. Nutzen Sie die Chrome DevTools → Performance und zeichnen Sie einen Seitenaufbau auf. Das Flammendiagramm zeigt, welches Skript den Hauptthread belegt und das Rendering blockiert.
5. Prüfen Sie die Ansicht Coverage (DevTools → Coverage): Ungenutztes CSS und JS sind direkte Kandidaten zum Entfernen oder für verzögertes Laden.

Server- und TTFB-Optimierung

TTFB (Time to First Byte) ist die Grundlage jeder Geschwindigkeit. Antwortet der Server langsam, arbeitet jede weitere Optimierung gegen eine künstliche Obergrenze. Ziel: TTFB unter 200 ms in CDN-Umgebungen, unter 400 ms bei dynamischen Servern.

Hosting und Infrastruktur

Wahl des Hostings

Shared Hosting, bei dem sich die Ressourcen auf Tausende Websites verteilen, begrenzt die TTFB physisch. Ein VPS oder dedizierter Server mit Nginx/Caddy und sauberem Caching liefert bei statischen Inhalten eine TTFB von 20–80 ms.

CDN (Content Delivery Network)

Cloudflare, BunnyCDN, Fastly: Der nächste Edge-Knoten antwortet statt Ihres Ursprungsservers. Bei statischen oder gecachten Inhalten sinkt die TTFB auf 10–50 ms. Bei dynamischen Inhalten hängt das von der Konfiguration des Edge-Caches ab.

HTTP/2 und HTTP/3 (QUIC)

HTTP/2 beseitigt Head-of-Line-Blocking und unterstützt Multiplexing. HTTP/3 über QUIC beschleunigt den Verbindungsaufbau zusätzlich (0-RTT) und ist im mobilen Netz robuster gegenüber Paketverlust.

Geografischer Standort des Servers

Die physische Entfernung zwischen Nutzer und Server kostet etwa 1 ms pro 100 km (Hin- und Rückweg). Bei einer überwiegend europäischen Zielgruppe ist ein Server in Frankfurt oder Amsterdam deutlich schneller als US-East.

Komprimierung und Kodierung

• Aktivieren Sie Brotli (br). Es spart 15–25 % gegenüber gzip bei vergleichbarer Dekompressionsgeschwindigkeit. Alle modernen Browser unterstützen es.
• Behalten Sie gzip als Fallback für ältere Clients. Mindeststufe: Komprimierungsstufe 6.
• Aktivieren Sie die Komprimierung für HTML, CSS, JS, JSON, XML und SVG. Bilder und Binärdateien sind bereits komprimiert, gzip bringt darauf nichts.
• Verwenden Sie den Header Vary: Accept-Encoding, damit das CDN getrennte Versionen für verschiedene Clients speichert.

Serverseitiges Caching

Dynamische Seiten (PHP, Node.js, Python) greifen bei jeder Anfrage auf die Datenbank zu. Ein Cache liefert fertiges HTML aus, ohne es neu zu berechnen.

• Full-Page-Cache: Nginx FastCGI Cache, Varnish oder Redis speichern fertiges HTML und liefern es aus, ohne die Anwendung zu belasten.
• Objekt-Cache: Redis oder Memcached für Ergebnisse von Datenbankabfragen, Sessions und berechnete Daten.
• Regeln für die Invalidierung: Der Cache muss geleert werden, wenn sich Inhalte ändern (CMS-Webhook oder Ablauf nach TTL).
• Stale-while-revalidate: Den veralteten Cache sofort ausliefern und im Hintergrund neu erzeugen. Nutzer warten dann nicht auf die Neuerzeugung.

Asset-Optimierung: Bilder, Schriften, CSS

Bilder

Bilder sind meist die schwerste Kategorie der Seitenlast. Eine korrekte Optimierung spart 30–70 % des Traffics und wirkt sich direkt auf LCP aus.

Verwenden Sie das Element <picture>, um das passende Format auszuliefern: AVIF für unterstützende Browser, WebP als Fallback, JPEG/PNG für ältere Browser. Die Komponente Image von Next.js übernimmt das automatisch.

Schriften

• Schriften selbst hosten: Liefern Sie .woff2 von Ihrer eigenen Domain aus. So entfallen DNS-Abfrage, TCP-Handshake und die Abhängigkeit vom CDN von Google Fonts.
• Kritische Schriften vorladen: <link rel="preload" as="font" type="font/woff2" crossorigin> im <head>. Der Browser beginnt mit dem Laden, bevor das CSS geparst wird.
• font-display: swap. Der Browser zeigt die Systemschrift, bis die eigene Schrift geladen ist. So entfällt FOIT (unsichtbarer Text).
• Font-Subsetting: Laden Sie nur die benötigten Glyphen (Latein und Kyrillisch). Tools: glyphhanger oder fonttools.
• Variable Schriften verwenden: eine Datei statt mehrerer Schnitte (Regular, Fett, Kursiv). Das spart insgesamt 30–50 % der Schriftgröße.

CSS

Kritisches CSS inline

Styles für den sichtbaren Bereich ohne Scrollen werden direkt im <head> in einem <style>-Tag eingebettet. Der Browser rendert den ersten Bildschirm, ohne auf eine externe CSS-Datei zu warten. Der Rest des CSS wird asynchron geladen.

Minifizierung

Entfernen von Leerzeichen und Kommentaren, Kürzen von Eigenschaften. Tools: cssnano oder LightningCSS. Typische Einsparung: 10–30 % der ursprünglichen Größe.

Entfernen ungenutzten CSS

PurgeCSS, UnCSS oder der eingebaute Mechanismus des Frameworks (Tailwind Purge). Besonders wichtig bei Bootstrap oder Material UI, denn sie bringen Tausende ungenutzter Regeln mit.

@import in CSS vermeiden

CSS-@import erzeugt sequenzielle Anfragen: Der Browser lädt die Datei, findet das @import und lädt erst danach die nächste. Verwenden Sie stattdessen <link>-Tags für paralleles Laden.

JavaScript: Render-Blocking und Hauptthread

JavaScript ist auf modernen Websites der größte Gegner der Page Speed. Es blockiert das Rendering, belegt den Hauptthread und verzögert die Interaktivität. Ziel: möglichst wenig JS im kritischen Pfad und konsequente Nutzung von defer, async und dynamischem Import.

Ladestrategien

Bundle und Code-Splitting

• Code-Splitting: Teilen Sie JS in Chunks auf und laden Sie nur, was die aktuelle Seite braucht. In Next.js passiert das pro Seite automatisch.
• Dynamischer Import: import('module') für Komponenten, die beim ersten Laden nicht gebraucht werden (Modale, Tabs, Filter).
• Tree Shaking: Gebündelt wird nur der tatsächlich genutzte Code. Webpack und Rollup leisten das für ESM-Pakete. Prüfen Sie, ob CommonJS-Abhängigkeiten das Tree Shaking verhindern.
• Bundle-Analyse: bundlephobia.com zeigt die Größe von npm-Paketen, @next/bundle-analyzer zeigt für Next.js genau, was Platz belegt.
• Vermeiden Sie große monolithische Bibliotheken: moment.js (67 KB) → day.js (2 KB), lodash → einzelne Hilfsfunktionen, jQuery → natives JS.

SPA und serverseitiges Rendering

Client-seitige SPAs (React ohne SSR, Angular, Vue mit CSR) liefern leeres HTML und erzeugen Inhalte erst im Browser. Das führt zu einem hohen LCP und einer schlechten Time to Interactive.

SSR (Server-Side Rendering)

Das vollständige HTML wird auf dem Server erzeugt. Der Browser erhält die fertigen Inhalte sofort. LCP, FCP und der Lighthouse-Score verbessern sich deutlich. Erfordert Client-Hydration, daher sollten Sie die TTI (Time to Interactive) im Blick behalten.

SSG (Static Site Generation)

Das HTML wird zur Build-Zeit erzeugt. Maximale Geschwindigkeit bei TTFB und LCP. Geeignet für Inhalte, die selten ändern: Blog, Dokumentation, Landingpages.

PPR (Partial Prerendering)

Neu in Next.js 15: eine statische Seitenhülle mit gestreamten dynamischen Teilen. Die statische Hülle wird sofort vom CDN ausgeliefert, während die dynamischen Daten gestreamt werden, sobald sie fertig sind.

Caching: Browser und CDN

Richtig konfiguriertes Caching ist die günstigste Optimierung mit der größten Wirkung für wiederkehrende Besucher. Ziel: Alle statischen Assets werden ein Jahr lang gecacht. HTML wird minimal oder gar nicht gecacht.

• Inhaltsbasiertes Hashing (Fingerprinting): Webpack, Vite und Next.js hängen automatisch einen Content-Hash an die Dateinamen. Ändert sich der Code, ändert sich der Hash, und der alte Cache wird nicht mehr genutzt.
• ETag und Last-Modified: Hat der Client die Ressource bereits, antwortet der Server mit 304 Not Modified und ohne Body. Das spart Traffic, es bleibt aber ein Netzwerk-Roundtrip.
• Service Worker: ein programmierbarer Cache im Browser. Er ermöglicht komplexe Strategien (Cache-First, Network-First, Stale-While-Revalidate) für PWAs und Offline-Nutzung.
• CDN-Cache-Control: Verwenden Sie s-maxage, um das CDN-Caching unabhängig von max-age des Browsers zu steuern. Das CDN cached länger, der Browser kürzer.

Drittanbieter-Skripte: der versteckte Hauptverursacher

Drittanbieter-Skripte (Analytics, Chatbots, Pixel, A/B-Tests, Widgets) sind oft die Hauptursache für schlechte TBT- und INP-Werte. Eine durchschnittliche kommerzielle Seite lädt 15–30 Drittanbieter-Skripte.

FAQ