📒 🤷🏽 🍪 Brotli Effizienz in der realen Welt #⃣ ⚒️ 🗄️

Eine der grundlegendsten Regeln für die Entwicklung schneller Websites ist die Optimierung ihrer Ressourcen. Wenn es sich um Textressourcen handelt - um Code, der in HTML, CSS und JavaScript geschrieben wurde, bedeutet dies, dass es sich um Datenkomprimierung handelt. Der De-facto-Standard zum Komprimieren von Textressourcen im Web ist die Gzip-Methode. Das heißt, ungefähr 80% der komprimierten Ressourcen, die beim Herunterladen der Site erhalten werden, werden mit Gzip komprimiert. Um die verbleibenden 20% der Ressourcen zu komprimieren, wird ein viel neuerer Algorithmus verwendet - Brotli.

Natürlich enthalten diese 100% der komprimierten Ressourcen, die in Browser gelangen, wenn sie Antworten auf Anfragen an Websites erhalten, nicht alle Ressourcen. Es gibt immer noch viele Ressourcen, die komprimiert oder komprimiert werden könnten. Diese Ressourcen bleiben jedoch unkomprimiert. Ausführlichere Metriken zur Komprimierung finden Sie im Abschnitt Komprimierung der Web Almanac-Ressource.

Die gzip-Komprimierungsmethode ist unglaublich effizient. Alle Arbeiten von Shakespeare im Klartext dauern 5,3 MB. Und nach der Gzip-Komprimierung (Komprimierungsstufe 6) belegen sie nur 1,9 MB. Dies bedeutet, dass sich die Dateigröße, in der diese Daten gespeichert sind, um das 2,8-fache verringert hat. Gleichzeitig gehen bei der Komprimierung keine Daten verloren. Großartig!

Noch besser ist, dass der Grad der Gzip-Komprimierung durch das Vorhandensein doppelter Zeilen in Dateien beeinflusst wird. Je mehr Wiederholungen im Text enthalten sind, desto effizienter ist die Komprimierung. Dies ist sehr gut für das Web, da der in HTML, CSS und JS geschriebene Code eine einheitliche Syntax hat und viele Wiederholungen enthält.

Obwohl Gzip eine sehr effiziente Komprimierungsmethode ist, ist es auch ziemlich alt. Es erschien 1992 (was natürlich hilft, seine weit verbreitete Verbreitung zu erklären). Nach 21 Jahren veröffentlichte Google 2013 Brotli, einen neuen Algorithmus, der eine noch höhere Komprimierung verspricht als die Gzip-Methode. Dieselben Werke von Shakespeare mit einer Größe von 5,2 MB werden mit Brotli auf eine Größe von 1,7 MB (mit einer Komprimierungsstufe von 6) komprimiert. Und das bedeutet bereits eine 3,1-fache Reduzierung der Dateigröße. Dies ist sogar besser als die Verwendung von Gzip.

Wenn Sie ein Tool verwenden , um den Grad der Datenkomprimierung mit Gzip und Brotli zu bewerten, werden Sie wahrscheinlich feststellen, dass Brotli beim Komprimieren einiger Daten viel effizienter ist als Gzip. Beispielsweise sind ReactDOM-Daten bei Komprimierung mit Brotli mit maximaler Komprimierungsstufe (11) um 27% kleiner als bei Verwendung von Gzip mit maximaler Komprimierungsstufe (9).

Hier ist ein Vergleich der Brotli-Komprimierung mit der Gzip-Komprimierung bei der Verarbeitung von ReactDOM.

Komprimierungsstufe	Größe (in Bytes)	Komprimierungseffizienz (im Vergleich zu nicht komprimierten Daten)	% Verbesserung gegenüber Gzip
1	43456	2.73	3%
2	39898	2,97	elf%
3	39416	3,08	fünfzehn%
4	38488	3,08	fünfzehn%
5	36323	3.27	neunzehn%
6	36048	3.29	zwanzig%
7	35804	3.31	zwanzig%
8	35709	3.32	21%
9	35659	3.33	21%
10	33590	3.53	25%
elf	33036	3.59	27%

Wie Sie sehen können, umgeht Brotli auf allen Komprimierungsstufen Gzip. Bei der mit Brotli verfügbaren maximalen Komprimierungsstufe ist es 27% effizienter als Gzip.

Aufgrund persönlicher Beobachtungen stelle ich fest, dass der Übergang eines meiner Kunden von Gzip zu Brotli zu einer mittleren Reduzierung der Dateigröße um 31% führte.

Infolgedessen habe ich in den letzten Jahren zusammen mit anderen Leistungsexperten Kunden ermutigt, von Gzip zu Brotli zu wechseln.

Ich werde ein paar Worte zur Browserunterstützung für Gzip und Brotli sagen. Gzip ist so weit verbreitet, dass CanIUse nicht einmal eine Tabelle mit Supportinformationen anzeigt. Es heißt so: "Dieser HTTP-Header wird in fast allen Browsern unterstützt (beginnend mit IE6 +, Firefox 2+, Chrome 1+ usw.)." Und Brotli genießt beim Schreiben dieses Materials eine sehr angenehme Unterstützung.bei 93,17%. Und das ist sehr, sehr viel! Wenn Ihre Website also mindestens eine signifikante Größe hat, gefällt Ihnen die Rückgabe unkomprimierter Ressourcen an mehr als 6% Ihrer Benutzer möglicherweise nicht besonders gut. Mit Brotli verlieren Sie jedoch nichts. Kunden verwenden ein progressives Unterstützungsmodell für neue Algorithmen, sodass Benutzer, die keine Brotli-Ressourcen akzeptieren können, einfach die Fallback-Option in Form von Gzip verwenden. Wir werden weiter unten mehr darüber sprechen.

Im Allgemeinen, insbesondere wenn Sie CDN verwenden, ist das Einschalten von Brotli eine Frage von Sekunden. Zumindest ist dies bei Cloudflare der Fall, dem Dienst, den ich für die CSS Wizardry-Site verwende. Viele meiner Kunden sind jedoch nicht so erfolgreich, wenn wir über die letzten Jahre sprechen. Einige von ihnen unterstützen ihre eigene Infrastruktur, und die Praxis zeigt, dass die Installation und Bereitstellung von Brotli nicht so einfach ist. Einige verwenden CDN-Dienste, die sich in ihren leicht zugänglichen Funktionen nicht unterscheiden, um den neuen Algorithmus zu unterstützen.

In den Fällen, in denen wir nicht zu Brotli wechseln konnten, hatten wir immer eine unbeantwortete Frage: "Was wäre wenn ...". Infolgedessen entschied ich mich schließlich, mich mit Zahlen zu bewaffnen und eine Antwort auf die Frage zu geben, was der Site den Übergang zu Brotli gibt.

Weniger ist nicht unbedingt schneller.

Normalerweise bedeutet "weniger" jedoch "schneller". Wenn Sie die Dateigröße reduzieren, wird diese in der Regel schneller vom Server zum Client übertragen. Wenn Sie eine Datei beispielsweise um 20% verkleinern, bedeutet dies nicht, dass sie 20% schneller ankommt. Der Punkt hier ist, dass die Dateigröße nur ein Aspekt der Webleistung ist. Unabhängig von der Größe der Datei ist die an den Browser gelieferte Ressource mit vielen anderen Faktoren und vielen Systemeinschränkungen verbunden - Netzwerkverzögerungen, Paketverlust und dergleichen. Mit anderen Worten, das Einsparen der Dateigröße hilft dabei, dieselben Daten wie zuvor zu übertragen und weniger Pakete zu senden. Die Datenübertragung zwischen dem Server und dem Client wird jedoch durch Netzwerkverzögerungen begrenzt. Infolgedessen ändert sich die Geschwindigkeit, mit der Pakete am Client ankommen, nicht.

TCP, Pakete, Roundtrip-Verzögerung

Wenn es sehr einfach ist, Dateien vom Server auf den Client zu übertragen, müssen wir uns das TCP-Protokoll ansehen. Wenn wir eine Datei vom Server erhalten, kommt sie nicht auf einmal zu uns. Das TCP-Protokoll, auf dem HTTP funktioniert, unterteilt die Dateien in Segmente, die als Pakete bezeichnet werden. Diese Pakete werden der Reihe nach nacheinander an den Client gesendet. Der Client bestätigt den Empfang jedes Pakets in der Serie, bevor er mit der Übertragung der nächsten Serie beginnt. Dies geschieht so lange, bis der Client alle erforderlichen Pakete sammelt, bis keine nicht gesendeten Pakete auf dem Server vorhanden sind und bis der Client die Pakete in einer Datei sammeln kann, die als Datei erkannt werden kann. Damit die Paketsequenzübertragungssitzung erfolgreich abgeschlossen werden kann, muss der Server sie an den Client senden und der Client muss ihren Empfang bestätigen. Zeit,Die Datenmenge, die zum Empfangen von Daten und zum Empfangen einer Empfangsbestätigung erforderlich ist, wird als Round Trip Time (RTT) bezeichnet.

Jede neue TCP-Verbindung kann nicht wissen, wie hoch die verfügbare Bandbreite ist und wie zuverlässig die Verbindung ist (dh wie hoch der Paketverlust ist). Wenn der Server versucht, Megabyte Daten über eine Verbindung zu senden, die eine Datenübertragungsrate von einem Megabit pro Sekunde unterstützt, überfordert eine solche Übertragung die Verbindung und führt zu einer Überlastung des Kommunikationskanals. Und umgekehrt: Wenn der Server versucht, eine kleine Datenmenge über eine sehr schnelle Verbindung zu übertragen, wird die Verbindung ineffizient verwendet und ist inaktiv.

Um dieses Rätsel zu lösen, verwendet TCP einen Mechanismus, der als langsamer Start bezeichnet wird. Dies ist Teil der Überlastungsfenster-Verwaltungsstrategie. Jede neue TCP-Verbindung ist durch die Fähigkeit begrenzt, nur 10 Datenpakete in der ersten Paketsequenz zu senden (10 Pakete - die Größe des anfänglichen Überlastungsfensters). Zehn TCP-Segmente enthalten ungefähr 14 KB Daten. Wenn diese Pakete erfolgreich vom Client empfangen werden, enthält die zweite Serie bereits 20 Pakete, dann 40, 80, 160 usw. Das exponentielle Wachstum von Paketen in Sequenzen wird fortgesetzt, bis eines der folgenden Ereignisse eintritt:

Das System wird Paketverlust erleiden. Zu diesem Zeitpunkt reduziert der Server die Anzahl der Pakete in der folgenden Reihenfolge, dividiert die vorherige Anzahl der Pakete durch 2 und versucht erneut, die Daten zu übertragen.
Wir haben die Grenze der verfügbaren Bandbreite erreicht und können sie mit voller Kapazität nutzen.

Diese einfache und elegante Strategie ermöglicht es Ihnen, am Rande von Vorsicht und Optimismus zu balancieren. Dies gilt für jede neue TCP-Verbindung, die von der Webanwendung hergestellt wird.

Mit einfachen Worten, die anfängliche Größe des Überlastungsfensters der neuen TCP-Verbindung beträgt nur etwa 14 KB. Oder ungefähr 11,8% der unkomprimierten ReactDOM-Daten. Entweder 36,94% der mit Gzip komprimierten Daten oder 42,38% der mit Brotli komprimierten Daten (bei maximaler Komprimierungsstufe).

Und dann werden wir langsamer. Der Übergang von 11,8% auf 36,94% ist bereits eine spürbare Verbesserung! Aber der Übergang von 36,94% auf 42,38% - das ist alles andere als beeindruckend. Was ist los?

Datensitzungsnummer	Die in einer Sitzung übertragene Datenmenge, Kb	Kumulierte Datenmenge, Kb	Die Reihenfolge, in der die ReactDOM-Daten übertragen werden
1	14	14
2	28	42	Gzip (37,904 Kb), Brotli (33,036 Kb)
3	56	98
4	112	210	Unkomprimierte Option (118,656 Kb)
5	224	434

Es stellt sich heraus, dass sowohl mit Gzip komprimierte als auch mit Brotli komprimierte Daten in derselben Paketserie übertragen werden. Das Übertragen einer Datei dauert zwei Sequenzen. Wenn sich herausstellt, dass die RTT bei der Übertragung aller Sequenzen ziemlich einheitlich ist, bedeutet dies, dass die Übertragung von mit Gzip und Brotli komprimierten Daten dieselbe Zeit in Anspruch nimmt. Andererseits erfordert das Übertragen einer unkomprimierten Datenversion vier Paketreihen, nicht zwei. Dies kann insbesondere bei Verbindungen mit hohen Netzwerklatenzen zu einer spürbaren Zeit führen, die für die Datenübertragung erforderlich ist.

Ich tendiere hier dazu, dass die Geschwindigkeit der Datenübertragung nicht nur von der Dateigröße abhängt. Es wird von den Funktionsmerkmalen des TCP-Protokolls beeinflusst. Wir müssen die Dateien nicht nur verkleinern. Wir müssen sie viel kleiner machen und auf eine Größe bringen, die es ihnen ermöglicht, in weniger Paketsequenzen übertragen zu werden.

Dies bedeutet theoretisch, dass der Brotli-Algorithmus Daten wesentlich aggressiver komprimieren kann, damit er spürbar effizienter als Gzip ist. Dies ist notwendig, damit Daten in weniger Paketsequenzen übertragen werden können als bei Verwendung von Gzip. Und ich weiß nicht, wie sich dieser Algorithmus entwickeln wird ...

Es ist erwähnenswert, dass das obige Modell ziemlich vereinfacht ist. Es gibt viele andere Faktoren zu berücksichtigen. Zum Beispiel - ist es eine neue oder bereits offene TCP-Verbindung? Wird die Verbindung für etwas anderes verwendet? Stoppen und starten Priorisierungsmechanismen für den Serververkehr die Datenübertragung? Haben H / 2-Streams exklusiven Zugriff auf die Bandbreite? Dieser Abschnitt ist eine ernstere Studie. Es sollte als guter Ausgangspunkt für Ihre eigene Forschung angesehen werden. Aber überlegen Sie sich, die Daten gründlich mit etwas wie Wireshark zu analysieren, und lesen Sie dieses Material, das eine tiefere Beschreibung der „Magie“ der ersten 14 KB enthält.

Dies gilt nur für brandneue TCP-Verbindungen. Dateien, die über eine vorhandene Verbindung übertragen werden, werden nicht langsam gestartet. Dies führt uns zu zwei wichtigen Schlussfolgerungen:

Ich denke nicht, dass es sich lohnt, es zu wiederholen, aber ich werde es wiederholen: statische Ressourcen müssen gehostet werden. Dies ist eine großartige Möglichkeit, Verzögerungen beim langsamen Start zu vermeiden, da die Verwendung Ihres eigenen, bereits „aufgewärmten“ Servers bedeutet, dass Pakete, die diesen Server verlassen, Zugriff auf eine größere Bandbreite haben. Diese Schlussfolgerung führt mich zur zweiten Schlussfolgerung.
, , . , . .

	, ,	,
1	14	14
2	28	42
3	56	98
4	112	210
5	224	434
6	448	882
7	896	1778
8	1792	3570
9	3584	7154
10	7168	14322
…	…	…
20	7340032	14680050

Am Ende der 10. Datenübertragungssitzung beträgt die in einer Sitzung übertragene Datenmenge 7168 KB, während insgesamt bereits 14322 KB Daten übertragen wurden. Dies ist mehr als genug für normale Arbeiten im Internet (dh nicht zum Anzeigen des Game of Thrones). Tatsächlich kommt es normalerweise vor, dass wir die gesamte Webseite und alle ihre Ressourcen laden, ohne die Grenze unserer Bandbreite zu erreichen. Mit anderen Worten, die Verwendung eines Glasfaserkommunikationskanals mit 1 Gbit / s (dh 0,125 GB / s) lässt das normale Surfen nicht viel schneller erscheinen als die Verwendung einer langsameren Verbindung, da der größte Teil dieses Kanals nicht gleichmäßig ist wird verwendet.

Und bis zur 20. Datenübertragungssitzung übertragen wir theoretisch 7,34 GB Daten in einer Paketsequenz.

Was ist mit der realen Welt?

Bisher haben wir uns mit theoretischen Überlegungen befasst. Und ich habe angefangen, an diesem Material zu arbeiten, weil ich gerne wissen möchte, welche Auswirkungen Brotli auf reale Websites haben kann.

Bisher haben die hier angegebenen Zahlen auf den großen Unterschied zwischen dem Mangel an Komprimierung und der Verwendung von Gzip und der Tatsache hingewiesen, dass der Gewinn durch die Verwendung von Brotli im Vergleich zu Gzip recht gering ist. Dies zeigt uns, dass der Übergang von der fehlenden Komprimierung zur Verwendung von Gzip eine spürbare Verbesserung bringt, während der Übergang von Gzip zu Brotli wahrscheinlich weniger beeindruckend aussieht.

Ich habe als Beispiele mehrere Websites ausgewählt, die sich an folgenden Überlegungen orientieren:

Die Site sollte relativ bekannt sein (es ist besser, Sites zu verwenden, die mit etwas verglichen werden können).
Die Stelle sollte für den Test geeignet sein. Das heißt - es sollte eine geeignete Größe haben (daher ist es interessanter, seine Materialien auf Komprimierung zu analysieren) und gleichzeitig nicht hauptsächlich Materialien enthalten, die nicht mit Gzip / Brotli komprimiert wurden - wie zum Beispiel YouTube.
Nicht alle Websites aus der Sammlung sollten großen Unternehmen gehören (es lohnt sich, einige, beispielsweise „normale“ Websites, zu analysieren).

Angesichts dieser Anforderungen habe ich die unten aufgeführten Websites ausgewählt und mit dem Testen begonnen. Hier sind die Websites, die ich ausgewählt habe:

Ich wollte die Tests nicht komplizieren und habe mich daher auf folgende Indikatoren festgelegt:

Die Menge der übertragenen Daten.
Erste FCP-Zeit (Contentful Paint).

Sie wurden in folgenden Situationen analysiert:

Fehlende Komprimierung.
Mit gzip.
Mit brotli.

Die FCP-Metrik kommt der realen Welt nahe und ist universell genug für ihre Anwendung auf jede Site, da Sie damit bewerten können, was Benutzer von Websites benötigen - dh den Inhalt dieser Sites. Darüber hinaus habe ich mich für diese Metrik entschieden, weil Paul Calvano , ein intelligenter Mensch, Folgendes sagte: „Die Erfahrung zeigt, dass die Verwendung von Brotli zu einem verbesserten FCP führt, insbesondere wenn kritische CSS / JS-Ressourcen groß sind.“ .

Testen

Ich werde dir ein schmutziges Geheimnis verraten. Viele Studien zur Webleistung (nicht alle, aber viele) basieren nicht auf Untersuchungen zu Leistungsverbesserungen, sondern auf Schlussfolgerungen aus dem Gegenteil - aus Leistungseinbußen. Zum Beispiel ist es für die BBC viel einfacher zu behaupten, dass "sie 10% der Benutzer für jede zusätzliche Sekunde verlieren, die sie zum Laden ihrer Website benötigen", als herauszufinden, was dank einer Verbesserung von einer Sekunde passiert. Es ist viel einfacher, die Website zu verlangsamen, als sie zu beschleunigen, und Sie haben das Gefühl, dass dies der Grund ist, warum viele Leute diesen Job so gut machen.

Vor diesem Hintergrund habe ich nicht versucht, zuerst Websites herunterzuladen, die Gzip verwenden, und dann offline ihren Inhalt mithilfe von Brotli irgendwie zu komprimieren. Stattdessen habe ich Websites gefunden, die Brotli verwenden, und dann die Komprimierung deaktiviert. Ich ging von Brotli zu Gzip und dann von Gzip zu Non-Compression, um zu messen, wie dies auf der Site funktioniert.

Obwohl ich beispielsweise keine Verbindung zum Linkedin-Server herstellen und Brotli nicht trennen kann, kann ich einfach über einen Browser auf diese Site zugreifen, der Brotli nicht unterstützt. Obwohl ich die Brotli-Unterstützung in Chrome nicht deaktivieren kann, kann ich die Tatsache, dass mein Browser Brotli unterstützt, vor dem Server verbergen. Browser teilen den Servern mithilfe des Anforderungsheaders mit, welche Komprimierungsalgorithmen sie unterstützencontent-encoding. Mit Webpagetest kann ich die Header selbst anpassen. Also ist alles sehr einfach!

Mit den erweiterten Funktionen von WebPageTest können wir benutzerdefinierte Anforderungsheader festlegen.

So richte ich das Feld Benutzerdefinierte Header ein:

Vollständiges Herunterfahren der Komprimierung : accept-encoding: randomstring.
Deaktivieren von Brotli, aber Gzip-Unterstützung : accept-encoding: gzip.
So verwenden Sie Brotli, wenn diese Komprimierungsmethode von der Site unterstützt wird (und sofern sie vom Browser unterstützt wird): Das Feld bleibt leer.

Sie können herausfinden, ob dies wie beabsichtigt funktioniert, indem Sie das Vorhandensein (oder Fehlen) des Headers content-encodingin der Serverantwort überprüfen .

Ergebnisse

Wie erwartet bedeutete der Übergang von mangelnder Komprimierung zu Gzip eine signifikante Verbesserung, aber der Übergang von Gzip zu Brotli sieht nicht so beeindruckend aus. Die Rohdaten aus meinen Experimenten finden Sie hier . Die folgenden Ergebnisse interessieren mich am meisten:

Gzip : 73%.
FCP Gzip : 23.305%.
Brotli Gzip: 5.767%.
FCP Brotli Gzip: 3.462%.

Dies sind alles Medianwerte. Apropos "Materialgrößen", ich meine nur HTML, CSS und JavaScript.

Dank der Verwendung von Gzip konnten die Dateigrößen im Vergleich zu unkomprimierten Versionen um 73% reduziert werden. Durch die Verwendung von Brotli konnte die Dateigröße nur um weitere 5,7% reduziert werden. Wenn wir über FCP sprechen, verbesserte sich dieser Indikator dank Gzip um 23% im Vergleich zur fehlenden Komprimierung, und Brotli fügte nur weitere 3,5% hinzu.

Obwohl solche Ergebnisse die Theorie zu bestätigen scheinen, gibt es verschiedene Möglichkeiten, diese Ergebnisse zu verbessern. Das erste ist, eine viel größere Anzahl von Websites zu testen. Ich möchte zwei weitere detaillierter diskutieren.

Eigene Ressourcendaten und Daten aus externen Quellen

In meinen Tests habe ich Brotli überall ausgeschaltet, nicht nur für Server, auf denen Standortdaten gespeichert sind. Dies bedeutet, dass ich nicht nur die Vorteile gemessen habe, die Websites durch die Verwendung von Brotli erhalten, sondern auch die Vorteile, die Brotli aus den externen Quellen dieser Websites zieht. Dies fällt nur dann in den Bereich unserer Interessen, wenn Ressourcen von Drittanbietern auf kritische Weise für die untersuchten Websites verwendet werden. Dies ist jedoch erwähnenswert.

Komprimierungsstufen

Apropos Komprimierung: Wir diskutieren häufig die Ergebnisse, die mit dem besten Komprimierungsanwendungsszenario erzielt wurden. Nämlich - wenn wir Gzip verwenden, denken wir an die 9. Komprimierungsstufe und wenn wir Brotli verwenden - an die 11. Stufe. Es ist jedoch unwahrscheinlich, dass der untersuchte Server optimal konfiguriert wird. Zum Beispiel verwendet Apache die gzip-Komprimierung der Stufe 6, während NGINX nur die erste verwendet.

Das Deaktivieren von Brotli bedeutet, dass wir zur Fallback-Option, zu Gzip, wechseln. Angesichts der Art und Weise, wie ich die Websites getestet habe, konnte ich eine solche Fallback-Konfiguration nicht ändern oder irgendwie darauf reagieren. Ich sage das, weil die Materialien der beiden Stellen im Test tatsächlich größer wurden, als Brotli eingeschaltet wurde. Dies zeigt mir, dass der Grad der Gzip-Komprimierung so war, dass er eine stärkere Komprimierung lieferte als der Grad der Brotli-Komprimierung.

Die Auswahl einer Komprimierungsstufe ist ein Kompromiss. Jeder möchte nach der höchsten Komprimierungsstufe fragen und diesbezüglich das Problem als gelöst betrachten. Ein solcher Ansatz ist jedoch unpraktisch. Tatsache ist, dass die zusätzliche Zeit, die der Server benötigt, um diese Komprimierung dynamisch durchzuführen, sehr wahrscheinlich die Vorteile einer höheren Komprimierungsstufe zunichte macht. Um dieses Problem zu lösen, können Sie auf Folgendes zurückgreifen:

Sie können eine pragmatische Komprimierungsstufe verwenden, die das richtige Gleichgewicht zwischen Geschwindigkeit und Effizienz bei der dynamischen Datenkomprimierung bietet.
Sie können vorkomprimierte statische Ressourcen auf den Server hochladen, deren Komprimierungsstufe höher ist als die für die dynamische Komprimierung verwendete. In diesem Fall können Sie zur Auswahl der Stufe der dynamischen Komprimierung die im ersten Absatz beschriebene Idee verwenden.

Zusammenfassung

Man hat den Eindruck, dass man vernünftigerweise die Bedeutungslosigkeit von Brotlis Vorteilen gegenüber Gzip erkennen kann.

Wenn das Aktivieren der Brotli-Unterstützung nur einige Mausbewegungen im Bedienfeld Ihres CDN erfordert, sollten Sie Brotli nehmen und sofort einschalten. Die Unterstützung für diesen Komprimierungsalgorithmus ist breit genug, Browser, die Brotli nicht unterstützen, wechseln problemlos zu Ersatzmechanismen, und selbst eine geringfügige Verbesserung ist besser als nichts.

Laden Sie nach Möglichkeit statische Ressourcen, die mit der maximalen Komprimierungsstufe vorkomprimiert wurden, auf die Server hoch. Verwenden Sie für die dynamische Komprimierung nicht die höchste, sondern nicht die niedrigste Komprimierungsstufe. Wenn Sie NGINX verwenden, stellen Sie sicher, dass Sie nicht die standardmäßige erste Komprimierungsstufe für NGINX verwenden.

Wenn Sie jedoch für die Verwendung von Brotli möglicherweise wochenlanges Entwickeln, Testen und Bereitstellen benötigen, geraten Sie nicht in Panik. Stellen Sie nur sicher, dass Sie die Gzip-Komprimierung für alles verwenden, was komprimiert werden kann (dazu gehören neben Textressourcen auch Dateien .ico und .ttf - wenn sie natürlich in Ihrem Projekt verwendet werden).

Ich nehme an, eine kurze Version dieses Artikels könnte folgendermaßen aussehen: Wenn Sie Brotli nicht aktivieren sollten oder können, verlieren Sie nicht so viel.

Liebe Leser! Planen Sie Brotli zu verwenden?

Brotli Effizienz in der realen Welt