CMSJuli 2021

Brotli: Eine lohnende Alternative zur JSON-Kompression

Eine ständige Herausforderung für eine Website ist es, die bestmögliche User Experience zu erreichen. Als CMS-Anbieter wissen wir, dass die Optimierung der Größe der an den Browser gesendeten Dateien die Ladezeit einer Seite drastisch verkürzen kann. Schnellere Ladezeiten von Seiten führen zu mehr und zufriedeneren Nutzern, einer niedrigeren Absprungrate und besseren Google-Rankings.

Dieser Artikel behandelt die Vorteile der Brotli-Kompression beim Senden von JavaScript und anderen Assets an den Browser und wie ein Website-Besitzer oder DevOps-Team sicherstellen kann, dass sie für Ihre AWS CloudFront-Distribution aktiviert ist.

Der Weg zu Brotli

Bei dem ständigen Versuch, unsere Website-Ladegeschwindigkeit zu optimieren, stellten wir fest, dass eine der größten Nutzlasten einer Seite der Scrivito-Content-Dump ist. Dies ist eine JavaScript-Datei, die ein großes stringifiziertes JSON-Objekt enthält. Es wird verwendet, um alle CMS-Daten vorzuladen, die für das anfängliche Rendern der Seite erforderlich sind.

In der Überlegung, ob die Kosten der Nutzlast reduziert werden können, haben wir einige Recherchen zur JSON-Kompression durchgeführt. Sehr bald stießen wir auf Aussagen wie diese auf Reddit, mit einer bemerkenswerten abschließenden Antwort:

[FRAGE] Suche nach Möglichkeiten, JSON signifikant zu komprimieren. Irgendwelche Vorschläge?

"Haben Sie sich Brotli angesehen? Sie können eine ziemlich gute Kompression erreichen (im Allgemeinen besser als gzip) auf Stufe 11"

Oder, wie eine der existierenden Kompressionsbibliotheken, "brick.json", in ihrer Readme-Datei angibt:

"Empfehlung

Für die Datenübertragung vom Server zum Client wählen Sie Google Brotli"

Vielleicht haben Sie schon von Brotli gehört. Bei unseren Recherchen fanden wir einige mehr und weniger relevante Details:

  • Es wurde nach einem Schweizerdeutschen Brötchen benannt (Brötli), was erklärt, warum es für Nicht-Schweizerdeutsche obskur und etwas lustig klingen mag.
  • Brotli wurde von Jyrki Alakuijala und Zoltán Szabadka entwickelt. Beide arbeiten bei Google Research Europe in Zürich und haben eine sehr lange Erfolgsbilanz in der Kompressionsforschung in allen Richtungen. Diese Leute wissen also definitiv, wovon sie sprechen.
  • Was Brotli anderen Algorithmen überlegen macht, ist das riesige Wörterbuch, mit dem es ausgestattet ist. Es enthält die häufigsten Wörter, die in mehreren natürlichen und Computersprachen gefunden wurden.

Der aktuelle Stand von Brotli

Brotli hat in den letzten Jahren viel Aufmerksamkeit erhalten, da alle großen Browser Unterstützung dafür hinzugefügt haben, gefolgt von großen Plattformanbietern. Netlify zum Beispiel hat Brotli für ihre Kunden verfügbar gemacht. Auch AWS kündigte es letzten September an und erklärte:

"Brotli ist sofort und ohne zusätzliche Kosten verfügbar."

Da wir AWS CloudFront für die Bereitstellung von Assets für unsere und die Websites unserer Kunden verwenden, fragten wir uns, warum sie bei einigen Seiten mit dem weniger modernen gzip-Inhaltstyp übertragen wurden.

Wird dieses spezifische Asset mit Brotli (br) Kompression ausgeliefert?

curl https://www.example.com/my_asset.js -o /dev/null -v \
-H "Accept-Encoding: deflate, gzip, br" 2>&1 | grep content-encoding

< content-encoding: gzip

Offensichtlich nicht. Wir hatten die Einstellungen in der AWS-Konsole überprüft, und sie sahen gut aus. Die Standard-CloudFront-Richtlinie hat Brotli aktiviert. Warum funktionierte es also nicht von Anfang an?

Wir nahmen an, dass Brotli nicht auf CloudFront-Distributionen angewendet wurde, die erstellt wurden, bevor AWS die neue Kompressionsfunktion hinzugefügt hatte. Aber es gab keinen eindeutigen Hinweis in der Dokumentation.

Beim dritten Blick entdeckten wir dieses kleine Juwel: Eine Option, die auf eine magische Alteinstellung gesetzt war.

Einrichten von CloudFront

Um dorthin in der AWS-Konsole zu gelangen:

  • Klicken Sie auf Ihre CloudFront-Distribution,
  • wählen Sie den Tab "Behaviors",
  • überprüfen Sie in der Liste das Verhalten (in unserem Fall gab es nur "Default"),
  • klicken Sie auf die Schaltfläche "Edit",
  • finden Sie die "Cache and origin request settings".

Ändern Sie nun "Use legacy cache settings" zu "Use a cache policy and origin request policy" und bestätigen Sie durch Klicken auf "Yes, Edit."

curl https://www.example.com/my_asset.js -o /dev/null -v \
-H "Accept-Encoding: deflate, gzip, br" 2>&1 | grep content-encoding

< content-encoding: gzip

Zweistellige Einsparungen

Ein zweistelliger prozentualer Rückgang der Bandbreitennutzung, mit vernachlässigbarem Dekompressionsaufwand, kostenlos! Nur durch Überprüfen und Anpassen der Einstellungen.

Wenn Sie nicht sicher sind, ob Ihre Assets bereits mit Brotli komprimiert sind, empfehlen wir Ihnen dringend, einen Blick darauf zu werfen!

Bezüglich der Erkenntnisse über JSON-Kompression (kurz zusammengefasst):

Die Verwendung der Brotli-Kompression ist der richtige Ansatz für die Server-Client-Kommunikation.

Die Hälfte der existierenden JSON-Kompressionsbibliotheken würde tatsächlich die komprimierte Nutzlast vergrößern und zusätzlich einen Rechenaufwand hinzufügen.

Erkenntnisse

  • An den richtigen Schrauben zu drehen, kann sich lohnen.
  • Vorheriges Messen und Analysieren verhindert, dass man sich in die falsche Richtung bewegt.
  • Auch Ankündigungen von Dienstieistern können wirklich lesenswert sein.
  • Manchmal reicht es aus, einfach eine neue Einstellung zu aktivieren.