Codierung und Übertragungsgröße textbasierter Assets optimieren

Neben dem Vermeiden unnötiger Ressourcendownloads können Sie die Geschwindigkeit beim Seitenaufbau am besten verbessern, indem Sie die gesamte Downloadgröße minimieren. Dazu müssen Sie die verbleibenden Ressourcen optimieren und komprimieren.

Datenkomprimierung – Grundlagen

Nachdem Sie Ihre Website so eingerichtet haben, dass keine ungenutzten Ressourcen heruntergeladen werden, müssen Sie alle verbleibenden infrage kommenden Ressourcen komprimieren, die der Browser herunterladen muss. Je nach Ressourcentyp (Text, Bilder, Schriftarten usw.) gibt es viele verschiedene Techniken: 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 eine optimale Leistung ist eine Kombination aller folgenden Techniken erforderlich:

  • Bei der Komprimierung werden Informationen mit weniger Bits codiert.
  • Die besten Ergebnisse werden immer erzielt, wenn unnötige Daten entfernt werden.
  • Es gibt viele verschiedene Komprimierungstechniken und ‑algorithmen.
  • Sie benötigen verschiedene Techniken, um die beste Komprimierung zu erzielen.

Das Reduzieren der Datengröße wird als Datenkomprimierung bezeichnet. Viele Menschen haben Algorithmen, Techniken und Optimierungen beigetragen, um das Komprimierungsverhältnis, die Komprimierungsgeschwindigkeit und den von verschiedenen Komprimierungsalgorithmen benötigten Speicher zu verbessern.

Eine ausführliche Beschreibung der Datenkomprimierung würde den Rahmen dieser Anleitung sprengen. Es ist jedoch wichtig, dass Sie im Großen und Ganzen verstehen, wie die Komprimierung funktioniert und welche Techniken Sie verwenden können, um die Größe verschiedener Assets zu reduzieren, die für Ihre Seiten erforderlich sind.

Um die grundlegenden Prinzipien dieser Techniken zu veranschaulichen, betrachten wir den Prozess der Optimierung eines einfachen SMS-Formats, 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 Anmerkungen enthalten, die manchmal auch als Kommentare bezeichnet werden und durch das Präfix „#“ gekennzeichnet sind. Anmerkungen haben keinen Einfluss auf die Bedeutung oder das Verhalten der Nachricht.
  2. Nachrichten können Header enthalten. Das sind Schlüssel/Wert-Paare (im vorherigen Beispiel durch ":" getrennt), die am Anfang der Nachricht stehen.
  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. Entfernen Sie sie beim Übertragen der Nachricht.
  2. Es gibt gute Techniken, um Header effizient zu codieren. Wenn Sie beispielsweise wissen, dass alle Nachrichten „format“ und „date“ enthalten, können Sie diese in kurze Ganzzahl-IDs umwandeln und nur diese senden. Das ist aber möglicherweise nicht der Fall. Lass es also lieber erst einmal so.
  3. Die Nutzlast besteht nur aus Text. Wir wissen zwar nicht, was genau darin enthalten ist (offenbar wird eine "secret-cipher" verwendet), aber allein der Text zeigt, dass er sehr redundant ist. Vielleicht können Sie statt wiederholter Buchstaben einfach die Anzahl der wiederholten Buchstaben zählen und sie effizienter codieren. Aus "AAA" wird beispielsweise "3A", was einer Folge von drei A's entspricht.

Durch die Kombination dieser Techniken wird Folgendes erreicht:

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

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

Dies ist ein einfaches Beispiel dafür, wie Komprimierungsalgorithmen die Übertragungsgröße von textbasierten Ressourcen reduzieren können. In der Praxis sind Komprimierungsalgorithmen viel komplexer als im vorherigen Beispiel. Im Web können sie verwendet werden, um die Downloadzeiten für Ressourcen erheblich zu verkürzen. Durch die Komprimierung von textbasierten Assets kann eine Webseite weniger Zeit für das Laden von Ressourcen aufwenden, sodass Nutzer die Auswirkungen dieser Ressourcen schneller sehen als ohne Komprimierung.

Minifizierung: Vorverarbeitung und kontextspezifische Optimierungen

Die erste hier besprochene Technik ist die Minifizierung. Die Minimierung ist zwar nicht unbedingt ein 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, um die Funktionalität des Quellcodes auf Produktionswebsites aufrechtzuerhalten. Sie kann das Laden von Ressourcen im Web sogar verzögern.

Die Minimierung ist eine Art von inhaltsbezogener 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 Software, mit der Ressourcen automatisch minimiert werden können, kurz bevor neuer Produktionscode auf einer Website bereitgestellt wird.

Die beste Methode, um redundante oder unnötige Daten zu komprimieren, ist, sie zu entfernen. Sie können jedoch nicht einfach beliebige Daten löschen. In einigen Kontexten, in denen wir inhaltsspezifisches Wissen über das Datenformat und seine Eigenschaften haben, ist es jedoch möglich, die Größe der Nutzlast erheblich zu reduzieren, ohne ihre tatsächliche Bedeutung oder ihre 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 zum Anpassen der Darstellung einer Seite.
  3. JavaScript für Interaktionen und andere erweiterte Seitenfunktionen.

Für jeden dieser Inhaltstypen gelten unterschiedliche Regeln für gültige Inhalte, unterschiedliche Regeln für die Angabe von Kommentaren usw. Die Frage, die sich jedoch stellt, ist: „Wie kann die Größe dieser Seite reduziert werden?“

  • Kommentare im Code sind für Entwickler sehr hilfreich, der Browser benötigt sie jedoch nicht. Durch das Entfernen von CSS- (/* ... */), HTML- (<!-- ... -->) und JavaScript-Kommentaren (// ...) wird die Gesamtübertragungsgröße der Seite und ihrer untergeordneten Ressourcen reduziert.
  • Ein „intelligenter“ CSS-Komprimierer könnte erkennen, dass wir eine ineffiziente Methode zum Definieren von Regeln für .awesome-container verwenden, und die beiden Deklarationen in eine zusammenfassen, ohne andere Stile zu beeinträchtigen. So würden noch mehr Byte eingespart. Bei einer großen Anzahl von CSS-Regeln kann sich das Entfernen dieser Art von Redundanz summieren. Es ist jedoch möglicherweise nicht möglich, dies aggressiv anzuwenden, da Selektoren oft in verschiedenen Kontexten, z. B. in Media-Queries, dupliziert werden müssen.
  • Leerzeichen und Tabulatoren sind für Entwickler in HTML, CSS und JavaScript praktisch. Ein zusätzlicher Kompressor könnte alle Tabulatoren und Leerzeichen entfernen. Im Gegensatz zu anderen Deduplizierungstechniken kann diese Art der Optimierung recht aggressiv angewendet werden, sofern solche Leerzeichen oder Tabulatoren für die Darstellung der Seite nicht erforderlich sind. So sollten Sie beispielsweise die Leerzeichen in Textblöcken 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 Sie die vorherigen Schritte ausgeführt haben, umfasst die Seite nur noch 204 statt 516 Zeichen. Das entspricht einer Einsparung von etwa 60%. Zugegeben, es ist nicht sehr lesbar, aber das ist auch nicht erforderlich, damit es verwendet werden kann. Moderne Entwicklungspraktiken ermöglichen es Ihnen auch, die gut formatierte und lesbare Version Ihres Quellcodes von dem gut optimierten Code zu trennen, den Sie in der Produktion verwenden. In Kombination mit Quellzuordnungen, die eine lesbare Darstellung Ihres transformierten Produktionscodes bieten, können Sie Fehler in der Produktion leichter beheben. So können Sie sowohl eine gute Entwicklerumgebung als auch eine optimierte Leistung für die Nutzererfahrung erzielen.

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

Die oben beschriebenen Techniken lassen sich nicht nur auf textbasierte Assets anwenden. Bilder, Videos und andere Inhaltstypen enthalten jeweils eigene Metadaten und verschiedene Nutzlasten. Wenn Sie beispielsweise ein Bild mit einer Kamera aufnehmen, enthält die Datei in der Regel viele zusätzliche Informationen wie Kameraeinstellungen und Standort. Je nach Anwendung können diese Daten wichtig sein (z. B. bei einer Website zum Teilen von Fotos) oder völlig nutzlos. Sie sollten überlegen, ob sich eine Entfernung lohnt. In der Praxis können diese Metadaten für jedes Bild mehrere Zehntausend Kilobyte umfassen.

Als ersten Schritt zur Optimierung der Effizienz Ihrer Assets sollten Sie eine Bestandsaufnahme der verschiedenen Inhaltstypen vornehmen und überlegen, welche inhaltsspezifischen Optimierungen Sie anwenden können, um ihre Größe zu reduzieren. Nachdem Sie herausgefunden haben, welche das sind, können Sie diese Optimierungen automatisieren, indem Sie sie Ihren Build- und Release-Schritten hinzufügen. So wird sichergestellt, dass die Optimierungen bei jeder Neuveröffentlichung 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 ein Schritt weiter gegangen: Es wird aggressiv nach wiederholbaren Mustern in textbasierten Nutzlasten gesucht, bevor sie an den Nutzer gesendet werden. Außerdem werden sie dekomprimiert, sobald sie im Browser des Nutzers ankommen. Das Ergebnis ist eine weitere und erhebliche Reduzierung dieser Ressourcen und damit schnellere Downloadzeiten.

  • gzip und Brotli sind häufig verwendete Komprimierungsalgorithmen, die sich am besten für textbasierte Assets wie CSS, JavaScript und HTML eignen.
  • Alle modernen Browser unterstützen die gzip- und Brotli-Komprimierung und geben im HTTP-Anfrageheader Accept-Encoding an, dass beide unterstützt werden.
  • Ihr Server muss für die Komprimierung konfiguriert sein. Webserversoftware ermöglicht oft standardmäßig die Komprimierung von textbasierten Ressourcen durch Module.
  • Sowohl gzip als auch Brotli können optimiert werden, um die Komprimierungsraten durch Anpassen des Komprimierungsgrads zu verbessern. Bei Gzip reichen die Komprimierungseinstellungen von 1 bis 9, wobei 9 die beste ist. Für Brotli liegt dieser Bereich zwischen 0 und 11, wobei 11 der beste Wert ist. Höhere Komprimierungseinstellungen erfordern jedoch mehr Zeit. Bei Ressourcen, die dynamisch komprimiert werden, d. h. zum Zeitpunkt der Anfrage, bieten Einstellungen in der Mitte des Bereichs in der Regel den besten Kompromiss zwischen Komprimierungsrate und Geschwindigkeit. Es ist jedoch eine statische Komprimierung möglich. Dabei wird die Antwort im Voraus komprimiert. Daher können die aggressivsten Komprimierungseinstellungen für jeden Komprimierungsalgorithmus verwendet werden.
  • Content Delivery Networks (CDNs) bieten in der Regel eine automatische Komprimierung von infrage kommenden 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 Komprimierungsprogramme, die auf jeden Byte-Stream angewendet werden können. Dabei wird ein Teil des zuvor untersuchten Inhalts einer Datei gespeichert und anschließend versucht, doppelte Datenfragmente effizient zu finden und zu ersetzen.

In der Praxis funktionieren sowohl Gzip als auch Brotli am besten bei textbasierten Inhalten. Bei größeren Dateien werden häufig 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, ist die Verbesserung gering oder nicht vorhanden.

Alle modernen Browser werben im HTTP-Anfrageheader Accept-Encoding mit der Unterstützung von gzip und Brotli. Es liegt jedoch in der Verantwortung des Hostinganbieters, 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 Tabelle oben 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 Brotli und GZIP die maximale Komprimierungsstufe auf jede Datei angewendet. Verwenden Sie nach Möglichkeit Brotli anstelle von gzip.

Die Komprimierung ist eine der einfachsten und effektivsten Optimierungen, die Sie vornehmen können. Wenn Ihre Website diese Funktion nicht nutzt, verpassen Sie 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 bei der Implementierung, da sie Komprimierungsgeschwindigkeit und ‑verhältnis ausgleichen.

Eine schnelle Möglichkeit, die Komprimierung in Aktion zu sehen, besteht darin, die Chrome-Entwicklertools zu öffnen, den Bereich „Netzwerk“ zu öffnen, eine beliebige Seite zu laden und sich das untere Ende des Bereichs „Netzwerk“ anzusehen.

Entwicklertools-Ausgabe der tatsächlichen Größe im Vergleich zur Übertragungsgröße.
Eine Darstellung der Übertragungsgröße (d. h. komprimiert) aller Seitenressourcen im Vergleich zu ihrer tatsächlichen Größe, wie sie im Bereich „Netzwerk“ der Chrome-Entwicklertools visualisiert wird.

Wie in der vorherigen Abbildung sollten Sie eine Aufschlüsselung der folgenden Elemente sehen:

  • Die Anzahl der Anfragen, also die Anzahl der Ressourcen, die für die Seite geladen wurden.
  • Die Übertragungsgröße aller Anfragen. Dieser Messwert gibt die Effektivität der Komprimierung an, die auf die Ressourcen einer Seite angewendet wird.
  • Die Ressourcengröße aller Anfragen. Hier wird angegeben, wie groß die Ressourcen für die Seite nach der Dekomprimierung sind.

Auswirkungen auf die Core Web Vitals

Leistungssteigerungen können nur gemessen werden, wenn es Messwerte gibt, die diese Steigerungen widerspiegeln. Die Core Web Vitals-Initiative wurde ins Leben gerufen, um Messwerte zu entwickeln und bekannt zu machen, die die tatsächliche Nutzerfreundlichkeit widerspiegeln. Das ist ein Unterschied zu Messwerten wie der einfachen Seitenladezeit, die nicht eindeutig mit der Qualität der Nutzererfahrung in Verbindung gebracht werden können.

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 optimierten Ressourcen und den beteiligten Messwerten variieren. In den folgenden Fällen können diese Optimierungen jedoch die Core Web Vitals Ihrer Website verbessern:

  • Durch die Reduzierung und Komprimierung von HTML-Ressourcen kann das Laden des HTML-Codes und die Auffindbarkeit der zugehörigen Unterressourcen verbessert werden. Das kann sich positiv auf den Largest Contentful Paint (LCP) einer Seite auswirken. Mit Ressourcenhinweisen wie rel="preload" lässt sich die Auffindbarkeit von Ressourcen beeinflussen. Wenn Sie jedoch zu viele davon verwenden, kann es zu Problemen mit der Bandbreitenkonkurrenz kommen. Wenn die HTML-Antwort für eine Navigationsanfrage komprimiert ist, können die darin enthaltenen Ressourcen so schnell wie möglich vom Vorabladeprüfer erkannt werden.
  • Einige LCP-Kandidaten können auch schneller geladen werden, wenn Sie die Komprimierung verwenden. Beispielsweise kann die Ressourcenladezeit von SVG-Bildern, die LCP-Kandidaten sind, durch textbasierte Komprimierung verkürzt werden. Das unterscheidet sich von Optimierungen, die Sie bei anderen Bildtypen vornehmen würden, die von Natur aus durch andere Komprimierungsmethoden komprimiert werden, z. B. wie JPEG-Bilder die verlustbehaftete Komprimierung verwenden.
  • Außerdem können Textknoten auch LCP-Kandidaten sein. Wie die in diesem Leitfaden beschriebenen Techniken funktionieren, hängt davon ab, ob Sie eine Web-Schriftart für Text auf Ihren Webseiten verwenden. Wenn Sie eine Webschriftart verwenden, gelten die Best Practices für die Optimierung von Webschriftarten. Wenn Sie jedoch keine Webfonts verwenden, sondern Systemschriftarten, die ohne Ressourcenlastdauer angezeigt werden, wird diese Dauer durch das Minimieren und Komprimieren Ihres CSS-Codes verkürzt. Das Rendern potenzieller LCP-Textknoten kann also früher erfolgen.

Fazit

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

Wichtiger ist, dass diese Prozesse automatisiert werden. Verwenden Sie für die Minimierung einen Bundler, um die Minimierung auf infrage kommende Ressourcen anzuwenden. Achten Sie darauf, dass die Konfiguration Ihres Webservers die Komprimierung unterstützt, und verwenden Sie die effektivste verfügbare Komprimierung. Um dies so einfach wie möglich zu gestalten, sollten Sie CDNs verwenden, um die Komprimierung zu automatisieren. Sie können Ressourcen nicht nur komprimieren, sondern auch sehr schnell.

Wenn Sie diese grundlegenden Leistungskonzepte in die Architektur Ihrer Website integrieren, können Sie sicherstellen, dass Ihre Bemühungen zur Leistungsoptimierung auf einem guten Fundament beruhen und dass nachfolgende Optimierungen auf einer soliden Grundlage guter grundlegender Praktiken aufbauen können.