Caching, Komprimierung und Auslieferung
Caching und Komprimierung gehören zu den wirkungsvollsten Einzelmaßnahmen der Performance-Optimierung. Richtig konfiguriert, können sie die übertragene Datenmenge um 60 bis 80 Prozent reduzieren und wiederholte Seitenaufrufe nahezu instantan machen. Die folgenden Fragen erklären die verschiedenen Caching-Ebenen und Komprimierungsmethoden, die wir in unseren Performance-Projekten einsetzen. Mehr über unser Team und unsere Arbeitsweise erfahren Sie auf der Über-uns-Seite.
- Was ist der Unterschied zwischen Browser-Cache und Server-Cache? Der Browser-Cache speichert Ressourcen wie Bilder, CSS und JavaScript lokal auf dem Gerät des Besuchers. Beim wiederholten Seitenaufruf werden diese Ressourcen direkt vom lokalen Speicher geladen, ohne den Server zu kontaktieren. Der Server-Cache hingegen speichert vorab gerenderte HTML-Seiten oder Datenbankabfragen auf dem Server, sodass sie bei jedem Aufruf, auch von neuen Besuchern, schneller ausgeliefert werden. Beide Caching-Ebenen ergänzen sich: Der Server-Cache beschleunigt den ersten Seitenaufruf, der Browser-Cache beschleunigt alle weiteren Aufrufe desselben Besuchers.
- Was ist Brotli-Komprimierung und warum ist sie besser als Gzip? Brotli ist ein von Google entwickelter Komprimierungsalgorithmus, der speziell für Web-Inhalte optimiert wurde. Im Vergleich zu Gzip erreicht Brotli bei textbasierten Ressourcen wie HTML, CSS und JavaScript eine 15 bis 25 Prozent bessere Komprimierung (Google, 2023). Das bedeutet kleinere Übertragungsgrößen und schnellere Ladezeiten. Moderne Browser unterstützen Brotli vollständig. Wir konfigurieren Server so, dass sie Brotli als bevorzugten Algorithmus verwenden und Gzip als Fallback für ältere Clients bereitstellen.
- Wie funktioniert ein Reverse Proxy wie Varnish? Ein Reverse Proxy sitzt zwischen dem Webserver und den Besuchern und speichert komplette HTML-Seiten im Arbeitsspeicher. Wenn ein Besucher eine gecachte Seite aufruft, liefert der Reverse Proxy die Seite direkt aus dem Speicher, ohne dass der Webserver oder die Datenbank überhaupt kontaktiert werden. Das reduziert die TTFB auf wenige Millisekunden, selbst bei komplexen dynamischen Seiten. Varnish ist besonders effektiv für Shop-Systeme mit vielen Kategorie- und Produktseiten, die sich selten ändern.
- Was bedeutet Critical CSS und wie wird es implementiert? Critical CSS bezeichnet den minimalen CSS-Code, der benötigt wird, um den sichtbaren Bereich einer Seite (Above the Fold) beim ersten Laden korrekt darzustellen. Dieser CSS-Code wird inline im HTML-Dokument eingebettet, sodass der Browser die Seite sofort rendern kann, ohne auf externe CSS-Dateien warten zu müssen. Das restliche CSS wird asynchron nachgeladen. Die Implementierung erfolgt durch automatisierte Extraktion des kritischen CSS mit spezialisierten Tools, die den sichtbaren Bereich für verschiedene Bildschirmgrößen analysieren. Das Ergebnis ist ein deutlich schnellerer First Contentful Paint.
- Wie gehe ich mit Third-Party-Scripts um, die die Performance bremsen? Third-Party-Scripts wie Analytics, Chat-Widgets, Marketing-Pixel und Social-Media-Embeds gehören zu den häufigsten Performance-Bremsen. Wir gehen in drei Schritten vor: Erstens inventarisieren wir alle eingebundenen Third-Party-Scripts und bewerten ihren geschäftlichen Nutzen. Zweitens eliminieren wir nicht mehr benötigte Scripts. Drittens optimieren wir die verbleibenden durch verzögertes Laden (Lazy Loading nach User-Interaktion), Self-Hosting der Script-Dateien auf dem eigenen Server, Fassaden für Chat-Widgets und Embeds sowie Service Worker für gezieltes Caching.
- Wie stelle ich sicher, dass die Performance nach der Optimierung stabil bleibt? Performance-Regressionen entstehen häufig durch neue Inhalte, Plugin-Updates oder Änderungen an Drittanbieter-Scripts. Um die Stabilität zu sichern, empfehlen wir drei Maßnahmen: ein automatisiertes Monitoring, das Core Web Vitals kontinuierlich misst und bei Verschlechterungen alarmiert, eine Performance-Budget-Definition, die maximale Seitengrößen und Script-Volumen festlegt, und regelmäßige Performance-Reviews im Quartalsrhythmus. So werden Regressionen innerhalb von Stunden erkannt und können behoben werden, bevor sie die Felddaten negativ beeinflussen.