„All the way up to 11“: Brotli-Bereitstellung vom Ursprung aus & neues Feature: Compression Rules

Während der gesamten Speed Week haben wir darüber gesprochen, wie wichtig es ist, die Performance zu optimieren. Die Komprimierung spielt eine entscheidende Rolle bei der Reduzierung der über das Internet übertragenen Dateigrößen. Kleinere Dateigrößen führen zu schnelleren Downloads, einem schnelleren Laden der Website und einer besseren Benutzerfreundlichkeit.

Nehmen Sie Haushaltsreiniger als praktisches Beispiel. Es wird geschätzt, dass „eine typische Flasche Reinigungsmittel zu 90 % aus Wasser und zu weniger als 10 % aus wertvollen Inhaltsstoffen besteht“. Wenn Sie 90 % einer typischen 500ml Flasche Haushaltsreiniger entfernen, reduziert sich das Gewicht von 600g auf 60g. Diese Reduktion bedeutet, dass nur ein 60g-Paket mit der Anweisung, es bei Erhalt zu rehydrieren, verschickt werden muss. Rechnet man diese Gewichtsreduzierung auf mehrere Hunderte Liter hoch, so ergibt sich für Unternehmen schnell eine enorme Einsparung beim Versand. Ganz zu schweigen von den Auswirkungen auf die Umwelt.

So funktioniert die Komprimierung. Der Absender komprimiert die Datei auf die kleinstmögliche Größe und sendet dann die kleinere Datei mit Anweisungen, wie sie beim Empfang zu behandeln ist. Durch die Verringerung der Größe der gesendeten Dateien sorgt die Komprimierung dafür, dass die für die Übertragung von Dateien über das Internet benötigte Bandbreite wesentlich geringer ist. Wenn Dateien bei teuren Cloud-Anbietern wie AWS gespeichert sind, kann die Reduktion der Dateigröße der gesendeten Dateien direkt zu erheblichen Kosteneinsparungen bei der Bandbreite führen.

Kleinere Dateigrößen sind auch besonders vorteilhaft für Endbenutzer mit begrenzten Internetverbindungen, wie z. B. mobile Geräte in Mobilfunknetzen oder Benutzer in Gebieten mit langsamen Netzwerkgeschwindigkeiten.

Cloudflare hat schon immer die Komprimierung in Form von Gzip unterstützt. Gzip ist ein weit verbreiteter Komprimierungsalgorithmus, den es seit 1992 gibt und der allen Cloudflare-Benutzern Dateikomprimierung bietet. 2013 führte Google jedoch Brotli ein, das höhere Komprimierungsstufen und eine insgesamt bessere Performance unterstützt. Der Wechsel von gzip zu Brotli führt zu kleineren Dateigrößen und schnelleren Ladezeiten für Webseiten. Wir unterstützen Brotli seit 2017 für die Verbindung zwischen Cloudflare und Client-Browsern. Heute kündigen wir die End-to-End-Unterstützung von Brotli für Webinhalte an: Unterstützung für die Brotli-Komprimierung auf der höchstmöglichen Stufe, vom Ursprungsserver bis zum Client.

Wenn Ihr Ursprungsserver Brotli unterstützt, aktivieren Sie es, erhöhen Sie die Komprimierungsstufe und genießen Sie den Performance-Boost.

Brotli-Komprimierung auf 11

Brotli verfügt über 12 Komprimierungsstufen von 0 bis 11, wobei 0 die schnellste Komprimierungsgeschwindigkeit, aber die niedrigste Komprimierungsrate und 11 die höchste Komprimierungsrate bietet, aber mehr Computing-Ressourcen und Zeit erfordert. Bei unserer ersten Implementierung von Brotli vor fünf Jahren haben wir festgestellt, dass die Komprimierungsstufe 4 ein ausgewogenes Verhältnis zwischen den eingesparten Bytes und der Komprimierungszeit bietet, ohne die Performance zu beeinträchtigen.

Seit 2017 verwendet Cloudflare eine maximale Komprimierung von Brotli-Stufe 4 für alle komprimierbaren Assets, basierend auf dem „accept-encoding“-Header des Endnutzers. Ein Problem war jedoch, dass Cloudflare nur Gzip-Komprimierung vom Ursprung anforderte, selbst wenn der Ursprung Brotli unterstützte. Darüber hinaus würde Cloudflare die von der Quelle empfangenen Inhalte immer dekomprimieren, bevor sie komprimiert und an den Endbenutzer gesendet werden, was zu einer zusätzlichen Verarbeitungszeit führt. Infolgedessen waren die Kunden nicht in der Lage, die Vorteile der Brotli-Komprimierung voll auszuschöpfen.

So wurde es früher gemacht

Da Cloudflare Brotli nun vollständig End-to-End unterstützt, werden Kunden nun feststellen können, dass unser aktualisierter accept-encoding-Header bei ihren Ursprüngen ankommt. Sobald dies der Fall ist, können Kunden stark komprimierte Brotli-Dateien direkt an uns übertragen, zwischenspeichern und bereitstellen, und zwar bis zur maximalen Stufe 11. Dies wird dazu beitragen, die Latenzzeit und den Bandbreitenverbrauch zu reduzieren. Wenn das Gerät des Endbenutzers die Brotli-Komprimierung nicht unterstützt, dekomprimieren wir die Datei automatisch und stellen sie entweder im dekomprimierten Format oder als mit Gzip komprimierte Datei bereit, je nach accept-encoding-Header.

Vollständige End-to-End-Unterstützung der Brotli-Komprimierung

Endbenutzer kann die Brotli-Komprimierung nicht unterstützen

Kunden können die Brotli-Komprimierung bei ihrem Ursprungsserver implementieren, indem sie sich die entsprechenden Online-Materialien ansehen. Beispielsweise können Kunden, die NGINX verwenden, Brotli implementieren, indem sie diese Anleitung befolgen und die Komprimierung in der Konfigurationsdatei `nginx.conf` wie folgt auf Stufe 11 einstellen:

brotli on;
brotli_comp_level 11;
brotli_static on;
brotli_types text/plain text/css application/javascript application/x-javascript text/xml 
application/xml application/xml+rss text/javascript image/x-icon 
image/vnd.microsoft.icon image/bmp image/svg+xml;

Cloudflare stellt diese Assets dann dem Client mit genau der gleichen Komprimierungsstufe (11) für die passende Datei brotli_types zur Verfügung. Das bedeutet, dass alle SVG- oder BMP-Bilder mit Brotli-Stufe 11 komprimiert an den Client gesendet werden.

Testen

Wir haben eine einfache CSS-Datei komprimiert und dabei die Auswirkungen verschiedener Komprimierungsalgorithmen und -stufen gemessen. Unser Ziel war es, potenzielle Verbesserungen zu identifizieren, die Benutzer durch die Optimierung von Komprimierungstechniken erfahren könnten. Diese Ergebnisse sind in der folgenden Tabelle zu sehen:

Durch die Komprimierung von Brotli auf Stufe 11 können Benutzer ihre Dateigrößen im Vergleich zur besten Gzip-Komprimierungsstufe um 19 % reduzieren. Außerdem ist die stärkste Brotli-Komprimierungsstufe etwa 18 % kleiner als die von Cloudflare verwendete Standardstufe. Dies unterstreicht die erhebliche Größenreduzierung, die durch die Verwendung der Brotli-Komprimierung erreicht wird, insbesondere auf der höchsten Stufe, was zu einer verbesserten Leistung der Website, schnelleren Ladezeiten und einer allgemeinen Reduzierung der Egress-Gebühren führen kann.

Damit die Vorteile der höheren End-to-End-Komprimierungsraten genutzt werden können, müssen die folgenden Cloudflare-Proxy-Funktionen deaktiviert werden.

• E-Mail-Adresse verschleiern
• Rocket Loader
• Serverseitige Ausnahmen (Server Side Excludes, SSE)
• Mirage
• HTML Minification - JavaScript und CSS können aktiviert bleiben.
• Automatic HTTPS RewritesDies ist darauf zurückzuführen, dass Cloudflare den Body dekomprimieren und darauf zugreifen muss, um die angeforderten Einstellungen anzuwenden. Alternativ kann ein Kunde diese Funktionen für bestimmte Pfade über Konfigurationsregeln deaktivieren.

Wenn eine dieser Rewrite-Funktionen aktiviert ist, kann Ihr Ursprung immer noch eine Brotli-Komprimierung mit höheren Stufen senden. Wir dekomprimieren jedoch, wenden die aktivierte(n) Cloudflare-Funktion(en) an und komprimieren im laufenden Betrieb erneut mit der Standard-Brotli-Stufe 4 oder Gzip-Stufe 8, je nach dem accept-encoding-Header des Benutzers.

Bei Browsern, die keine Brotli-Komprimierung akzeptieren, werden wir weiterhin dekomprimieren und Gzipped-Antworten oder unkomprimiert senden.

Implementierung

Der erste Schritt zur Implementierung von Brotli vom Ursprung aus bestand in der Konstruktion eines Dekomprimierungsmoduls, das in den Cloudflare Software-Stack integriert werden konnte. Damit können wir die komprimierten Bits, die wir von der Quelle erhalten, effizient in die ursprüngliche, unkomprimierte Datei umwandeln. Dieser Schritt war entscheidend, da zahlreiche Funktionen wie E-Mail-Verschleierung (Email Obfuscation) und Cloudflare Workers Customers darauf angewiesen sind, auf den Body einer Antwort zuzugreifen, um Anpassungen vorzunehmen.

Wir haben den Dekomprimierer in den zentralen Reverse-Web-Proxy von Cloudflare integriert. Diese Integration stellte sicher, dass alle Cloudflare-Produkte und -Funktionen mühelos auf die Brotli-Dekomprimierung zugreifen können. Dies ermöglichte es unserem Cloudflare Workers-Team auch, Brotli direkt in Cloudflare Workers zu integrieren, so dass unsere Workers-Kunden in der Lage sind, mit den in Brotli zurückgegebenen Antworten zu interagieren oder sie unverändert an den Endbenutzer weiterzuleiten.

Wir präsentieren: Compression Rules – Präzise Steuerung der Komprimierung zu Endnutzern

Standardmäßig komprimiert Cloudflare bestimmte Inhaltstypen basierend auf dem Content-Type-Header der Datei. Heute kündigen wir außerdem Compression Rules für unsere Enterprise-Kunden an, mit denen Sie noch mehr Kontrolle darüber haben, wie und was Cloudflare komprimiert.

Heute kündigen wir auch die Einführung von Compression Rules für unsere Enterprise-Kunden an. Mit Compression Rules erhalten Sie eine bessere Kontrolle über die Komprimierungsfunktionen von Cloudflare. So können Sie individuell festlegen, wie und welche Inhalte Cloudflare komprimiert, um die Performance Ihrer Website zu optimieren.

Zum Beispiel durch die Verwendung der Compression Rules von Cloudflare für .ktx -Dateien können Kunden die Bereitstellung von Texturen in WebGL-Anwendungen optimieren und so das Benutzererlebnis insgesamt verbessern. Durch die Aktivierung der Komprimierung wird die Bandbreitennutzung minimiert und sichergestellt, dass WebGL-Anwendungen schnell und reibungslos geladen werden, selbst wenn es sich um große und detaillierte Texturen handelt.

Alternativ können Kunden die Komprimierung deaktivieren oder eine Präferenz für die Art der Komprimierung angeben. Ein anderes Beispiel wäre ein Infrastrukturunternehmen, das Gzip nur für seine IoT-Geräte unterstützen möchte, aber Brotli-Komprimierung für alle anderen Hostnamen zulässt.

Compression Rules verwenden die Filter, auf denen unsere anderen Regelprodukte aufbauen, mit den zusätzlichen Feldern Medientyp und Erweiterungstyp. So können Sie ganz einfach die Inhalte angeben, die Sie komprimieren möchten.

Abschaffung des Brotli-Toggles

Brotli wird schon seit 2016 von einigen Webbrowsern unterstützt, seit 2017 bietet Cloudflare Brotli-Support an. Wie bei allen neuen Webtechnologien war Brotli unbekannt und wir gaben Kunden die Möglichkeit, Brotli über die API und unsere Benutzeroberfläche selektiv zu aktivieren oder zu deaktivieren.

Da sich Brotli nun weiterentwickelt hat und von allen Browsern unterstützt wird, planen wir, Brotli in den kommenden Monaten in allen Zonen standardmäßig zu aktivieren. Wir spiegeln das Gzip-Verhalten wider, das wir derzeit unterstützen, und entfernen die Umschaltfunktion aus unserem Dashboard. Wenn Browser Brotli nicht unterstützen, wird Cloudflare weiterhin die von ihnen akzeptierten Kodierungstypen wie Gzip oder unkomprimiert unterstützen. Enterprise-Kunden werden weiterhin in der Lage sein, Compression Rules zu verwenden, um genau zu steuern, wie wir die Daten für ihre Benutzer komprimieren.

Die Zukunft der Webkomprimierung

Nicht nur haben wir eine hohe Akzeptanz von Brotli als neuer Komprimierungstechnik für das Web festgestellt, es bietet auch eine exzellente Performance. Mit Blick auf die Zukunft behalten wir Trends und neue Komprimierungsalgorithmen wie zstd als möglichen Komprimierungsalgorithmus der nächsten Generation gut im Auge.

Gleichzeitig versuchen wir, Brotli direkt zu verbessern, wo wir können. Eine Entwicklung, auf die wir uns besonders konzentrieren, ist die gemeinsame Nutzung von Wörterbüchern mit Brotli. Wann immer Sie ein Asset komprimieren, verwenden Sie ein „Wörterbuch“, das die Komprimierung effizienter macht. Eine einfache Analogie dazu ist die Eingabe von OMW in eine iPhone-Nachricht. Das iPhone übersetzt es automatisch mit Hilfe seines eigenen internen Wörterbuchs in On My Way.

Dieses interne Wörterbuch hat aus drei Zeichen neun Zeichen gemacht (einschließlich Leerzeichen). Das interne Wörterbuch hat sechs Zeichen eingespart, was für die Benutzer einen Performance-Vorteil bedeutet.

Standardmäßig definiert der Brotli RFC ein statisches Wörterbuch, das sowohl von den Clients als auch von den Ursprungsservern verwendet wird. Das statische Wörterbuch wurde so konzipiert, dass es universell einsetzbar ist und für jeden gilt. Die Größe des Wörterbuchs wurde so optimiert, dass es nicht zu groß ist und gleichzeitig die besten Komprimierungsergebnisse erzielt werden können. Was wäre jedoch, wenn ein Ursprungsserver ein maßgeschneidertes Wörterbuch für eine bestimmte Website erstellen könnte? Ein Cloudflare-spezifisches Wörterbuch würde es uns beispielsweise ermöglichen, die Wörter und Ausdrücke zu komprimieren, die auf unserer Website wiederholt vorkommen, wie z.B. das Wort „Cloudflare“. Das maßgeschneiderte Wörterbuch wäre so konzipiert, dass es diese so stark wie möglich komprimiert, und der Browser, der dasselbe Wörterbuch verwendet, wäre in der Lage, dies zurück zu übersetzen.

Ein neuer Vorschlag des Web Incubator CG zielt darauf ab, genau das zu tun. Sie können Ihre eigenen Wörterbücher angeben, die Browser verwenden können, um Websites eine weitere Optimierung der Komprimierung zu ermöglichen. Wir freuen uns, zu diesem Vorschlag beizutragen und planen, unsere Forschungsergebnisse bald zu veröffentlichen.

Jetzt Testen

Compression Rules sind jetzt verfügbar! End-to-End-Brotli-Komprimierung wird in den kommenden Wochen eingeführt. So können Sie die Performance verbessern, die Bandbreite reduzieren und präzise steuern, wie Cloudflare die Komprimierung für Ihre Endbenutzer handhabt.