Wie ich Brotli nutzte, um noch kleinere CSS- und JavaScript-Dateien im CDN-Maßstab zu erhalten

Die HBO-Sitcom „Silicon Valley“ folgte auf humorvolle Weise Pied Piper, einem Team von Entwicklern mit Startup-Träumen, die einen Kompressionsalgorithmus entwickeln wollten, der so leistungsfähig ist, dass Bedenken hinsichtlich hochwertigem Streaming und Dateispeicherung der Vergangenheit angehören würden.

In der Show wird Google vom fiktiven Unternehmen Hooli dargestellt, das hinter Pied Pipers geistigem Eigentum her ist. Das Lustige ist, dass Google, obwohl weit von einem Startup entfernt, im wirklichen Leben tatsächlich eine leistungsstarke Kompressions-Engine namens Brotli hat.

Dieser Artikel handelt von meinen Erfahrungen mit Brotli im Produktionsmaßstab. Trotz der Tatsache, dass es sehr teuer und für die On-Demand-Komprimierung auf höheren Kompressionsstufen wirklich unpraktikabel ist, ist Brotli tatsächlich sehr sparsam und spart aus vielen Gründen Kosten, insbesondere im Vergleich zu gzip oder niedrigeren Kompressionsstufen von Brotli (worauf wir noch eingehen werden).

Brotlis Anfänge…

2015 veröffentlichte Google einen Blogbeitrag, in dem Brotli angekündigt und seinen Quellcode auf GitHub veröffentlicht wurde. Die beiden Entwickler, die Brotli entwickelten, entwickelten auch Googles Zopfli-Kompression zwei Jahre zuvor. Aber während Zopfli auf bestehenden Kompressionstechniken aufbaute, wurde Brotli von Grund auf neu geschrieben und konzentrierte sich gezielt auf Textkomprimierung, um statische Web-Assets wie HTML, CSS, JavaScript und sogar Webfonts zu optimieren.

Zu dieser Zeit arbeitete ich als freiberuflicher Berater für Web-Performance. Ich war sehr gespannt auf die von Brotli versprochene Verbesserung von 20-26% gegenüber Zopfli. Zopfli selbst ist eine dichte Implementierung des Deflate-Kompressors im Vergleich zur Standardimplementierung von zlib, daher war die Behauptung von bis zu 26% recht beeindruckend. Und was ist zlib? Es ist im Wesentlichen dasselbe wie gzip.

Wir betrachten also die nächste Generation von Zopfli, das ein Ableger von zlib ist, das im Wesentlichen gzip ist.

Eine Geschichte der Enttäuschung

Es dauerte einige Monate, bis große CDN-Anbieter Brotli unterstützten, aber inzwischen wurde es in Tools, Diensten, Browsern und Servern weit verbreitet eingesetzt. **Jedoch spiegelten sich die von Brotli versprochenen 26% dichte Komprimierung nie in der Produktion wider.** Einige CDNs stellten intern eine niedrigere Kompressionsstufe ein, während andere Brotli am Ursprung unterstützten, sodass sie es nur unterstützten, wenn es manuell am Ursprung aktiviert wurde.

Die Serverunterstützung für Brotli war ziemlich gut, aber um hohe Kompressionsstufen zu erreichen, war es erforderlich, eigene Vor-Komprimierungscodes zu schreiben oder ein Servermodul zu verwenden, um dies zu tun — was nicht immer eine Option ist, insbesondere bei Shared-Hosting-Diensten.

Das war wirklich enttäuschend für mich. Ich wollte jedes letzte mögliche Byte für die Websites meiner Kunden komprimieren, um sie schneller zu machen, aber die Verwendung von Vor-Komprimierung und die gleichzeitige Möglichkeit für Kunden, Dateien bei Bedarf zu aktualisieren, war nicht immer einfach.

Die Sache selbst in die Hand nehmen

Ich begann, meinen eigenen Performance-Optimierungsdienst für meine Kunden aufzubauen.

Ich hatte mehrere Tricks, die Websites erheblich beschleunigen konnten. Der Dienst kategorisierte alle Optimierungen in drei Gruppen, bestehend aus mehreren „Content-“, „Delivery-“ und „Cache“-Optimierungen. Brotli hatte ich für den Content-Optimierungsteil des Dienstes für komprimierbare Ressourcen im Auge.

Wie andere Komprimierungsformate gibt es auch Brotli in verschiedenen Leistungsstufen. Brotlis maximale Stufe ist genau wie die maximale Lautstärke der Gitarrenverstärker in „This is Spinal Tap“: Sie geht bis 11.

Brotli:11 oder Brotli-Kompressionsstufe 11 kann eine deutliche Reduzierung der Größe komprimierbarer Dateien bieten, hat aber einen erheblichen Nachteil: **Es ist schmerzhaft langsam und für die On-Demand-Komprimierung nicht praktikabel, so wie es gzip kann.** Es kostet erheblich mehr CPU-Zeit.

In meinen Benchmarks dauert es bei Brotli:11 mehrere hundert Millisekunden, um eine einzelne minifizierte jQuery-Datei zu komprimieren. Die einzige Möglichkeit, Brotli:11 meinen Kunden anzubieten, war, es für die Vor-Komprimierung zu verwenden, und ich musste einen Weg finden, Dateien auf Serverebene zu cachen. Glücklicherweise hatten wir das bereits eingerichtet. Das einzige Problem war die Befürchtung, dass Brotli all unsere Verarbeitungsressourcen aufbrauchen könnte.

Ich legte meine Ängste beiseite und baute Brotli:11 als konfigurierbare Serveroption auf. So konnten Kunden entscheiden, ob die Aktivierung die Rechenkosten wert war.

Es ist langsam, aber zahlt sich nach und nach aus

Neben verschiedenen anderen Optimierungen bietet der Dienst für meine Kunden auch geografische Inhaltsbereitstellung; mit anderen Worten, er verfügt über ein integriertes CDN.

Von den mehreren Tricks, die ich anwandte, als ich die Sache selbst in die Hand nahm, war einer die Kombination von öffentlichem CDN (oder Open-Source-CDN) und privatem CDN auf einem einzigen Host, damit Websites die Vorteile des gemeinsamen Browser-Caches öffentlicher Ressourcen nutzen können, ohne separate DNS-Lookup- und Verbindungskosten für diesen öffentlichen Host zu verursachen. Ich wollte diese zusätzlichen Verbindungskosten vermeiden, da sie erhebliche Auswirkungen für mobile Nutzer haben. Außerdem kann die Kombination von immer mehr Ressourcen auf einem einzigen Host dazu beitragen, die HTTP/2-Funktionen wie Multiplexing optimal zu nutzen.

Ich aktivierte das öffentliche CDN und schaltete die Brotli:11-Vor-Komprimierung für alle komprimierbaren Ressourcen ein, darunter CSS, JavaScript, SVG und TTF sowie andere Dateitypen. Der Overhead der Komprimierung erhöhte sich tatsächlich beim ersten Aufruf jeder Ressource – aber danach schien alles reibungslos zu laufen. Brotli hat über 90% Browserunterstützung und praktisch alle Anfragen, die meinen Dienst erreichen, nutzen jetzt Brotli.

Ich war glücklich. Kunden waren glücklich. Aber ich hatte keine Zahlen. Ich begann, die Auswirkungen der Aktivierung dieser Hochdichtekomprimierung auf öffentliche Ressourcen zu analysieren. Dafür habe ich die Dateigrößen mehrerer beliebter Bibliotheken aufgezeichnet – darunter jQuery, Bootstrap, React und andere Frameworks –, die gängige Komprimierungsmethoden anderer CDNs verwendeten, und festgestellt, dass die Brotli:11-Komprimierung im Vergleich zu anderen Komprimierungsformaten rund 21% einsparte.

Es ist wichtig zu beachten, dass einige der anderen öffentlichen CDNs, mit denen ich verglich, bereits Brotli verwendeten, jedoch auf niedrigeren Kompressionsstufen. Die zusätzlichen 21% Komprimierung waren für mich also wirklich zufriedenstellend. Diese Zahl basiert auf einer sehr kleinen Untermenge von Bibliotheken, ist aber nicht um viel daneben, da ich bei allen getesteten Websites diesen Gewinn erzielt habe.

Hier ist eine grafische Darstellung der Einsparungen.

Die Rohdaten können Sie unten einsehen. Beachten Sie, dass die Einsparungen bei CSS viel ausgeprägter sind als bei JavaScript.

Bibliothek	Original	Durchschnittliche gängige Komprimierung (A)	Brotli:11 (B)	(A) / (B) – 1
Ant Design	1.938,99 KB	438,24 KB	362,82 KB	20.79%
Bootstrap	152,11 KB	24,20 KB	17,30 KB	39.88%
Bulma	186,13 KB	23,40 KB	19,30 KB	21.24%
D3.js	236,82 KB	74,51 KB	65,75 KB	13.32%
Font Awesome	1.104,04 KB	422,56 KB	331,12 KB	27.62%
jQuery	86,08 KB	30,31 KB	27,65 KB	9.62%
React	105,47 KB	33,33 KB	30,28 KB	10.07%
Semantic UI	613,78 KB	91,93 KB	78,25 KB	17.48%
three.js	562,75 KB	134,01 KB	114,44 KB	17.10%
Vue.js	91,48 KB	33,17 KB	30,58 KB	8.47%

Die Ergebnisse sind großartig, was ich erwartet hatte. **Aber wie sieht es mit den Gesamtauswirkungen der Verwendung von Brotli:11 im großen Maßstab aus?** Es stellt sich heraus, dass die Verwendung von Brotli:11 für alle öffentlichen Ressourcen die Kosten rundherum reduziert.

• **Es wird erwartet, dass die kleineren Dateigrößen zu einem geringeren TLS-Overhead führen.** Das heißt, es ist nicht leicht messbar und für meinen Dienst nicht signifikant, da moderne CPUs bei der Verschlüsselung sehr schnell sind. Dennoch glaube ich, dass es durch die Verschlüsselung bei jeder Anfrage zu winzigen und wiederholten Einsparungen kommt, da kleinere Dateien schneller verschlüsselt werden.
• Es reduziert die Bandbreitenkosten. Die von mir erzielten 21% Einsparungen sind der Beweis. Und denken Sie daran, Einsparungen sind keine einmalige Sache. Jede Anfrage zählt als Kosten, daher wiederholen sich die 21% Einsparungen immer wieder und schaffen so eine Schneeball-Ersparnis bei den Bandbreitenkosten. 
• Wir cachen nur „heiße“ Dateien im Speicher auf Edge-Servern. Aufgrund der weit verbreiteten Browserunterstützung für Brotli werden diese „heißen“ Dateien meistens mit Brotli kodiert, und ihre geringe Größe ermöglicht es uns, mehr davon im verfügbaren Speicher unterzubringen.
• Besucher, insbesondere auf Mobilgeräten, profitieren von reduzierten Datenübertragungen. Dies führt zu geringerem Akkuverbrauch und Einsparungen bei den Datengebühren. Das ist ein riesiger Vorteil, der an die Nutzer unserer Kunden weitergegeben wird!

Das ist alles sehr gut. Die Kosten, die wir pro Anfrage sparen, sind nicht signifikant, aber wenn man bedenkt, dass wir bei öffentlichen Ressourcen eine Cache-Miss-Rate von nahezu Null haben, können wir die anfänglich hohen Kompressionskosten leicht auf die nächsten hundert Anfragen amortisieren. Danach profitieren wir ein Leben lang von reduzierten Kosten.

Es ist noch nicht vorbei

Mit der Mischung aus öffentlichen und privaten CDNs, die wir als Teil unseres Performance-Optimierungsdienstes eingeführt haben, wollten wir sicherstellen, dass Kunden niedrigere Kompressionsstufen für Ressourcen festlegen können, die sich häufig ändern (wie benutzerdefiniertes CSS und JavaScript) im privaten CDN und automatisch auf das öffentliche CDN für Open-Source-Ressourcen umschalten, die sich seltener ändern und über eine vordefinierte Brotli:11-Komprimierung verfügen. Auf diese Weise können unsere Kunden immer noch eine hohe Komprimierungsrate für selten geänderte Ressourcen erzielen und gleichzeitig gute Komprimierungsraten mit sofortiger Bereinigung und Updates für komprimierbare Ressourcen genießen.

Dies geschieht alles reibungslos und nahtlos mit unseren Integrationstools. Der zusätzliche Vorteil dieses Ansatzes für Kunden besteht darin, dass die Bandbreite des öffentlichen CDNs völlig kostenlos ist und beispiellose Leistungsniveaus bietet.

Probieren Sie es selbst aus!

Beim Testen auf einer gängigen Website kann eine aggressive Komprimierung die Seitenladezeit leicht um **rund 50 KB verkürzen**. Wenn Sie mit dem kostenlosen öffentlichen CDN experimentieren und kleinere CSS- und JavaScript-Dateien nutzen möchten, können Sie gerne unseren PageCDN-Dienst nutzen. Hier sind einige der am häufigsten verwendeten Bibliotheken für Ihre Nutzung

<!-- jQuery 3.5.0 -->
<script src="https://pagecdn.io/lib/jquery/3.5.0/jquery.min.js" crossorigin="anonymous" ></script>


<!-- FontAwesome 5.13.0 -->
<link href="https://pagecdn.io/lib/font-awesome/5.13.0/css/all.min.css" rel="stylesheet" crossorigin="anonymous" >


<!-- Ionicons 4.6.3 -->
<link href="https://pagecdn.io/lib/ionicons/4.6.3/css/ionicons.min.css" rel="stylesheet" crossorigin="anonymous" >


<!-- Bootstrap 4.4.1 -->
<link href="https://pagecdn.io/lib/bootstrap/4.4.1/css/bootstrap.min.css" rel="stylesheet" crossorigin="anonymous" >


<!-- React 16.13.1 -->
<script src="https://pagecdn.io/lib/react/16.13.1/umd/react.production.min.js" crossorigin="anonymous" ></script>


<!-- Vue 2.6.11 -->
<script src="https://pagecdn.io/lib/vue/2.6.11/vue.min.js" crossorigin="anonymous" ></script>

Unsere PHP-Bibliothek schaltet automatisch zwischen privatem und öffentlichem CDN um, falls Sie dies wünschen. Dieselbe Funktion ist nahtlos in unser WordPress-Plugin integriert, das öffentliche Ressourcen automatisch über das Public CDN lädt. Beide Tools bieten vollen Zugriff auf das kostenlose öffentliche CDN. Bibliotheken für JavaScript, Python und Ruby sind noch nicht verfügbar. Wenn Sie eine solche Bibliothek zu unserem Public CDN beitragen, werde ich sie gerne in unserer Dokumentation auflisten.

Zusätzlich können Sie unser Suchwerkzeug verwenden, um sofort eine entsprechende Ressource im öffentlichen CDN zu finden, indem Sie eine URL einer Ressource auf Ihrer Website angeben. Wenn keines dieser Tools für Sie funktioniert, können Sie die jeweilige Bibliotheksseite aufrufen und die gewünschten URLs auswählen.

Blick in die Zukunft

Wir haben damit begonnen, nur die beliebtesten Bibliotheken zu hosten, um die Verbreitung von Malware zu verhindern. Die Dinge ändern sich jedoch schnell und wir fügen neue Bibliotheken hinzu, wenn unsere Nutzer sie uns vorschlagen. Sie können auch gerne Ihre Favoriten vorschlagen. Wenn Sie immer noch eine öffentliche oder private GitHub-Repository verlinken möchten, die noch nicht auf unserem öffentlichen CDN verfügbar ist, können Sie unser privates CDN verwenden, um eine Verbindung zu einer Repository herzustellen und alle neuen Veröffentlichungen zu importieren, sobald sie auf GitHub erscheinen, und dann Ihre eigenen aggressiven Optimierungen vor der Auslieferung anzuwenden.

Was denkst du?

Alles, was wir hier behandelt haben, basiert ausschließlich auf meiner persönlichen Erfahrung mit Brotli-Kompression im CDN-Maßstab. Es ist zufällig auch eine Einführung in mein öffentliches CDN. Wir sind immer noch ein kleiner Dienst und unsere Kunden-Websites sind nur Hunderte. Dennoch scheint die aggressive Komprimierung in diesem Umfang rentabel zu sein.

Ich habe für meine Kunden hochwertige Ergebnisse erzielt und jetzt können Sie diesen kostenlosen Dienst auch für Ihre Websites nutzen. Und wenn er Ihnen gefällt, hinterlassen Sie bitte ein Feedback an meine E-Mail und empfehlen Sie ihn weiter.