Web-Performance optimieren

Sie haben eine Website gebaut, die gut aussieht und funktioniert, aber zu langsam lädt. Sie wissen nicht, wo Sie ansetzen sollen. Bildkomprimierung und CSS-Minifizierung allein reichen nicht aus. Sie brauchen gemessene Web-Vitals-Werte, gezieltes Lazy Loading, priorisierte Ressourcen und einen korrekt konfigurierten Browser-Cache und einen Service Worker. Das Ziel: schnelle Ladezeiten unter realen Bedingungen, nicht nur im lokalen Test.

Warum die Ladezeit entscheidet

Die Ladezeit einer Website ist kein rein technisches Detail. Sie bestimmt, ob Besucher bleiben oder weiterziehen, und sie fließt in die Bewertung durch Suchmaschinen ein. Google verwendet mit den Core Web Vitals eine Reihe von Messwerten, die das Ladeerlebnis abbilden: die Zeit bis zum ersten sichtbaren Inhalt, die Reaktion auf Eingaben und die visuelle Stabilität der Seite. An diesen Messwerten müssen sich alle Optimierungen messen lassen.

Wer eine Website für ein Unternehmen oder ein eigenes Projekt betreibt, sollte die Performance nicht als einmalige Aufgabe betrachten. Sie verändert sich mit jedem neuen Inhalt, jedem Plugin und jedem Design-Update. Eine neue Schriftart, ein zusätzliches Tracking-Skript oder ein größeres Hero-Bild können die Messwerte spürbar verschlechtern, ohne dass im Quelltext ein offensichtlicher Fehler auftritt. Deshalb gehört die Messung in den regelmäßigen Arbeitsablauf, nicht nur in die Launch-Phase.

Web Vitals messen

Bevor Sie optimieren, brauchen Sie eine verlässliche Messung. Laborwerte aus einem eigenen Test mit schnellem Internet und leerem Cache sagen wenig über die Erfahrung realer Besucher aus. Entscheidend sind Felddaten, also Messwerte, die von echten Nutzern mit ihren Geräten und Netzwerken gesammelt werden.

Für die eigene Analyse stehen Ihnen die Performance-APIs des Browsers zur Verfügung. Die Navigation Timing API liefert detaillierte Zeitstempel für die einzelnen Phasen des Ladeprozesses, vom Beginn der Anfrage bis zur vollständigen Darstellung. Mit der PerformanceObserver API können Sie Performance-Einträge beobachten, während sie auftreten, ohne die Seite zu blockieren. Damit können Sie messen, wie lange bestimmte Ressourcen brauchen und wo Engpässe entstehen.

Für Felddaten nutzen Sie Dienste, die die Werte Ihrer Besucher sammeln, etwa den Chrome User Experience Report oder Analyse-Tools, die Performance-Messwerte direkt auf der Seite erfassen. Achten Sie darauf, die Messung über mehrere Wochen laufen zu lassen, denn die Werte schwanken mit Tageszeit, Endgeräten und Netzwerkbedingungen. Eine einzelne Stichprobe ist kein Beleg für eine Verbesserung.

Lazy Loading einsetzen

Lazy Loading bedeutet, dass der Browser Bilder und andere Medien erst dann lädt, wenn sie kurz davor sind, in den sichtbaren Bereich zu kommen. Das spart Datenvolumen und beschleunigt den ersten Aufbau der Seite, besonders bei langen Seiten mit vielen Bildern.

Für Bilder unterhalb des sichtbaren Bereichs ist das loading="lazy"-Attribut der einfachste Einstieg. Es funktioniert in allen modernen Browsern und benötigt kein zusätzliches Skript. Wichtig ist die Einschränkung: Bilder im oberen Bereich, also das Hero-Bild oder das erste Produktfoto, sollten Sie nicht lazy laden. Sie sind sofort sichtbar und gehören zur kritischen Darstellung. Wenn Sie sie verzögern, verschlechtern Sie den messbaren Ersteindruck.

Für komplexere Fälle, etwa wenn Sie eigene Logik benötigen, um zu entscheiden, wann ein Element geladen wird, bietet sich der Intersection Observer an. Er beobachtet, wann ein Element den Viewport betritt, und löst dann das Laden aus. Das ist nützlich für Hintergrundbilder, die per CSS gesetzt werden, oder für Iframes mit eingebetteten Inhalten, die erst bei Bedarf geladen werden sollen.

Ressourcen priorisieren

Nicht alle Ressourcen sind gleich wichtig. Der Browser hat eine eigene Reihenfolge, in der er Skripte, Stylesheets und Bilder lädt, aber diese Reihenfolge passt nicht immer zu den Anforderungen Ihrer Seite. Mit Preloading teilen Sie dem Browser mit, dass eine bestimmte Ressource früh geladen werden soll, noch bevor er sie normalerweise anfordern würde.

Sinnvoll ist Preloading für Ressourcen, die für die erste Darstellung kritisch sind, aber erst spät im HTML auftauchen. Ein typisches Beispiel sind Schriftarten, die per CSS geladen werden und erst nach dem Stylesheet bekannt sind. Wenn Sie die Schriftart vorladen, steht sie früher zur Verfügung und reduziert das Umspringen des Textes, das als schlechte visuelle Stabilität gemessen wird.

Die Fetch Priority API geht einen Schritt weiter. Mit ihr können Sie die Priorität einzelner Ressourcen explizit setzen. Damit können Sie etwa ein wichtiges Skript höher einstufen als ein weniger kritisches. Setzen Sie diese Mechanik sparsam ein. Wenn Sie zu viele Ressourcen vorladen oder priorisieren, konkurrieren sie um die begrenzte Bandbreite und der Vorteil kehrt sich um.

HTTP Early Hints ist eine Server-Funktion, mit der der Server bereits vor der vollständigen Antwort erste Hinweise an den Browser sendet, welche Ressourcen geladen werden sollen. Das verkürzt die Wartezeit, besonders bei Verbindungen mit hoher Latenz. Die Umsetzung erfordert Zugriff auf die Serverkonfiguration und ist nicht bei jedem Hosting-Anbieter verfügbar. Prüfen Sie, ob Ihr Anbieter die Funktion unterstützt, bevor Sie Zeit in die Einrichtung investieren.

Cache und Service Worker nutzen

Der Browser-Cache speichert bereits geladene Ressourcen, damit sie bei einem erneuten Besuch nicht erneut übertragen werden müssen. Sie steuern den Cache über HTTP-Header wie Cache-Control, mit denen Sie festlegen, wie lange eine Ressource gespeichert werden darf und ob sie bei jedem Besuch neu validiert werden muss.

Statische Ressourcen wie Bilder, CSS- und JavaScript-Dateien, die sich selten ändern, können Sie mit einer langen Cache-Dauer versehen. Damit der Besucher nach einem Update nicht die alte Version sieht, verwenden Sie einen Fingerprint im Dateinamen, etwa style-v2.css. Der Browser lädt die neue Datei, weil sich die URL geändert hat, und die alte Version läuft von selbst aus dem Cache.

Service Worker gehen über den einfachen Cache hinaus. Es sind Skripte, die der Browser im Hintergrund ausführt und die als Vermittler zwischen Website und Netzwerk stehen. Sie können Antworten aus dem Cache liefern, wenn kein Netzwerk verfügbar ist, und so Offline-Funktionen ermöglichen. Für wiederkehrende Besucher beschleunigen sie den Seitenaufbau, weil Teile der Seite direkt aus dem lokalen Speicher kommen.

Der Aufwand für einen Service Worker ist nicht zu unterschätzen. Sie müssen die Cache-Strategien für verschiedene Ressourcentypen festlegen, die Aktualisierung des Workers planen und Fehler behandeln, wenn der Cache veraltet ist. Ein schlecht konfigurierter Service Worker kann dazu führen, dass Besucher veraltete Inhalte sehen oder dass Updates nicht ankommen. Testen Sie die Strategien gründlich, bevor Sie den Worker für alle Besucher aktivieren.