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

Jeremy Wagner

Veröffentlicht am 6. März 2024

Die Datenkomprimierung ist eine bewährte Technik zur Leistungsoptimierung, mit der die Größe geeigneter Seitenressourcen reduziert wird. Lange Zeit war es üblich, auf Webservern hauptsächlich gzip 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 Ergebnis sind kürzere Ladezeiten für Ressourcen, ohne das beabsichtigte Verhalten einer Seite zu beeinträchtigen.

Obwohl gzip an sich schon 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, der insgesamt bessere Komprimierungsverhältnisse für geeignete Ressourcen bietet. Ende 2017 unterstützten alle modernen Browser Brotli und die Serverunterstützung dafür wurde immer weiter verbreitet. Vor Kurzem wurde in Chrome die ZStandard-Komprimierung eingeführt.

Aber das ist noch nicht alles. Das Chrome-Team hat daran gearbeitet, freigegebene Wörterbücher im Web nutzbar zu machen. Diese sind jetzt in einer Ursprungstestversion für Brotli und ZStandard verfügbar. Freigegebene Wörterbücher können die Brotli- und ZStandard-Komprimierung ergänzen und so deutlich höhere Komprimierungsverhältnisse für Websites erzielen, auf denen häufig aktualisierter Code ausgeliefert wird. In einigen Fällen sind Komprimierungsverhältnisse von 90% oder mehr möglich. In diesem Beitrag erfahren Sie mehr darüber, wie freigegebene Wörterbücher funktionieren und wie Sie sich für die Origin-Testversionen registrieren können, um sie für Brotli und ZStandard auf Ihrer Website zu verwenden. Du kannst dir auch dieses Video ansehen:

Freigegebene Wörterbücher

Bei der Komprimierung werden redundante Sequenzen in einer Eingabe gesucht und diese Informationen verwendet, um eine viel kleinere Ausgabe zu erstellen, die später wieder umgekehrt werden kann. Die Komprimierung funktioniert im Web gut, da sie die Ladezeiten von Ressourcen erheblich verkürzt. Sowohl Brotli als auch ZStandard können ihre Effektivität durch die Verwendung eines Komprimierungswörterbuchs weiter steigern. 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 zum Teil durch die Verwendung eines internen Wörterbuchs erreicht.

Mit Brotli und ZStandard können jedoch auch benutzerdefinierte Wörterbücher verwendet werden, die von Nutzern erstellt wurden und Muster enthalten, die für bestimmte Ressourcen spezifisch sind. 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. Wie gut ein bestimmtes Wörterbuch für seine Eingabe geeignet ist, kann sich erheblich auf die allgemeine Komprimierungseffizienz auswirken. Wörterbücher, die den Inhalten einer Eingabe sehr ähnlich sind, führen zu Ausgaben mit höheren Komprimierungsverhältnissen als Wörterbücher mit allgemeinen oder unterschiedlichen Inhalten.

Ein Beispiel für die Effektivität eines benutzerdefinierten Komprimierungswörterbuchs: Angenommen, Ihre Website verwendet das Angular-Framework und die aktuelle Version ist 1.7.9. Diese Version des Angular-Frameworks ist unkomprimiert etwa 172 KiB groß. 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 einem ähnlichen Komprimierungsverhältnis wie bei der vorherigen Version rechnen.

Hier kann ein benutzerdefiniertes Wörterbuch hilfreich sein, indem ein Verfahren namens Delta-Komprimierung verwendet wird. Dabei kann ein Wörterbuch einer früheren Version einer Ressource verwendet werden, 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, beträgt die Ausgabe etwas mehr als 4 KiB. Das entspricht einem Komprimierungsverhältnis von fast 98%. Komprimierungswörterbücher können sich also erheblich auf die Ladeleistung auswirken und ihre Effektivität wurde bereits in realen Anwendungen nachgewiesen.

Es gibt jedoch eine Herausforderung, diesen Ablauf im Web zu ermöglichen. Wenn Sie ein Wörterbuch verwenden, um eine Ressource zu komprimieren, benötigen Sie dasselbe Wörterbuch, um sie zu dekomprimieren. Dieser Ablauf wurde bereits im Web versucht, nämlich mit SDCH, war aber schwierig sicher zu implementieren. Dieser neueste Vorschlag für die Komprimierung mit freigegebenen Wörterbüchern berücksichtigt diese Bedenken und bietet gleichzeitig einen erheblichen Vorteil für statische und dynamische Ressourcen.

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

Alle Browser werben mit den Komprimierungsalgorithmen, die sie unterstützen, über den Accept-Encoding Anfrageheader. 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, welcher Algorithmus verwendet werden soll.

Wenn die Unterstützung für freigegebene Wörterbücher aktiviert ist und ein entsprechendes Wörterbuch für eine Ressource verfügbar ist, werden dem Accept-Encoding-Header 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, der im nächsten Abschnitt behandelt wird.

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

Wenn ein Webserver so konfiguriert ist, dass er dieses Token erkennt, und er 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 das 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 ist eine Ressource, die für eine angeforderte URL immer dieselbe Antwort liefert. Häufige Beispiele für komprimierbare statische Seitenressourcen sind JavaScript- und CSS-Dateien. Diese Ressourcen werden in der Regel für Caching-Zwecke versioniert, manchmal mit einem Hash des Inhalts der Datei im Dateinamen (z. B. styles.abcd1234.css) oder einer anderen Methode zur Identifizierung der Ressource. Diese Ressourcentypen sind gut für die Delta-Komprimierung geeignet, die freigegebene Wörterbücher bieten, da statische Ressourcen oft lange im Cache gespeichert werden und in der Regel häufig aktualisiert werden.

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

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

Der Header Use-As-Dictionary gilt für zukünftige Versionen einer Ressource, die mit dem darin angegebenen Muster übereinstimmen. Angenommen, Ihre Website liefert alle Stile in einer einzigen CSS-Datei aus. Der Einfachheit halber befindet sich die erste Version dieser Ressource unter /dist/styles.v1.css und wird mit einem Use-As-Dictionary-Antwortheader gesendet, der einen match-Wert von /dist/styles.*.css enthält.

Nach einiger Zeit aktualisieren Sie das CSS Ihrer Website und liefern eine neue Version unter /dist/styles.v2.css aus. Da der match-Wert, der im Use-As-Dictionary-Antwortheader der vorherigen Version verwendet wurde, auf diese Anfrage angewendet wird, sendet der Browser einen Available-Dictionary-Header, der einen Hash des Wörterbuchs enthält, das als strukturierte Feld-Byte-Sequenz codiert ist:

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

An diesem Punkt 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 das verfügbare Wörterbuch im Browsercache des Nutzers wird verwendet, um sie zu dekomprimieren.

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

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

Auch dynamische Ressourcen können von der Komprimierung mit freigegebenen Wörterbüchern profitieren. Dynamische Ressourcen ändern sich je nach Kontext. Ein Beispiel ist eine Nachrichtenwebsite, auf der die Hauptseite häufig aktualisiert wird, wenn es neue Nachrichten gibt. HTML-Dokumente sind oft dynamische Ressourcen. In solchen Fällen kann das Wörterbuch den größten Teil der allgemeinen HTML-Struktur und des Vorlagencodes der Website enthalten. So werden komprimierte Seiten erstellt, bei denen nur die eindeutigen Teile jeder Seite gesendet werden.

Aufgrund der Natur dynamisch generierter Ressourcen muss ein Wörterbuch auf dem Client geladen werden, um später verwendet zu werden. Wenn ein Wörterbuch vorab geladen wird, ist die Anwendung der Komprimierung mit freigegebenen Wörterbüchern auf dynamische Ressourcen spekulativ. In solchen Fällen hofft man, dass die Website genügend Traffic erhält, damit die Kosten für das Wörterbuch über eine große Anzahl von Navigationen amortisiert werden können. Wenn Sie es ausprobieren möchten, müssen Sie zuerst den Speicherort des Wörterbuchs über ein <link> Element im HTML-Code Ihrer Seite angeben:

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

Wenn Chrome auf dieses <link> Element stößt, ruft es das Wörterbuch möglicherweise ab, sobald die Seite inaktiv ist, und mit niedriger Priorität, um Bandbreitenkonflikte zu vermeiden. Die Antwort für das Wörterbuch selbst muss einen Use-As-Dictionary-Header enthalten und angeben, auf welchen dynamischen Ressourcenpfad es angewendet wird:

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

Ab hier ist der Ablauf 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. Das ist ähnlich wie beim Ablauf für statische Ressourcen, der weiter oben beschrieben wurde.

Statische Ressourcen zur Build-Zeit komprimieren

Wenn Sie mit Bundlern vertraut sind, kennen Sie vielleicht verschiedene Plug-ins, mit denen Ressourcen zur Build-Zeit komprimiert und anschließend diese komprimierten Ressourcen bereitgestellt werden können. Mit Apache können Sie beispielsweise Direktiven verwenden, um diese vorkomprimierten Ressourcen zum Zeitpunkt der Anfrage bereitzustellen.

Die meisten Node.js-basierten Bundler, die Komprimierung unterstützen, verwenden die integrierte Zlib-Bibliothek von Node. Zlib bietet Unterstützung für Brotli und Bundler, die es verwenden, bieten in der Regel eine Schnittstelle, um Optionen direkt an Zlib zu übergeben, das die Komprimierung mit Wörterbuch unterstützt. Hier sind einige Bundler, die die Verwendung von Wörterbüchern unterstützen:

Verfügbare Wörterbücher für eine bestimmte Version einer Ressource können eine beliebige frühere Version einer Ressource verwenden. Das bedeutet, dass Sie den Nutzertraffic analysieren und entsprechend planen müssen. Achten Sie auf ein Gleichgewicht und generieren Sie Ressourcen, die möglichst vielen wiederkehrenden Nutzern zugutekommen. CDN-Anbieter experimentieren derzeit mit der Komprimierung mit freigegebenen Wörterbüchern. Es sind noch keine Implementierungen für die öffentliche Nutzung verfügbar, aber wir gehen davon aus, dass sich das ändern wird.

Probier es gleich aus!

Die Integration der Komprimierung mit freigegebenen Wörterbüchern in die vorhandenen Komprimierungsfunktionen des Browsers kann die Ladeleistung von Websites, auf denen häufig aktualisierter Produktionscode ausgeliefert wird und die viel Traffic von wiederkehrenden Besuchern erhalten, erheblich verbessern. Wenn Sie die Komprimierung mit freigegebenen Wörterbüchern ausprobieren möchten, haben Sie zwei Möglichkeiten:

  1. Wenn Sie nur selbst mit der Komprimierung mit freigegebenen Wörterbüchern experimentieren möchten, um ein Gefühl dafür zu bekommen, wie sie funktioniert, können Sie die experimentelle Funktion Übertragung von Komprimierungswörterbüchern auf der Seite chrome://flags aktivieren.
  2. Wenn Sie diese Funktion auf Ihrer Produktionswebsite ausprobieren und sehen möchten, wie die Komprimierung mit freigegebenen Wörterbüchern echten Nutzern zugutekommt, registrieren Sie sich für den Ursprungstest, um ein Token zu erhalten, und lesen Sie nach, wie Ursprungstests funktionieren.

Fazit

Wir freuen uns sehr über diesen wichtigen Fortschritt bei der Komprimierungstechnologie im Web und darüber, wie viel schneller bestehende Anwendungen werden könnten, die Menschen jeden Tag nutzen. Wir empfehlen Ihnen, die Funktion auszuprobieren, und vor allem möchten wir Ihre Meinung dazu hören. 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 alles funktioniert, ist die Erläuterung ein guter nächster Schritt.