Höhere Komprimierungseffizienz mit gemeinsam genutzten Wörterbüchern

Jeremy Wagner

Die Datenkomprimierung ist eine bewährte Methode zur Leistungsoptimierung, mit der die Größe geeigneter Seitenressourcen reduziert wird. Lange Zeit war es üblich, hauptsächlich gzip auf Webservern zu verwenden, um gängige textbasierte Seitenressourcen wie HTML-, CSS- und JavaScript-Dateien zu komprimieren und an den Client zu senden, wo sie dekomprimiert werden konnten. Das führt zu kürzeren Ladezeiten für Ressourcen, ohne dass sich das beabsichtigte Verhalten einer Seite ändert.

Obwohl gzip an sich sehr effektiv ist, wurden in den letzten Jahren weitere Verbesserungen bei der Komprimierung im Web erzielt. 2016 wurde der Brotli-Algorithmus in Chrome eingeführt, wodurch für infrage kommende Ressourcen insgesamt bessere Komprimierungsraten erzielt wurden. Ende 2017 wurde Brotli von allen modernen Browsern unterstützt und die Serverunterstützung für Brotli wurde immer weiter ausgebaut. In letzter Zeit wurde in Chrome die ZStandard-Komprimierung eingeführt.

Aber damit ist noch nicht Schluss. Das Chrome-Team hat daran gearbeitet, freigegebene Wörterbücher für das Web nutzbar zu machen. Diese sind jetzt in einem Ursprungstest sowohl für Brotli als auch für ZStandard verfügbar. Gemeinsam genutzte Wörterbücher können die Brotli- und ZStandard-Komprimierung ergänzen, um wesentlich höhere Komprimierungsraten für Websites zu erzielen, auf denen häufig aktualisierter Code bereitgestellt wird. In einigen Fällen können Komprimierungsraten von 90% oder mehr erreicht werden. In diesem Beitrag erfahren Sie mehr darüber, wie freigegebene Wörterbücher funktionieren und wie Sie sich für die Ursprungstests registrieren können, um sie für Brotli und ZStandard auf Ihrer Website zu verwenden.

Geteilte Wörterbücher

Bei der Komprimierung werden redundante Sequenzen in einer Eingabe gefunden und anhand dieser Informationen eine viel kleinere Ausgabe erstellt, die später wiederhergestellt werden kann. Die Komprimierung funktioniert gut im Web, da sie die Ressourcenladezeiten erheblich reduziert. Sowohl Brotli als auch ZStandard können durch die Verwendung eines Komprimierungswörterbuchs noch effizienter werden. Dabei handelt es sich um eine Sammlung zusätzlicher Muster, die diese Algorithmen bei der Komprimierung verwenden können. Die hohe Effizienz von Brotli wird in gewissem Maße durch die Verwendung eines internen Wörterbuchs erreicht.

Mit Brotli und ZStandard können jedoch benutzerdefinierte Wörterbücher verwendet werden, die Muster für bestimmte Ressourcen enthalten. In der Praxis ist ein benutzerdefiniertes Wörterbuch eine externe Datei, die auf jede Eingabe angewendet werden kann. Wörterbücher können sehr spezifisch für den Produktionscode einer Anwendung oder für beliebige Inhalte sein. Die Eignung eines bestimmten Wörterbuchs für die Eingabe kann sich stark auf die Gesamteffizienz der Komprimierung auswirken. Wörterbücher, die dem Inhalt einer Eingabe sehr ähnlich sind, liefern eine Ausgabe mit einem höheren Komprimierungsverhältnis als Wörterbücher mit generischen oder unterschiedlichen Inhalten.

Hier ein Beispiel dafür, wie effektiv ein benutzerdefiniertes Komprimierungswörterbuch sein kann: Angenommen, Ihre Website verwendet das Angular-Framework und Sie verwenden die aktuelle Version 1.7.9. Diese Version des Angular-Frameworks hat unkomprimiert etwa 172 KiB. Bei der Komprimierung mit den Standardeinstellungen von Brotli beträgt die Größe etwa 53 KiB. Das ergibt ein Komprimierungsverhältnis von fast 70 %. Angenommen, Sie entscheiden sich später für ein Upgrade auf Angular 1.8.3. Da diese Version von Angular ungefähr die gleiche Größe wie Version 1.7.9 hat, können Sie mit ungefähr demselben Komprimierungsverhältnis wie bei der vorherigen Version rechnen.

Hier kann ein benutzerdefiniertes Wörterbuch mithilfe eines Prozesses namens Deltakomprimierung nützlich sein. Dabei wird ein Wörterbuch einer früheren Version einer Ressource verwendet , um eine spätere Version zu komprimieren. Wenn Sie im vorherigen Beispiel Version 1.8.3 von Angular mit Version 1.7.9 als Wörterbuch komprimieren, würde die Ausgabe knapp über 4 KiB betragen. Das entspricht einem Komprimierungsverhältnis von fast 98%. Komprimierungswörterbücher können sich eindeutig stark auf die Ladeleistung auswirken. Ihre Effektivität wurde bereits in realen Anwendungen nachgewiesen.

Es ist jedoch eine Herausforderung, diesen Ablauf im Web zu implementieren. Der Haken dabei ist, dass Sie dasselbe Wörterbuch verwenden müssen, um die Dekomprimierung vorzunehmen. Dieser Ablauf wurde bereits im Web versucht – nämlich SDCH –, war aber nur schwer sicher zu implementieren. Dieser aktuelle Vorschlag für die Komprimierung von freigegebenen Wörterbüchern behebt diese Bedenken und bietet gleichzeitig einen erheblichen Vorteil sowohl für statische als auch für dynamische Ressourcen.

Wie Chrome die Unterstützung für freigegebene Wörterbücher anpreist

Alle Browser geben die von ihnen unterstützten Komprimierungsalgorithmen über den Accept-Encoding-Anfrageheader an. Der Inhalt des Headers ist eine durch Kommas getrennte Liste der unterstützten Codierungen:

Accept-Encoding: gzip, br, zstd

Dieser Accept-Encoding-Header gibt an, dass der Browser, der die Ressource anfordert, die Komprimierungsalgorithmen gzip, Brotli und ZStandard unterstützt. Ein Webserver, der auf die Anfrage antwortet, kann dann entscheiden, welchen Algorithmus er bei der Beantwortung der Anfrage verwenden soll.

Wenn die Unterstützung für freigegebene Wörterbücher aktiviert ist und ein relevantes Wörterbuch für eine Ressource verfügbar ist, werden der Accept-Encoding-Überschrift zusätzliche Tokens hinzugefügt. Diese Tokens sind br-d für Brotli und zstd-d für Zstandard. Chrome enthält auch den Hash eines verfügbaren Wörterbuchs, das im Folgenden beschrieben wird.

Accept-Encoding: gzip, br, zstd, br-d, zstd-d
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

Wenn ein Webserver so konfiguriert ist, dass er dieses Token und das Wörterbuch erkennt, kann er auf diese Anfrage mit einer Ressource antworten, die mit dem Wörterbuch für die entsprechende Codierung komprimiert wurde. Wie dies in der Praxis erreicht wird, hängt davon ab, ob es sich bei der Anfrage um eine statische oder dynamische Ressource handelt.

Komprimierung mit freigegebenen Wörterbüchern für statische Ressourcen

Eine statische Seitenressource liefert für eine angeforderte URL immer dieselbe Antwort. Gängige Beispiele für komprimierbare Ressourcen statischer Seiten sind JavaScript- und CSS-Dateien. Diese Ressourcen werden in der Regel zu Caching-Zwecken auf irgendeine Weise versioniert – manchmal mit einem Hash des Dateiinhalts im Dateinamen (z. B. styles.abcd1234.css) oder einer anderen Methode zum Erstellen eines Fingerabdrucks der Ressource. Diese Ressourcentypen eignen sich hervorragend für die Deltakomprimierung, die von freigegebenen Wörterbüchern bereitgestellt wird, da statische Ressourcen häufig für lange Zeit im Cache gespeichert und in der Regel relativ häufig aktualisiert werden.

Für eine statische Ressource kann ein Wörterbuch angegeben werden, indem der Antwortheader Use-As-Dictionary dafür festgelegt wird. Der Header kann eines von mehreren Schlüssel/Wert-Paaren enthalten. Das einzige erforderliche Paar ist match, das die URLPattern-Syntax für den Ressourcenpfad akzeptiert, unter dem das Wörterbuch verwendet werden soll:

Use-As-Dictionary: match="/dist/styles.*.css"

Betrachten Sie die Use-As-Dictionary-Überschrift als Mechanismus, der auf zukünftige Versionen einer Ressource angewendet wird, die dem darin angegebenen Muster entsprechen. Angenommen, Ihre Website liefert alle Stile in einer einzigen CSS-Datei aus. Angenommen, die erste Version dieser Ressource befindet sich unter /dist/styles.v1.css und wird mit einem Use-As-Dictionary-Antwortheader mit dem match-Wert /dist/styles.*.css gesendet.

Nach einiger Zeit aktualisieren Sie das CSS Ihrer Website und stellen eine neue Version davon unter /dist/styles.v2.css bereit. Da der match-Wert, der in der Use-As-Dictionary-Antwortheader der vorherigen Version verwendet wurde, für diese Anfrage gilt, sendet der Browser einen Available-Dictionary-Header mit einem Hash des Wörterbuchs, der als Bytesequenz eines strukturierten Felds codiert ist:

Accept-Encoding: gzip, br, zstd, br-d, zstd-d
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

An dieser Stelle muss der Server die Komprimierung auf seiner Seite konfigurieren, um sicherzustellen, dass das passende Wörterbuch verwendet wird. Die mit diesem Wörterbuch komprimierte Ressource wird dann gesendet und mit dem verfügbaren Wörterbuch im Browsercache des Nutzers dekomprimiert.

Wenn Sie häufig neuen Code für Ihre Website veröffentlichen, kann die Deltakomprimierung sehr hilfreich sein. Der Vorgang ist jedoch flexibel. Wenn der Browser nicht feststellt, dass ein Wörterbuch im Browsercache des Nutzers verfügbar ist, werden die zusätzlichen br-d- oder zstd-d-Tokens im Accept-Encoding-Header nicht angegeben. In diesem Fall gilt der Standardkomprimierungsablauf.

Komprimierung mit freigegebenen Wörterbüchern für dynamische Ressourcen

Auch dynamische Ressourcen können von der gemeinsamen Wörterbuchkomprimierung profitieren. Dynamische Ressourcen ändern sich je nach Kontext. Ein Beispiel hierfür ist eine Nachrichtenwebsite, auf der die Startseite häufig aktualisiert wird, wenn es Neuigkeiten gibt. HTML-Dokumente sind oft dynamische Ressourcen. In solchen Fällen kann das Wörterbuch den Großteil der gemeinsamen HTML-Struktur und des Vorlagencodes der Website enthalten, was zu komprimierten Seiten führt, auf denen nur die eindeutigen Teile jeder Seite gesendet werden.

Aufgrund der Natur dynamisch generierter Ressourcen muss ein Wörterbuch zur späteren Verwendung auf dem Client geladen werden. Wenn Sie ein Wörterbuch vorab laden, ist die Komprimierung mit einem freigegebenen Wörterbuch auf dynamische Ressourcen spekulativ. In solchen Fällen wird gehofft, dass Ihre Website genügend Zugriffe erhält, damit sich die Wörterbuchkosten über eine große Anzahl von Navigationen amortisieren lassen. Wenn Sie es ausprobieren möchten, müssen Sie zuerst den Speicherort des Wörterbuchs über ein <link>-Element in der HTML-Seite angeben:

<link rel="dictionary" href="/dictionary.dat">

Wenn Chrome auf dieses <link>-Element stößt, kann es das Wörterbuch abrufen, sobald die Seite inaktiv ist, und zwar mit niedriger Priorität, um Bandbreitenkonflikte zu vermeiden. Die Antwort für das Wörterbuch selbst muss einen Use-As-Dictionary-Header und den dynamischen Ressourcenpfad angeben, auf den sie sich bezieht:

Use-As-Dictionary: match="/product/*"

Der Ablauf ist weitgehend derselbe wie bei statischen Ressourcen. Der Browser erkennt, dass das Wörterbuch selbst auf übereinstimmende Ressourcen angewendet wird, und fügt der Anfrage einen Available-Dictionary-Header mit einem Hash des Inhalts des Wörterbuchs hinzu, ähnlich wie beim oben beschriebenen Ablauf für statische Ressourcen.

Statische Ressourcen zur Buildzeit komprimieren

Wenn Sie mit Bundlern vertraut sind, kennen Sie vielleicht auch verschiedene Plug-ins für sie, mit denen Ressourcen zur Buildzeit komprimiert und anschließend bereitgestellt werden können. Beispielsweise können Sie mit Apache-Direktiven diese vorab komprimierten Ressourcen zum Zeitpunkt der Anfrage bereitstellen.

Die meisten Node.js-basierten Bundler, die die Komprimierung unterstützen, verwenden die integrierte Zlib-Bibliothek von Node. Zlib unterstützt Brotli und Bundler, die es verwenden, bieten in der Regel eine Schnittstelle, über die Optionen direkt an Zlib übergeben werden können, das die wörterbuchgestützte Komprimierung unterstützt. Hier sind einige Bundler, die die Verwendung von Wörterbüchern unterstützen:

Die für eine bestimmte Version einer Ressource verfügbaren Wörterbücher können eine beliebige der vorherigen Versionen der Ressource verwenden. Das bedeutet, dass Sie den Nutzertraffic analysieren und entsprechend planen müssen. Streben Sie nach einem Gleichgewicht und erstellen Sie Ressourcen, die möglichst vielen wiederkehrenden Nutzern zugutekommen. CDN-Anbieter experimentieren derzeit mit der gemeinsamen Komprimierung von Wörterbüchern. Es gibt noch keine Implementierungen für die öffentliche Nutzung, aber wir gehen davon aus, dass sich das bald ändern wird.

Jetzt ausprobieren!

Die Integration der Komprimierung mit freigegebenen Wörterbüchern in die vorhandenen Komprimierungsfunktionen des Browsers kann die Ladeleistung von Websites erheblich verbessern, die häufig aktualisierten Produktionscode bereitstellen und einen erheblichen Traffic von wiederkehrenden Besuchern erhalten. Wenn Sie die gemeinsame Wörterbuchkomprimierung ausprobieren möchten, haben Sie zwei Möglichkeiten:

  1. Wenn Sie die Komprimierung von freigegebenen Wörterbüchern selbst ausprobieren möchten, um ein Gefühl dafür zu bekommen, wie sie funktioniert, können Sie die experimentelle Funktion Komprimierter Wörterbuchtransport auf der Seite chrome://flags aktivieren.
  2. Wenn Sie diese Funktion auf Ihrer Produktionswebsite testen und herausfinden möchten, wie die gemeinsame Wörterbuchkomprimierung echten Nutzern helfen kann, registrieren Sie sich für den Origin-Test, um ein Token zu erhalten. Lesen Sie auch den Artikel So funktionieren Origin-Tests.

Fazit

Wir sind sehr gespannt auf diesen wichtigen Fortschritt bei der Komprimierungstechnologie im Web und darauf, wie viel schneller bestehende Anwendungen, die Nutzer täglich verwenden, dadurch werden könnten. Wir empfehlen dir, es auszuprobieren. Wir freuen uns auf dein Feedback. Wenn Sie einen Fehler finden, melden Sie ihn unter crbug.com. Weitere Ressourcen und Tools finden Sie unter use-as-dictionary.com. Wenn Sie mehr darüber erfahren möchten, wie das Tool funktioniert, sehen Sie sich die Erklärung an.