Welchen Einfluss hat die Wahl des Kompressionsalgorithmus (Brotli vs. Gzip) auf die Time to First Byte (TTFB) bei statischen Assets?

Die Wahl zwischen Brotli und Gzip beeinflusst die Time to First Byte (TTFB) bei statischen Assets primär über die Art der Implementierung: On-the-fly-Kompression versus Pre-Kompression.

Bei der dynamischen Kompression (On-the-fly) muss der Server die Datei bei jeder Anfrage komprimieren. Brotli benötigt bei hohen Kompressionsstufen deutlich mehr CPU-Ressourcen als Gzip, was die TTFB messbar erhöht. Da statische Assets jedoch in der Regel vorab komprimiert werden (Pre-Kompression), entfällt dieser Rechenaufwand während des Requests. Der Server liefert lediglich die bereits existierende .br oder .gz Datei aus. In diesem Szenario ist der Einfluss auf die TTFB vernachlässigbar, da die Zeit für den Dateizugriff und den TCP-Handshake identisch bleibt.

Der Vorteil von Brotli liegt in der geringeren Dateigröße, was die Gesamtladezeit (Page Load Time) und den Largest Contentful Paint (LCP) verbessert, nicht jedoch die TTFB.

Vergleich der Auswirkungen bei statischen Assets:

Die Entscheidung für einen Algorithmus ist Teil einer übergeordneten IT-Consulting & Digitale Strategie, bei der die Balance zwischen Kompatibilität und Performance optimiert wird. Während Gzip eine universelle Unterstützung bietet, wird Brotli von allen modernen Browsern unterstützt und liefert bei Textdateien (HTML, CSS, JS) eine bessere Kompressionsrate.

Wir empfehlen für alle statischen Assets den Einsatz von Brotli in Kombination mit einer Pre-Kompression während des Build-Prozesses. Die geringere Payload reduziert die Netzwerkübertragungszeit signifikant, ohne die TTFB negativ zu beeinflussen. Gzip sollte lediglich als Fallback für veraltete Clients konfiguriert werden.