Codierung und Übertragungsgröße textbasierter Assets optimieren

Neben dem Entfernen unnötiger Ressourcendownloads lässt sich die Ladegeschwindigkeit der Seite am besten verbessern, indem Sie die Gesamtgröße der Downloads minimieren, indem Sie die verbleibenden Ressourcen optimieren und komprimieren.

Erste Schritte zur Datenkomprimierung

Sobald Sie Ihre Website so eingerichtet haben, dass das Herunterladen nicht verwendeter Ressourcen vermieden wird, besteht der nächste Schritt darin, alle verbleibenden zulässigen Ressourcen zu komprimieren, die der Browser herunterladen muss. Je nach Ressourcentyp (Text, Bilder, Schriftarten usw.) stehen viele verschiedene Techniken zur Auswahl: generische Tools, die auf dem Webserver aktiviert werden können, Optimierungen für die Vorverarbeitung für bestimmte Inhaltstypen und ressourcenspezifische Optimierungen, die Input vom Entwickler erfordern.

Um die bestmögliche Leistung zu erzielen, ist eine Kombination der folgenden Methoden 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 verschiedene Techniken, um die beste Komprimierung zu erzielen.

Der Vorgang zur Reduzierung der Datengröße ist die Datenkomprimierung. Viele Menschen haben Algorithmen, Techniken und Optimierungen beigesteuert, um das Komprimierungsverhältnis, die Komprimierungsgeschwindigkeit und den von verschiedenen Komprimierungsalgorithmen erforderlichen Speicher zu verbessern.

Eine umfassende Beschreibung der Datenkomprimierung würde den Rahmen dieses Leitfadens aber sprengen. Es ist jedoch wichtig, allgemein die Funktionsweise der Komprimierung und die Techniken zu verstehen, mit denen Sie die Größe verschiedener Assets auf Ihren Seiten reduzieren können.

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

Wie können Sie die Größe der vorigen Nachricht, die bei 200 Zeichen beginnt, reduzieren?

  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 einfach senden. Da dies jedoch möglicherweise nicht der Fall ist, lasse es vorerst so.
  3. Die Nutzlast besteht nur aus Text. Auch wenn wir nicht wissen, was der Inhalt ist (Offenbar wird ein "secret-cipher" verwendet), zeigt ein Blick auf den Text aber, dass er viele Redundanzen enthält. Anstatt wiederholte Buchstaben zu senden, können Sie vielleicht einfach die Anzahl der wiederholten Buchstaben zählen und sie effizienter codieren. Beispielsweise wird "AAA" zu "3A", was eine Folge von drei A-Elementen darstellt.

Wenn Sie diese Methoden kombinieren, ergibt sich folgendes Ergebnis:

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

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

Dies ist ein einfaches Beispiel dafür, wie Komprimierungsalgorithmen effektiv die Übertragungsgröße textbasierter Ressourcen reduzieren können. In der Praxis sind die Komprimierungsalgorithmen weitaus ausgefeilter, als das vorherige Beispiel gezeigt hat, und im Web können Komprimierungsalgorithmen verwendet werden, um die Downloadzeit von Ressourcen erheblich zu verkürzen. Durch die Komprimierung textbasierter Assets verbringen Webseiten weniger Zeit mit dem Laden von Ressourcen, sodass Nutzer die Auswirkungen dieser Ressourcen früher als ohne Komprimierung sehen können.

Reduzierung: Vorverarbeitung und kontextspezifische Optimierungen

Die erste hier besprochene Technik ist die Minifizierung. Die Komprimierung ist zwar kein strikter Komprimierungsalgorithmus, aber sie ist 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 dieses Quellcodes auf Produktionswebsites aufrechtzuerhalten, und kann das Laden von Ressourcen im Web verzögern.

Die Reduzierung ist eine Art der inhaltsspezifischen Optimierung, die die Größe der bereitgestellten Ressourcen erheblich reduzieren kann. Sie sollten am besten als Teil des Build- und Bereitstellungsprozesses angewendet werden. Bundler sind beispielsweise eine häufig verwendete Software, die Ressourcen bereits vor der Bereitstellung von neuem Produktionscode auf einer Website automatisch reduzieren kann.

Redundante oder unnötige Daten lassen sich am besten komprimieren, indem sie entfernt werden. 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 seine tatsächliche Bedeutung oder 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>

Betrachten Sie das vorige HTML-Snippet und die drei verschiedenen Inhaltstypen, die es enthält:

  1. HTML-Markup:
  2. CSS zum Anpassen der Präsentation einer Seite.
  3. JavaScript für Interaktionen und andere erweiterte Seitenfunktionen.

Für jeden dieser Inhaltstypen gelten unter anderem unterschiedliche Regeln für gültige Inhalte und unterschiedliche Regeln für die Angabe von Kommentaren. Dennoch ist die Frage, wie sich die Größe dieser Seite reduzieren lässt.

  • Codekommentare sind zwar der beste Freund eines Entwicklers, aber der Browser benötigt sie nicht! Wenn Sie CSS- (/* ... */), HTML- (<!-- ... -->) und JavaScript-Kommentare (// ...) entfernen, verringert sich die Gesamtgröße der Übertragung auf die Seite und ihre Unterressourcen.
  • Ein „smartes“ CSS-Komprimierungsprogramm könnte feststellen, dass wir die Regeln für .awesome-container auf ineffiziente Weise definieren, und die beiden Deklarationen zu einer zusammenfassen, ohne andere Stile zu beeinträchtigen. Dadurch werden mehr Byte eingespart. Bei einer großen Anzahl von CSS-Regeln kann das Entfernen dieser Art von Redundanz summieren. Sie kann jedoch möglicherweise nicht aggressiv angewendet werden, da Selektoren häufig in verschiedenen Kontexten erforderlich sind, z. B. in Medienabfragen.
  • Leerzeichen und Tabs sind praktische Funktionen für Entwickler in HTML, CSS und JavaScript. Ein zusätzliches Komprimierungsprogramm könnte alle Tabs und Leerzeichen entfernen. Im Gegensatz zu anderen Verfahren zur Deduplizierung kann diese Art der Optimierung ziemlich aggressiv angewendet werden, solange solche Leerzeichen oder Tabs nicht für die Darstellung der Seite erforderlich sind. So sollen beispielsweise die Leerzeichen innerhalb der Textausführungen in einem HTML-Dokument beibehalten werden, 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>

Nachdem die vorherigen Schritte angewendet wurden, enthält die Seite 516 auf 204 Zeichen, was einer Einsparung von etwa 60 % entspricht. Er ist zwar nicht gut lesbar, aber nicht nötig, um verwendbar zu sein. Mit modernen Entwicklungspraktiken können Sie außerdem die gut formatierten und lesbaren Versionen Ihres Quellcodes von dem optimierten Code trennen, den Sie an 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 profitieren Sie nicht nur von einer guten Entwicklererfahrung, sondern können gleichzeitig die Leistung zugunsten der Nutzer optimieren.

Das vorherige Beispiel verdeutlicht einen wichtigen Punkt: Ein universelles Komprimierungsprogramm, z. B. eins zur Komprimierung von beliebigem Text, könnte im vorherigen Beispiel die Seite ziemlich gut komprimieren, aber es würde nie die Kommentare entfernen, CSS-Regeln oder Dutzende anderer inhaltsspezifischer Optimierungen minimieren. Aus diesem Grund sind Vorverarbeitung, Reduzierung und andere kontextsensitive Optimierungen wichtig.

In ähnlicher Weise können die oben beschriebenen Techniken auch über textbasierte Assets hinaus erweitert werden. Bilder, Videos und andere Inhaltstypen enthalten jeweils eigene Formen von Metadaten und verschiedenen Nutzlasten. Wenn Sie beispielsweise ein Bild mit einer Kamera aufnehmen, sind in der Datei normalerweise viele zusätzliche Informationen enthalten: Kameraeinstellungen, Standort usw. Abhängig von Ihrer Anwendung können diese Daten kritisch sein (z. B. eine Website zum Teilen von Fotos) oder völlig nutzlos. Sie sollten überlegen, ob es sich lohnt, ihn zu entfernen. In der Praxis können diese Metadaten pro Bild bis zu 10 Kilobyte betragen.

Kurz gesagt: Erstellen Sie als ersten Schritt zur Optimierung der Effizienz Ihrer Assets eine Bestandsaufnahme der verschiedenen Inhaltstypen und überlegen Sie, welche Arten von inhaltsspezifischen Optimierungen Sie vornehmen können, um deren Größe zu reduzieren. Automatisieren Sie diese Optimierungen, indem Sie sie Ihren Build- und Release-Schritten hinzufügen. So sorgen Sie dafür, dass die Optimierungen einheitlich auf jeden neuen Release in der Produktion angewendet werden.

Textkomprimierung mit Komprimierungsalgorithmen

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

  • gzip und Brotli sind gängige Komprimierungsalgorithmen, die bei textbasierten Assets (CSS, JavaScript, HTML) die beste Leistung erzielen.
  • Alle modernen Browser unterstützen die gzip- und Brotli-Komprimierung und bieten im Accept-Encoding-HTTP-Anfrageheader eine Unterstützung für beide an.
  • Ihr Server muss so konfiguriert sein, dass die Komprimierung aktiviert ist. Webserver-Software aktiviert Module häufig, um textbasierte Ressourcen standardmäßig zu komprimieren.
  • Sowohl gzip als auch Brotli lassen sich durch Einstellen des Komprimierungsgrads fein abstimmen, um die Komprimierungsverhältnisse zu verbessern. Bei gzip liegen die Komprimierungseinstellungen zwischen 1 und 9, wobei 9 die beste Option ist. Für Brotli liegt dieser Bereich zwischen 0 und 11, wobei 11 der beste ist. Höhere Komprimierungseinstellungen erfordern jedoch mehr Zeit. Bei dynamisch komprimierten Ressourcen – also zum Zeitpunkt der Anfrage – bieten Einstellungen im mittleren Bereich des Bereichs tendenziell den besten Kompromiss zwischen Komprimierungsverhältnis und Geschwindigkeit. Eine statische Komprimierung ist jedoch möglich, wenn die Antwort vorab komprimiert wird und so die aggressiveste Komprimierungseinstellungen verwendet werden kann, die für jeden Komprimierungsalgorithmus verfügbar sind.
  • Content Delivery Networks (CDNs) bieten in der Regel eine automatische Komprimierung qualifizierender Ressourcen. CDNs können auch die dynamische und statische Komprimierung für Sie verwalten, sodass Sie sich um einen Komprimierungsaspekt weniger Gedanken machen müssen.

gzip und Brotli sind gängige Komprimierungsprogramme, die auf jeden Bytestream angewendet werden können. Intern erinnern sie sich an einen Teil der zuvor untersuchten Inhalte einer Datei und versuchen anschließend, doppelte Datenfragmente effizient zu finden und zu ersetzen.

In der Praxis funktionieren sowohl gzip als auch Brotli am besten bei textbasierten Inhalten und erzielen bei größeren Dateien häufig Komprimierungsraten von 70–90 %. Das Ausführen dieser Algorithmen-Assets, die bereits mit alternativen Algorithmen komprimiert wurden, z. B. die meisten Bildformate, die verlustfreie oder verlustbehaftete Komprimierungstechniken verwenden, führt jedoch kaum oder gar nicht zu einer Verbesserung.

Alle modernen Browser unterstützen gzip und Brotli im Accept-Encoding-HTTP-Anfrageheader. Es liegt jedoch in der Verantwortung des Hostanbieters, dass der Webserver ordnungsgemäß so konfiguriert ist, dass die komprimierte Ressource bereitgestellt wird, wenn der Client sie anfordert.

Datei Algorithmus Nicht komprimierte Größe Komprimierte Größe Verdichtungsverhältnis
angular-1.8.3.js Brotli-Brot 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-Brot 173 KiB 53 KiB 69%
angular-1.8.3.min.js gzip 173 KiB 60 KiB 65 %
jquery-3.7.1.js Brotli-Brot 302 KiB 69 KiB 77%
jquery-3.7.1.js gzip 302 KiB 83 KiB 73 %
jquery-3.7.1.min.js Brotli-Brot 85 KiB 27 KiB 68%
jquery-3.7.1.min.js gzip 85 KiB 30 KiB 65 %
lodash-4.17.21.js Brotli-Brot 531 KiB 73 KiB 86 %
lodash-4.17.21.js gzip 531 KiB 94 KiB 82 %
lodash-4.17.21.min.js Brotli-Brot 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 mit der Brotli- als auch mit der gzip-Komprimierung für einige bekannte JavaScript-Bibliotheken erzielt werden können. Die Einsparungen liegen je nach Datei und Algorithmus zwischen 65% und 86 %. Die maximale Komprimierungsstufe wurde auf jede Datei sowohl für Brotli als auch für gzip angewendet. Wenn möglich, sollten Sie Brotli gegenüber gzip bevorzugen.

Das Aktivieren der Komprimierung ist eine der einfachsten und effektivsten Optimierungen. Wenn Ihre Website das 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 bei ihrer Implementierung sehr effektiv und sorgen dafür, dass Komprimierungsgeschwindigkeit und -verhältnis ausgewogen werden.

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

Die Entwicklertools zeigen die tatsächliche Größe im Vergleich zur Übertragungsgröße an.
Eine Darstellung der Übertragungsgröße (d. h. komprimiert) aller Seitenressourcen im Vergleich zu ihrer tatsächlichen Größe, wie im Netzwerkbereich der Chrome-Entwicklertools dargestellt.

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

  • Die Anzahl der Anfragen, also 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 wurde.
  • Die Ressourcengröße aller Anfragen. Dies gibt an, wie groß die Ressourcen für die Seite sind, nachdem sie dekomprimiert wurden.

Auswirkungen auf Core Web Vitals

Leistungsverbesserungen können nur gemessen werden, wenn sie auch Messwerte enthalten. Die Core Web Vitals-Initiative dient dazu, Messwerte zu entwickeln und zu sensibilisieren, 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 auswirken.

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 Messwerten variieren. In folgenden Fällen können Sie jedoch die Core Web Vitals Ihrer Website verbessern:

  • Komprimierte und komprimierte HTML-Ressourcen können das Laden dieses HTML-Codes und die Auffindbarkeit seiner Unterressourcen verbessern und dadurch deren Last verbessern. Dies kann für den Largest Contentful Paint (LCP) einer Seite von Vorteil sein. Ressourcenhinweise wie rel="preload" können die Auffindbarkeit von Ressourcen beeinflussen, aber zu viele können zu Bandbreitenkonflikten führen. Wenn Sie sicherstellen, dass die HTML-Antwort auf 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 durch Komprimierung auch früher geladen werden. Bei SVG-Bildern, die LCP-Kandidaten sind, kann beispielsweise die Ladezeit von Ressourcen durch die textbasierte Komprimierung reduziert werden. Dies unterscheidet sich von Optimierungen, die Sie an anderen Bildtypen vornehmen würden, die durch andere Komprimierungsmethoden wie die verlustbehaftete Komprimierung von JPEG-Bildern explizit komprimiert werden.
  • Außerdem können Textknoten auch LCP-Kandidaten sein. Die in diesem Leitfaden beschriebenen Verfahren hängen davon ab, ob Sie eine Webschriftart 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 Webschriftarten verwenden, sondern Systemschriftarten, die ohne Ladezeiten von Ressourcen angezeigt werden, reduziert und komprimiert Ihr CSS-Code, um die Ladezeit zu verkürzen und zu komprimieren. Das bedeutet, dass potenzielle LCP-Textknoten früher gerendert werden können.

Fazit

Die Optimierung der Codierung und Übertragung textbasierter Assets ist ein grundlegendes Leistungskonzept, hat aber große Auswirkungen. Sie sollten Ihr Möglichstes tun, damit Ressourcen, die für die Reduzierung und Komprimierung geeignet sind, von diesen Optimierungen profitieren.

Noch wichtiger ist aber, dass diese Prozesse automatisiert werden. Verwenden Sie für die Reduzierung einen Bundler, um die Reduzierung auf zulässige Ressourcen anzuwenden. Sorgen Sie dafür, dass Ihre Webserverkonfiguration Komprimierung unterstützt. Verwenden Sie bei mehr Kompression jedoch die effektivste verfügbare Komprimierung. Um dies so einfach wie möglich zu gestalten, sollten Sie CDNs verwenden, um die Komprimierung für Sie zu automatisieren. Sie können damit nicht nur Ressourcen für Sie komprimieren, sondern auch sehr schnell.

Indem Sie diese grundlegenden Leistungskonzepte in die Architektur Ihrer Website einbinden, können Sie dafür sorgen, dass Ihre Bemühungen zur Leistungsoptimierung gut laufen und nachfolgende Optimierungen auf einer soliden Grundlage bewährter Basispraktiken aufbauen können.