Codierung und Übertragungsgröße textbasierter Assets optimieren

Neben dem Entfernen unnötiger Ressourcendownloads können Sie die Seitenladezeit auch durch Minimieren der Gesamtdownloadgröße verbessern, indem Sie die verbleibenden Ressourcen optimieren und komprimieren.

Nachdem Sie Ihre Website so eingerichtet haben, dass keine nicht verwendeten Ressourcen heruntergeladen werden, besteht der nächste Schritt darin, alle verbleibenden infrage kommenden Ressourcen zu komprimieren, die der Browser herunterladen muss. Je nach Ressourcentyp (Text, Bilder, Schriftarten usw.) stehen viele verschiedene Verfahren zur Auswahl: generische Tools, die auf dem Webserver aktiviert werden können, Optimierungen der Vorverarbeitung für bestimmte Inhaltstypen und ressourcenspezifische Optimierungen, die Eingaben des Entwicklers erfordern.

Um die beste Leistung zu erzielen, ist eine Kombination der folgenden Techniken erforderlich:

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

Das Reduzieren der Datengröße wird als Datenkomprimierung bezeichnet. Viele Menschen haben Algorithmen, Techniken und Optimierungen entwickelt, um die Komprimierungsraten, die Komprimierungsgeschwindigkeit und den von verschiedenen Komprimierungsalgorithmen benötigten Arbeitsspeicher zu verbessern.

Eine vollständige Erläuterung der Datenkomprimierung würde den Rahmen dieses Leitfadens sprengen. Es ist jedoch wichtig, dass Sie grob 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.

Zur Veranschaulichung der Grundprinzipien dieser Techniken betrachten wir den Prozess der Optimierung eines einfachen Textnachrichtenformats, das speziell 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 mit dem Präfix „#“ gekennzeichnet sind. Diese werden auch als Kommentare bezeichnet. Anmerkungen haben keinen Einfluss auf die Bedeutung der Nachricht oder ihr Verhalten.
  2. Nachrichten können Header enthalten, bei denen es sich um Schlüssel/Wert-Paare handelt, die im vorherigen Beispiel durch ":" getrennt sind und am Anfang der Nachricht angezeigt werden.
  3. Nachrichten enthalten Textnutzlasten.

Was kann ich tun, um die Größe der vorherigen Nachricht zu reduzieren, die mit 200 Zeichen beginnt?

  1. Der Kommentar ist interessant, hat aber keinen Einfluss auf die Bedeutung der Nachricht. Sie wird bei der Übertragung der Nachricht entfernt.
  2. Es gibt gute Methoden, 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 aber möglicherweise nicht der Fall. Lassen Sie es daher vorerst so.
  3. Die Nutzlast besteht nur aus Text. Wir wissen zwar nicht, wie der Inhalt wirklich ist (offensichtlich wird ein "secret-cipher" verwendet), aber ein Blick auf den Text zeigt, dass er viel Redundanz enthält. Anstatt wiederholte Buchstaben zu senden, können Sie die Anzahl der wiederholten Buchstaben einfach zählen und sie effizienter codieren. Aus "AAA" wird beispielsweise "3A", was für eine Sequenz von drei A's steht.

Die Kombination dieser Verfahren 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 deutliche Reduzierung.

Dies ist ein einfaches Beispiel dafür, wie Komprimierungsalgorithmen die Übertragungsgröße von textbasierten Ressourcen effektiv reduzieren können. In der Praxis sind Komprimierungsalgorithmen weitaus ausgefeilter als im vorherigen Beispiel dargestellt und im Internet können Komprimierungsalgorithmen verwendet werden, um die Downloadzeit für Ressourcen erheblich zu reduzieren. Wenn Sie textbasierte Assets komprimieren, kann das Laden von Ressourcen auf einer Webseite schneller erfolgen. So sehen Nutzer die Auswirkungen dieser Ressourcen früher als ohne Komprimierung.

Minimierung: Vorverarbeitung und kontextspezifische Optimierungen

Die erste hier beschriebene Methode ist die Minimierung. Die Minimierung ist zwar nicht streng genommen ein Komprimierungsalgorithmus, aber eine Möglichkeit, unnötige und redundante Zeichen im Quellcode zu entfernen, um Ressourcen für Menschen besser lesbar zu machen. Diese Lesbarkeit ist jedoch nicht erforderlich, um die Funktionalität dieses Quellcodes auf Produktionswebsites aufrechtzuerhalten, und kann das Laden von Ressourcen im Web verzögern.

Die Minimierung ist eine Art von inhaltsspezifischer Optimierung, mit der die Größe der bereitgestellten Ressourcen erheblich reduziert werden kann. Diese Optimierungen sollten am besten im Rahmen des Build- und Bereitstellungsprozesses angewendet werden. Beispielsweise sind Bundler eine gängige Art von Software, mit der Ressourcen kurz vor der Bereitstellung neuen Produktionscodes auf einer Website automatisch minimiert werden können.

Redundante oder unnötige Daten lassen sich am besten komprimieren, indem sie sie beseitigen. Sie können jedoch nicht einfach beliebige Daten löschen. In einigen Fällen, 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 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 darin enthaltenen Inhaltstypen an:

  1. HTML-Markup
  2. CSS zur Anpassung 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 bleibt jedoch: „Wie kann die Größe dieser Seite reduziert werden?“

  • Codekommentare sind die besten Freunde von Entwicklern, aber der Browser benötigt sie nicht. Wenn Sie Kommentare aus CSS- (/* ... */), HTML- (<!-- ... -->) und JavaScript-Code (// ...) entfernen, wird die Gesamtübertragungsgröße der Seite und ihrer untergeordneten Ressourcen reduziert.
  • Ein „intelligenter“ CSS-Komprimierer könnte feststellen, dass wir Regeln für .awesome-container auf ineffiziente Weise definieren, und die beiden Deklarationen zu einer zusammenführen, ohne andere Stile zu beeinflussen, wodurch mehr Bytes eingespart werden. Wenn Sie diese Art von Redundanz in einer großen Anzahl von CSS-Regeln entfernen, kann sich das positiv auswirken. Diese Maßnahme sollte jedoch nicht zu aggressiv angewendet werden, da Auswahlen oft in verschiedenen Kontexten notwendigerweise dupliziert werden, z. B. in Medienabfragen.
  • Leerzeichen und Tabulatoren sind praktische Funktionen für Entwickler in HTML, CSS und JavaScript. Ein zusätzliches Komprimierungsprogramm könnte alle Tabulatoren und Leerzeichen entfernen. Im Gegensatz zu anderen Deduplizierungstechniken kann diese Art der Optimierung ziemlich aggressiv angewendet werden, solange diese Leerzeichen oder Tabulatoren nicht für die Darstellung der Seite erforderlich sind. So sollten Sie beispielsweise die Leerzeichen innerhalb von Textabsätzen in einem HTML-Dokument beibehalten, da sie für die Lesbarkeit von Inhalten sorgen, 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>

Nach der Anwendung der vorherigen Schritte enthält die Seite nur noch 204 Zeichen statt 516, was einer Einsparung von etwa 60 % entspricht. Zugegeben, es ist nicht sehr gut lesbar, aber das ist auch nicht nötig, damit es nutzbar ist. Dank moderner Entwicklungspraktiken können Sie die gut formatierten und lesbaren Versionen Ihres Quellcodes auch getrennt vom gut optimierten Code aufbewahren, den Sie für die Produktion bereitstellen. In Kombination mit Quellkarten, die eine lesbare Darstellung Ihres umgewandelten Produktionscodes bieten und die Fehlerbehebung in der Produktion erleichtern, können Sie die Entwicklerfreundlichkeit verbessern und gleichzeitig die Leistung im Hinblick auf die Nutzerfreundlichkeit optimieren.

Im vorherigen Beispiel wird ein wichtiger Punkt veranschaulicht: Ein universeller Komprimierungsprogramm, das beispielsweise zur Komprimierung von beliebigem Text entwickelt wurde, könnte im vorigen Beispiel die Seite recht gut komprimieren, aber es wüsste nie, die Kommentare zu entfernen, CSS-Regeln auszublenden oder Dutzende anderer inhaltsspezifischer Optimierungen vorzunehmen. Deshalb sind Vorverarbeitung, Minimierung und andere kontextbezogene Optimierungen wichtig.

Die oben beschriebenen Techniken können auch auf andere textbasierte Assets angewendet werden. 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 normalerweise viele zusätzliche Informationen: Kameraeinstellungen, Standort usw. Je nach Anwendung können diese Daten kritisch sein (z. B. auf einer Website zum Teilen von Fotos) oder völlig nutzlos. Sie sollten überlegen, ob es sich lohnt, es zu entfernen. In der Praxis können diese Metadaten pro Bild bis zu zehn Kilobyte ausmachen.

Als ersten Schritt zur Optimierung der Effizienz Ihrer Assets sollten Sie also ein Inventar der verschiedenen Inhaltstypen erstellen und überlegen, welche inhaltsspezifischen Optimierungen Sie anwenden können, um ihre Größe zu reduzieren. Nachdem Sie diese Optimierungen ermittelt haben, automatisieren Sie sie, indem Sie sie Ihren Build- und Release-Schritten hinzufügen. So werden die Optimierungen bei jedem neuen Release in der Produktion konsistent angewendet.

Textkomprimierung mit Komprimierungsalgorithmen

Im nächsten Schritt wird ein Komprimierungsalgorithmus auf die textbasierten Assets angewendet, um ihre Größe zu reduzieren. Dabei wird noch ein Schritt weitergegangen: Es wird intensiv 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 führt zu einer weiteren und deutlichen Reduzierung dieser Ressourcen und damit zu kürzeren Downloadzeiten.

  • gzip und Brotli sind gängige Komprimierungsalgorithmen, die bei textbasierten Assets wie CSS, JavaScript und HTML am besten funktionieren.
  • Alle modernen Browser unterstützen die GZIP- und Brotli-Komprimierung und geben die Unterstützung für beide im Accept-Encoding-HTTP-Anfrageheader an.
  • Ihr Server muss so konfiguriert sein, dass die Komprimierung aktiviert ist. Webserversoftware aktiviert häufig standardmäßig Module, um textbasierte Ressourcen zu komprimieren.
  • Sowohl gzip als auch Brotli können durch Anpassung des Komprimierungsgrades optimiert werden. Bei gzip reichen die Komprimierungseinstellungen von 1 bis 9, wobei 9 die beste ist. Bei Brotli ist dieser Bereich 0 bis 11, wobei 11 der beste Wert 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. Es ist jedoch eine statische Komprimierung möglich. Dabei wird die Antwort vorab komprimiert und es können daher die aggressivsten Komprimierungseinstellungen für jeden Komprimierungsalgorithmus verwendet werden.
  • Content Delivery Networks (CDNs) bieten in der Regel eine automatische Komprimierung qualifizierter Ressourcen. CDNs können auch die dynamische und statische Komprimierung für Sie verwalten, sodass Sie sich um einen Aspekt der Komprimierung kümmern müssen.

gzip und Brotli sind gängige Komprimierungsprogramme, die auf jeden Byte-Stream angewendet werden können. Im Hintergrund speichern sie einen Teil des zuvor geprüften Inhalts einer Datei und versuchen anschließend, doppelte Datenfragmente effizient zu finden und zu ersetzen.

In der Praxis eignen sich sowohl gzip als auch Brotli am besten für textbasierte Inhalte. 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. auf die meisten Bildformate mit verlustfreier oder verlustbehafteter Komprimierung, führt dies zu kaum oder gar keiner Verbesserung.

Alle modernen Browser geben im Accept-Encoding-HTTP-Anfrageheader an, dass sie gzip und Brotli unterstützen. 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 %

In der Tabelle oben sehen Sie, wie viel Speicherplatz Sie mit der Brotli- und der GZIP-Komprimierung bei einigen bekannten JavaScript-Bibliotheken sparen können. Die Einsparungen betragen je nach Datei und Algorithmus zwischen 65 % und 86 %. Zum Vergleich wurde für jede Datei sowohl bei Brotli als auch bei gzip die maximale Komprimierungsstufe angewendet. Verwenden Sie nach Möglichkeit Brotli gegenüber gzip.

Die Komprimierung zu aktivieren, ist eine der einfachsten und effektivsten Optimierungen. Wenn Ihre Website dies nicht nutzt, lassen Sie sich eine große Chance entgehen, die Leistung für Ihre Nutzer zu verbessern. Glücklicherweise stellen viele Webserver Standardkonfigurationen bereit, die diese wichtige Optimierung ermöglichen. Insbesondere CDNs sind sehr effektiv bei der Implementierung dieser Konfiguration, um ein ausgeglichenes Verhältnis von Komprimierungsgeschwindigkeit und -verhältnis zu gewährleisten.

Wenn Sie die Komprimierung in Aktion sehen möchten, öffnen Sie die Chrome-Entwicklertools, den Bereich Netzwerk, laden Sie eine beliebige Seite und sehen Sie sich ganz unten im Bereich „Netzwerk“ an.

DevTools-Anzeige der tatsächlichen Größe im Vergleich zur Übertragungsgröße
Eine Darstellung der komprimierten Größe aller Seitenressourcen im Vergleich zu ihrer tatsächlichen Größe, wie sie im Netzwerkbereich der Chrome-Entwicklertools dargestellt wird.

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

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

Auswirkungen auf die Core Web Vitals

Leistungsverbesserungen können nur dann gemessen werden, wenn es Messwerte gibt, die diese Verbesserungen widerspiegeln. Die Core Web Vitals-Initiative soll für Messwerte sensibilisieren, die die tatsächliche Nutzerfreundlichkeit widerspiegeln. Dies unterscheidet sich von 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 auf Ihrer Website anwenden, können die Auswirkungen auf Core Web Vitals je nach optimierten Ressourcen und verwendeten Messwerten variieren. In folgenden Fällen können diese Optimierungen jedoch die Core Web Vitals Ihrer Website verbessern:

  • Reduzierte und komprimierte HTML-Ressourcen können das Laden dieses HTML-Codes und die Sichtbarkeit seiner Unterressourcen und damit auch das Laden dieser Ressourcen verbessern. Das kann sich positiv auf den LCP (Largest Contentful Paint) einer Seite auswirken. Mithilfe von Ressourcenhinweisen wie rel="preload" lässt sich die Auffindbarkeit von Ressourcen beeinflussen. Wenn Sie jedoch zu viele davon verwenden, kann es zu Bandbreitenkonflikten kommen. Wenn die HTML-Antwort für eine Navigationsanfrage komprimiert ist, können die darin enthaltenen Ressourcen vom Vorablade-Scanner so schnell wie möglich gefunden werden.
  • Einige LCP-Kandidaten können durch Komprimierung auch schneller geladen werden. So kann beispielsweise die Dauer der Ressourcenladezeit von SVG-Bildern, die LCP-Kandidaten sind, durch textbasierte Komprimierung reduziert werden. Das unterscheidet sich von Optimierungen, die Sie bei anderen Bildtypen vornehmen würden, die durch andere Komprimierungsmethoden komprimiert werden, z. B. die verlustbehaftete Komprimierung von JPEG-Bildern.
  • Außerdem können Textknoten LCP-Kandidaten sein. Die in diesem Leitfaden beschriebenen Verfahren hängen davon ab, ob Sie für den Text auf Ihren Webseiten eine Webschriftart verwenden. Wenn Sie eine Webschriftart verwenden, gelten die Best Practices für die Optimierung von Webschriftarten. Wenn Sie jedoch keine Webfonts, sondern Systemschriften verwenden, die ohne Ressourcenladezeit angezeigt werden, wird diese Zeit durch Minimieren und Komprimieren Ihres CSS verkürzt. Das bedeutet, dass potenzielle LCP-Textknoten früher gerendert werden können.

Fazit

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

Und was noch wichtiger ist: Stellen Sie sicher, dass diese Prozesse automatisiert werden. Verwenden Sie einen Bundler, um die Minimierung auf geeignete Ressourcen anzuwenden. Achte darauf, dass deine Webserverkonfiguration Komprimierung unterstützt. Verwende aber zusätzlich die effektivste verfügbare Komprimierung. Verwenden Sie CDNs, um die Komprimierung zu automatisieren. So können Sie Ressourcen nicht nur komprimieren, sondern auch sehr schnell.

Wenn Sie diese Leistungsgrundlagen in die Architektur Ihrer Website einbinden, können Sie dafür sorgen, dass Ihre Bemühungen zur Leistungsoptimierung auf einem soliden Fundament aufbauen und dass nachfolgende Optimierungen auf einer soliden Grundlage aus guten Grundpraktiken beruhen.