Codierung und Übertragungsgröße textbasierter Assets optimieren

Ilya Grigorik

Jeremy Wagner

Neben dem Eliminieren unnötiger Ressourcendownloads ist die beste Möglichkeit, die Geschwindigkeit beim Seitenaufbau zu verbessern, die Minimierung der Gesamtdownloadgröße durch Optimieren und Komprimieren der verbleibenden Ressourcen.

Datenkomprimierung – Grundlagen

Nachdem Sie Ihre Website so eingerichtet haben, dass keine ungenutzten Ressourcen heruntergeladen werden, müssen Sie im nächsten Schritt alle verbleibenden infrage kommenden Ressourcen komprimieren, die der Browser herunterladen muss. Je nach Ressourcentyp (Text, Bilder, Schriftarten usw.) gibt es viele verschiedene Techniken, aus denen Sie wählen können: generische Tools, die auf dem Webserver aktiviert werden können, Vorverarbeitungsoptimierungen für bestimmte Inhaltstypen und ressourcenspezifische Optimierungen, die Eingaben vom Entwickler erfordern.

Für die beste Leistung ist eine Kombination aller folgenden Techniken erforderlich:

• Bei der Komprimierung werden Informationen mit weniger Bits codiert.
• Das Entfernen unnötiger Daten führt immer zu den besten Ergebnissen.
• Es gibt viele verschiedene Komprimierungstechniken und ‑algorithmen.
• Sie benötigen eine Vielzahl von Techniken, um die beste Komprimierung zu erzielen.

Der Prozess der Reduzierung der Datengröße wird als Datenkomprimierung bezeichnet. Viele Personen haben Algorithmen, Techniken und Optimierungen beigetragen, um die Komprimierungsverhältnisse, die Komprimierungsgeschwindigkeit und den von verschiedenen Komprimierungsalgorithmen benötigten Speicher zu verbessern.

Eine vollständige Erläuterung der Datenkomprimierung würde den Rahmen dieses Leitfadens sprengen. Es ist jedoch wichtig, dass Sie zumindest grob verstehen, wie die Komprimierung funktioniert und mit welchen Techniken Sie die Größe der verschiedenen Assets reduzieren können, die für Ihre Seiten erforderlich sind.

Um die Kernprinzipien dieser Techniken zu veranschaulichen, betrachten wir den Prozess der Optimierung eines einfachen Nachrichtenformats, das nur für dieses Beispiel erfunden wurde:

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA

1. Nachrichten können beliebige Annotationen enthalten, die manchmal als Kommentare bezeichnet werden und durch das Präfix „#“ gekennzeichnet sind. Anmerkungen haben keinen Einfluss auf die Bedeutung der Nachricht oder ihr Verhalten.
2. Nachrichten können Header enthalten. Das sind Schlüssel/Wert-Paare (im vorherigen Beispiel durch ":" getrennt), die am Anfang der Nachricht angezeigt werden.
3. Nachrichten enthalten Textnutzlasten.

Was kann getan werden, um die Größe der vorherigen Nachricht zu reduzieren, die bei 200 Zeichen beginnt?

1. Der Kommentar ist interessant, hat aber keinen Einfluss auf die Bedeutung der Nachricht. Eliminieren Sie es, wenn Sie die Nachricht übertragen.
2. Es gibt gute Techniken, um Header effizient zu codieren. Wenn Sie beispielsweise wissen, dass alle Nachrichten „Format“ und „Datum“ enthalten, können Sie diese in kurze Ganzzahl-IDs konvertieren und nur diese senden. Das ist jedoch möglicherweise nicht der Fall. Am besten lassen Sie es also vorerst so, wie es ist.
3. Die Nutzlast besteht nur aus Text. Wir wissen zwar nicht, was der Inhalt wirklich ist (offenbar wird ein "secret-cipher" verwendet), aber ein Blick auf den Text zeigt, dass er viele Redundanzen enthält. Anstatt wiederholte Buchstaben zu senden, können Sie einfach die Anzahl der wiederholten Buchstaben zählen und sie effizienter codieren. Beispiel: "AAA" wird zu "3A", was für eine Sequenz von drei „A“s steht.

Die Kombination dieser Techniken führt zu folgendem Ergebnis:

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

Die neue Nachricht ist 56 Zeichen lang. Sie haben die ursprüngliche Nachricht also um 72 % komprimiert. Das ist eine erhebliche Reduzierung.

Dies ist ein einfaches Beispiel dafür, wie Komprimierungsalgorithmen die Übertragungsgröße textbasierter Ressourcen effektiv reduzieren können. In der Praxis sind Komprimierungsalgorithmen weitaus komplexer als im vorherigen Beispiel dargestellt. Im Web können Komprimierungsalgorithmen verwendet werden, um die Downloadzeiten für Ressourcen erheblich zu verkürzen. Wenn Sie textbasierte Assets komprimieren, kann eine Webseite weniger Zeit mit dem Laden von Ressourcen verbringen, sodass Nutzer die Auswirkungen dieser Ressourcen schneller sehen als ohne Komprimierung.

Minimierung: Vorverarbeitung und kontextspezifische Optimierungen

Die erste hier beschriebene Technik ist die Reduzierung. Die Reduzierung ist zwar kein Komprimierungsalgorithmus, aber eine Möglichkeit, unnötige und redundante Zeichen im Quellcode zu entfernen, um Ressourcen für Menschen lesbarer zu machen. Diese Lesbarkeit ist jedoch nicht erforderlich, damit der Quellcode auf Produktionswebsites funktioniert, und kann das Laden von Ressourcen im Web verzögern.

Die Reduzierung ist eine Art von inhaltsspezifischer Optimierung, mit der die Größe der bereitgestellten Ressourcen erheblich reduziert werden kann. Diese Optimierungen werden am besten im Rahmen des Build- und Bereitstellungsprozesses angewendet. Bundler sind beispielsweise eine häufig verwendete Art von Software, die Ressourcen automatisch reduzieren kann, kurz bevor neuer Produktionscode auf einer Website bereitgestellt wird.

Die beste Möglichkeit, redundante oder unnötige Daten zu komprimieren, besteht darin, sie zu entfernen. Sie können jedoch nicht einfach beliebige Daten löschen. In einigen Kontexten, in denen wir inhaltsspezifische Kenntnisse über das Datenformat und seine Eigenschaften haben, ist es jedoch möglich, die Größe der Nutzlast erheblich zu reduzieren, ohne die tatsächliche Bedeutung oder die Funktionen zu beeinträchtigen.

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

Sehen Sie sich das vorherige HTML-Snippet und die drei verschiedenen Inhaltstypen an, die es enthält:

1. HTML-Markup.
2. CSS, um die Darstellung einer Seite anzupassen.
3. JavaScript für Interaktionen und andere erweiterte Seitenfunktionen.

Für jeden dieser Inhaltstypen gelten unterschiedliche Regeln, z. B. was gültige Inhalte sind oder wie Kommentare angegeben werden. Die Frage, die sich jetzt stellt, ist: „Wie kann die Größe dieser Seite reduziert werden?“

• Codekommentare sind für Entwickler sehr hilfreich, aber der Browser benötigt sie nicht. Durch das Entfernen von CSS- (/* ... */), HTML- (<!-- ... -->) und JavaScript-Kommentaren (// ...) wird die Gesamtübertragungsgröße der Seite und ihrer Unterressourcen reduziert.
• Ein „intelligenter“ CSS-Kompressor könnte feststellen, dass wir eine ineffiziente Methode zum Definieren von Regeln für .awesome-container verwenden, und die beiden Deklarationen zu einer zusammenfassen, ohne andere Stile zu beeinträchtigen. So werden weitere Byte eingespart. Bei einer großen Anzahl von CSS-Regeln kann das Entfernen dieser Art von Redundanz einen großen Unterschied machen. Es ist jedoch möglicherweise nicht immer möglich, da Selektoren oft in verschiedenen Kontexten, z. B. in Medienabfragen, dupliziert werden müssen.
• Leerzeichen und Tabulatoren sind in HTML, CSS und JavaScript für Entwickler praktisch. Ein zusätzlicher Kompressor könnte alle Tabulatoren und Leerzeichen entfernen. Im Gegensatz zu anderen Deduplizierungstechniken kann diese Art der Optimierung ziemlich aggressiv angewendet werden, solange solche Leerzeichen oder Tabulatoren nicht für die Darstellung der Seite erforderlich sind. Beispielsweise sollten Sie die Leerzeichen in Textabschnitten in einem HTML-Dokument beibehalten, da sie die Lesbarkeit von Inhalten gewährleisten, die Nutzer tatsächlich sehen.

<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

Nachdem die vorherigen Schritte angewendet wurden, wird die Seite von 516 auf 204 Zeichen reduziert, was einer Einsparung von etwa 60 % entspricht. Zugegeben, es ist nicht sehr lesbar, aber das muss es auch nicht sein, um verwendbar zu sein. Moderne Entwicklungsmethoden ermöglichen es Ihnen außerdem, die gut formatierten und lesbaren Versionen Ihres Quellcodes von dem optimierten Code zu trennen, den Sie in die Produktion senden. In Kombination mit Quellzuordnungen, die eine lesbare Darstellung des transformierten Produktionscodes bieten, können Sie Fehler in der Produktion leichter beheben. So können Sie sowohl die Entwicklererfahrung verbessern als auch die Leistung im Sinne der Nutzererfahrung optimieren.

Hinweis: SVG-Bilder sind eine weitere textbasierte Ressource, die im vorherigen Beispiel nicht dargestellt wurde. SVGs können mit Tools wie SVGO minimiert und auf andere Weise verlustbehaftet optimiert werden.

Das vorherige Beispiel veranschaulicht einen wichtigen Punkt: Ein Kompressor für allgemeine Zwecke, der beispielsweise für die Komprimierung von beliebigem Text entwickelt wurde, könnte die Seite im vorherigen Beispiel recht gut komprimieren. Er würde jedoch nie wissen, dass er die Kommentare entfernen, CSS-Regeln reduzieren oder Dutzende anderer inhaltsspezifischer Optimierungen vornehmen muss. Deshalb sind Vorverarbeitung, Reduzierung und andere kontextbezogene Optimierungen wichtig.

Hinweis: Die unkomprimierten Entwicklungsversionen gängiger Frameworks sind beispielsweise viel größer als die entsprechenden Versionen, die für die Verwendung in der Produktion vorgesehen sind. Beispielsweise ist die Entwicklungsversion von Angular 1.8.3 fast 1, 4 Megabyte groß. Die Produktionsversion ist 177 Kilobyte groß. Dies zeigt deutlich das Potenzial dieser Optimierungen.

Die oben beschriebenen Techniken können auch auf andere als nur textbasierte Assets angewendet werden. Bilder, Videos und andere Inhaltstypen enthalten jeweils eigene Formen von Metadaten und verschiedene Nutzlasten. Wenn Sie beispielsweise ein Foto mit einer Kamera aufnehmen, werden in der Datei normalerweise viele zusätzliche Informationen eingebettet: Kameraeinstellungen, Standort usw. Je nach Anwendung können diese Daten wichtig (z. B. bei einer Website zum Teilen von Fotos) oder völlig nutzlos sein. Sie sollten sich überlegen, ob es sich lohnt, sie zu entfernen. In der Praxis können diese Metadaten pro Bild bis zu mehreren Dutzend Kilobyte ausmachen.

Kurz gesagt: Erstellen Sie als ersten Schritt zur Optimierung der Effizienz Ihrer Assets ein Inventar der verschiedenen Inhaltstypen und überlegen Sie, welche Art von inhaltsspezifischen Optimierungen Sie anwenden können, um ihre Größe zu reduzieren. Nachdem Sie herausgefunden haben, was diese sind, automatisieren Sie diese Optimierungen, indem Sie sie Ihren Build- und Release-Schritten hinzufügen. So sorgen Sie dafür, dass die Optimierungen für jeden neuen Release in der Produktion konsistent angewendet werden.

Textkomprimierung mit Komprimierungsalgorithmen

Der nächste Schritt zur Reduzierung der Größe textbasierter Assets besteht darin, einen Komprimierungsalgorithmus auf sie anzuwenden. Hier wird noch einen Schritt weiter gegangen, indem aggressiv nach wiederholbaren Mustern in textbasierten Nutzlasten gesucht wird, bevor sie an den Nutzer gesendet werden. Sobald sie im Browser des Nutzers ankommen, werden sie dekomprimiert. Das Ergebnis ist eine weitere und erhebliche Reduzierung dieser Ressourcen und damit schnellere Downloadzeiten.

• gzip und Brotli sind gängige Komprimierungsalgorithmen, die am besten für textbasierte Assets wie CSS, JavaScript und HTML geeignet sind.
• Alle modernen Browser unterstützen die gzip- und Brotli-Komprimierung und geben die Unterstützung für beide im HTTP-Anfrageheader Accept-Encoding an.
• Ihr Server muss so konfiguriert sein, dass die Komprimierung aktiviert ist. Webserver-Software ermöglicht häufig standardmäßig Module zum Komprimieren textbasierter Ressourcen.
• Sowohl gzip als auch Brotli können optimiert werden, um die Komprimierungsraten durch Anpassen der Komprimierungsstufe zu verbessern. Für gzip reichen die Komprimierungseinstellungen von 1 bis 9, wobei 9 die beste ist. Bei Brotli liegt dieser Bereich zwischen 0 und 11, wobei 11 die beste Komprimierung ist. Höhere Komprimierungseinstellungen erfordern jedoch mehr Zeit. Bei Ressourcen, die dynamisch komprimiert werden, also zum Zeitpunkt der Anfrage, bieten Einstellungen in der Mitte des Bereichs in der Regel den besten Kompromiss zwischen Komprimierungsverhältnis und Geschwindigkeit. Eine statische Komprimierung ist jedoch möglich. Dabei wird die Antwort im Voraus komprimiert und es können die aggressivsten Komprimierungseinstellungen verwendet werden, die für den jeweiligen Komprimierungsalgorithmus verfügbar sind.
• Content Delivery Networks (CDNs) bieten häufig eine automatische Komprimierung geeigneter Ressourcen. CDNs können auch die dynamische und statische Komprimierung für Sie verwalten, sodass Sie sich um einen Aspekt der Komprimierung weniger kümmern müssen.

gzip und Brotli sind gängige Komprimierungstools, die auf jeden Bytestream angewendet werden können. Im Hintergrund werden einige der zuvor untersuchten Inhalte einer Datei gespeichert und anschließend versucht, doppelte Datenfragmente auf effiziente Weise zu finden und zu ersetzen.

Hinweis: Wenn Sie eine ausführlichere Erklärung zur Funktionsweise der Komprimierung wünschen, sehen Sie sich diese gute Low-Level-Erklärung zu gzip an. Wenn Sie mit der Textkomprimierung experimentieren möchten, probieren Sie unsere Codelabs zu gzip und Brotli aus.

In der Praxis erzielen sowohl gzip als auch Brotli die besten Ergebnisse bei textbasierten Inhalten. Bei größeren Dateien werden oft Komprimierungsraten von bis zu 70–90 % erreicht. Wenn Sie diese Algorithmen jedoch auf Assets anwenden, die bereits mit alternativen Algorithmen komprimiert wurden, z. B. die meisten Bildformate, die verlustfreie oder verlustbehaftete Komprimierungstechniken verwenden, führt dies zu kaum oder gar keiner Verbesserung.

Alle modernen Browser geben im HTTP-Anfrageheader Accept-Encoding an, dass sie gzip und Brotli unterstützen. Es liegt jedoch in der Verantwortung des Hostanbieters, dafür zu sorgen, dass der Webserver richtig konfiguriert ist, um die komprimierte Ressource bereitzustellen, wenn der Client sie anfordert.

Datei	Algorithmus	Nicht komprimierte Größe	Komprimierte Größe	Verdichtungsverhältnis
angular-1.8.3.js	Brotli	1.346 KiB	256 KiB	81 %
angular-1.8.3.js	GZIP	1.346 KiB	329 KiB	76 %
angular-1.8.3.min.js	Brotli	173 KiB	53 KiB	69 %
angular-1.8.3.min.js	GZIP	173 KiB	60 KiB	65 %
jquery-3.7.1.js	Brotli	302 KiB	69 KiB	77 %
jquery-3.7.1.js	GZIP	302 KiB	83 KiB	73 %
jquery-3.7.1.min.js	Brotli	85 KiB	27 KiB	68 %
jquery-3.7.1.min.js	GZIP	85 KiB	30 KiB	65 %
lodash-4.17.21.js	Brotli	531 KiB	73 KiB	86 %
lodash-4.17.21.js	GZIP	531 KiB	94 KiB	82 %
lodash-4.17.21.min.js	Brotli	71 KiB	23 KiB	68 %
lodash-4.17.21.min.js	GZIP	71 KiB	25 KiB	65 %

Die obige Tabelle zeigt die Einsparungen, die sowohl die Brotli- als auch die gzip-Komprimierung für einige bekannte JavaScript-Bibliotheken bieten können. Die Einsparungen liegen je nach Datei und Algorithmus zwischen 65 % und 86 %. Zur Referenz wurde für jede Datei sowohl für Brotli als auch für gzip die maximale Komprimierungsstufe angewendet. Bevorzugen Sie nach Möglichkeit Brotli gegenüber gzip.

Wichtig: Die vorherige Tabelle zeigt deutlich, wie die Anwendung der Komprimierung zusätzlich zu Optimierungen wie der Reduzierung zusätzliche Einsparungen bringen kann. Es ist nicht immer so, dass die Komprimierung allein die Auswirkungen der Reduzierung bedeutungslos macht. Es handelt sich um eine additive Optimierung.

Die Aktivierung der Komprimierung ist eine der einfachsten und effektivsten Optimierungen, die Sie implementieren können. Wenn Ihre Website diese Funktion nicht nutzt, entgeht Ihnen eine große Chance, die Leistung für Ihre Nutzer zu verbessern. Glücklicherweise bieten viele Webserver Standardkonfigurationen, die diese wichtige Optimierung ermöglichen. Insbesondere CDNs sind sehr effektiv darin, sie so zu implementieren, dass Komprimierungsgeschwindigkeit und -verhältnis ausgeglichen sind.

Eine schnelle Möglichkeit, die Komprimierung in Aktion zu sehen, besteht darin, die Chrome-Entwicklertools zu öffnen, den Bereich Netzwerk aufzurufen, eine Seite Ihrer Wahl zu laden und den unteren Bereich des Netzwerkbereichs zu beobachten.

Eine Darstellung der Übertragungsgröße (d. h. komprimiert) aller Seitenressourcen im Vergleich zu ihrer tatsächlichen Größe, wie im Netzwerkbereich der Chrome-Entwicklertools visualisiert.

Wie im vorherigen Bild sollten Sie eine Aufschlüsselung der folgenden Punkte sehen:

• Die Anzahl der Anfragen, d. h. die Anzahl der für die Seite geladenen Ressourcen.
• Die Übertragungsgröße aller Anfragen. Dies spiegelt die Effektivität der Komprimierung wider, die auf die Ressourcen einer Seite angewendet wird.
• Die Ressourcengröße aller Anfragen. Dies gibt an, wie groß die Ressourcen für die Seite nach der Dekomprimierung sind.

Hinweis: Manchmal können Komprimierungsalgorithmen die Größe des Assets erhöhen. Das ist in der Regel der Fall, wenn das unkomprimierte Asset sehr klein ist und der Overhead des Algorithmus höher ist als die Einsparungen durch die Komprimierung oder wenn die Ressource bereits gut komprimiert ist. Um dieses Problem zu vermeiden, können Sie auf einigen Servern einen Mindestwert für die Dateigröße festlegen, der in der Regel unter vier oder fünf Kilobyte liegt.

Auswirkungen auf die Core Web Vitals

Leistungsverbesserungen können nur gemessen werden, wenn es Messwerte gibt, die diese Verbesserungen widerspiegeln. Die Core Web Vitals-Initiative wurde ins Leben gerufen, um Messwerte zu erstellen und das Bewusstsein für Messwerte zu schärfen, die die tatsächliche Nutzererfahrung widerspiegeln. Dies steht im Gegensatz zu Messwerten wie der einfachen Seitenladezeit, die sich nicht eindeutig auf die Qualität der Nutzererfahrung übertragen lassen.

Wenn Sie die in diesem Leitfaden beschriebenen Optimierungen auf die Ressourcen Ihrer Website anwenden, können die Auswirkungen auf die Core Web Vitals je nach den optimierten Ressourcen und den beteiligten Messwerten variieren. In den folgenden Fällen kann die Anwendung dieser Optimierungen jedoch die Core Web Vitals Ihrer Website verbessern:

• HTML-Ressourcen, die minimiert und komprimiert sind, können das Laden dieses HTML-Codes, die Auffindbarkeit der zugehörigen Unterressourcen und somit auch das Laden dieser Unterressourcen verbessern. Das kann sich positiv auf den Largest Contentful Paint (LCP) einer Seite auswirken. Ressourcenhinweise wie rel="preload" können zwar verwendet werden, um die Auffindbarkeit von Ressourcen zu beeinflussen, aber zu viele davon können zu Problemen mit der Bandbreitennutzung führen. Wenn die HTML-Antwort für eine Navigationsanfrage komprimiert ist, können die darin enthaltenen Ressourcen so schnell wie möglich vom Preload-Scanner erkannt werden.
• Einige LCP-Kandidaten können auch schneller geladen werden, wenn sie komprimiert werden. Beispielsweise kann die Ressourcen-Ladedauer von SVG-Bildern, die LCP-Kandidaten sind, durch textbasierte Komprimierung reduziert werden. Dies unterscheidet sich von Optimierungen, die Sie an anderen Bildtypen vornehmen würden, die durch andere Komprimierungsmethoden komprimiert werden, z. B. JPEG-Bilder, die eine verlustbehaftete Komprimierung verwenden.
• Außerdem können Textknoten auch LCP-Kandidaten sein. Wie die in diesem Leitfaden beschriebenen Techniken angewendet werden, hängt davon ab, ob Sie eine Webschriftart für Text auf Ihren Webseiten verwenden. Wenn du eine Webschriftart verwendest, gelten die Best Practices für die Optimierung von Webschriftarten. Wenn Sie jedoch keine Webschriftarten verwenden, sondern Systemschriftarten, die ohne Ladezeit für Ressourcen angezeigt werden, wird diese Dauer durch das Minimieren und Komprimieren des CSS-Codes verkürzt. Das bedeutet, dass das Rendern potenzieller LCP-Textknoten früher erfolgen kann.

Fazit

Die Optimierung der Codierung und Übertragung textbasierter Assets ist ein grundlegendes Leistungskonzept, das jedoch große Auswirkungen hat. Achten Sie darauf, dass Sie alles tun, damit Ressourcen, die für die Reduzierung und Komprimierung infrage kommen, von diesen Optimierungen profitieren.

Noch wichtiger ist, dass diese Prozesse automatisiert werden. Verwenden Sie für die Reduzierung einen Bundler, um die Reduzierung auf die entsprechenden Ressourcen anzuwenden. Achte darauf, dass deine Webserverkonfiguration die Komprimierung unterstützt, und verwende die effektivste verfügbare Komprimierung. Um dies so einfach wie möglich zu machen, können Sie CDNs verwenden, um die Komprimierung zu automatisieren. Sie können Ressourcen nicht nur für Sie komprimieren, sondern auch sehr schnell.

Wenn ihr diese grundlegenden Leistungskonzepte in die Architektur eurer Website einbindet, könnt ihr sicher sein, dass eure Bemühungen zur Leistungsoptimierung auf einem guten Fundament stehen und dass nachfolgende Optimierungen auf einer soliden Grundlage von guten grundlegenden Praktiken beruhen können.