Content Delivery Networks (CDNs)

Verbessern Sie die Leistung mithilfe eines Content Delivery Network.

Katie Hempenius

Content Delivery Networks (CDNs) verbessern die Websiteleistung, indem ein verteiltes Servernetzwerk verwendet wird, um Ressourcen für Nutzer bereitzustellen. CDNs reduzieren die Serverlast, senken außerdem die Serverkosten und eignen sich gut für die Verarbeitung von Trafficspitzen. In diesem Artikel wird erläutert, wie CDNs funktionieren. Außerdem erhalten Sie plattformunabhängige Hinweise zur Auswahl, Konfiguration und Optimierung einer CDN-Einrichtung.

Überblick

Ein Content Delivery Network besteht aus einem Netzwerk von Servern, die für die schnelle Lieferung von Inhalten an Nutzer optimiert sind. Obwohl CDNs vermutlich am besten für die Bereitstellung von Cache-Inhalten bekannt sind, können CDNs auch die Bereitstellung von nicht im Cache speicherbarem Inhalt verbessern. Generell gilt: Je mehr Inhalte von Ihrem CDN bereitgestellt werden, desto besser.

Grundsätzlich beruhen die Leistungsvorteile von CDNs auf einer Reihe von Prinzipien: CDN-Server befinden sich näher an den Nutzern als Ursprungsserver und haben daher eine kürzere Umlaufzeit (RTT). Netzwerkoptimierungen ermöglichen es CDNs, Inhalte schneller bereitzustellen, als wenn sie „direkt“ vom Ursprungsserver geladen werden. Außerdem erübrigt sich die Übertragung von Anfragen zum Ursprungsserver durch CDN-Caches.

Wichtiger Begriff : Ursprungsserver bezieht sich auf den Server, von dem ein CDN Inhalte abruft.

Ressourcenbereitstellung

Auch wenn es nicht intuitiv erscheint, ist die Verwendung eines CDN zum Bereitstellen von Ressourcen (auch nicht im Cache speicherbaren Ressourcen) in der Regel schneller als das Laden der Ressource durch den Nutzer „direkt“ von Ihren Servern.

Wenn ein CDN verwendet wird, um Ressourcen aus dem Ursprung bereitzustellen, wird zwischen dem Client und einem nahe gelegenen CDN-Server eine neue Verbindung hergestellt. Der Rest des Weges, also die Datenübertragung zwischen dem CDN-Server und dem Ursprung, erfolgt über das CDN-Netzwerk. Oftmals sind bestehende, persistente Verbindungen zum Ursprung enthalten. Dies hat zwei Vorteile: Durch das Beenden der neuen Verbindung so nah am Nutzer wie möglich werden unnötige Kosten für die Verbindungseinrichtung vermieden (das Herstellen einer neuen Verbindung ist teuer und erfordert mehrere Umläufe). Bei der Verwendung einer vorbereiteten Verbindung können Daten sofort mit maximalem Durchsatz übertragen werden.

Einige CDNs verbessern dies noch weiter, indem sie Traffic über mehrere CDN-Server im Internet zum Ursprung weiterleiten. Verbindungen zwischen CDN-Servern werden über zuverlässige und hochoptimierte Routen hergestellt und nicht über Routen, die durch das Border Gateway Protocol (BGP) bestimmt werden. Obwohl BGP das De-facto-Routingprotokoll des Internets ist, sind seine Routingentscheidungen nicht immer leistungsorientiert. Daher sind BGP-bestimmte Routen wahrscheinlich weniger leistungsfähig als die genau abgestimmten Routen zwischen CDN-Servern.

Caching

Da Ressourcen auf den Servern eines CDN im Cache gespeichert werden, muss eine Anfrage nicht bis zum Ursprung weitergeleitet werden, damit sie verarbeitet werden kann. Dadurch wird die Ressource schneller bereitgestellt und der Ursprungsserver wird dadurch entlastet.

Ressourcen zum Cache hinzufügen

Die am häufigsten verwendete Methode zum Füllen von CDN-Caches ist die Verwendung der CDN-Pull-Ressourcen, sobald sie benötigt werden. Dies wird als „Origin Pull“ bezeichnet. Wenn eine bestimmte Ressource zum ersten Mal aus dem Cache angefordert wird, fordert das CDN sie vom Ursprungsserver an und speichert die Antwort im Cache. Auf diese Weise werden die Inhalte des Cache mit der Zeit erweitert, wenn zusätzliche nicht zwischengespeicherte Ressourcen angefordert werden.

Ressourcen aus dem Cache entfernen

CDNs verwenden die Cache-Bereinigung, um regelmäßig nicht so nützliche Ressourcen aus dem Cache zu entfernen. Außerdem können Websiteinhaber Ressourcen dauerhaft löschen, um sie explizit zu entfernen.

• Cache-Bereinigung

  Caches haben eine begrenzte Speicherkapazität. Wenn ein Cache seine Kapazität fast erreicht hat, schaffen Sie Platz für neue Ressourcen. Dazu werden Ressourcen entfernt, auf die in letzter Zeit nicht zugegriffen wurde oder die viel Speicherplatz belegen. Dieser Vorgang wird als Cache-Bereinigung bezeichnet. Eine Ressource, die aus einem Cache entfernt wird, bedeutet nicht unbedingt, dass sie aus allen Caches in einem CDN-Netzwerk entfernt wurde.

• Löschen

  Das Bereinigen (auch „Cacheentwertung“ genannt) ist ein Mechanismus zum Entfernen einer Ressource aus den Caches eines CDN, ohne darauf warten zu müssen, dass sie abläuft oder entfernt wird. Er wird normalerweise über eine API ausgeführt. Das dauerhafte Löschen ist wichtig, wenn Inhalte zurückgezogen werden müssen, z. B. um Tippfehler, Preisfehler oder falsche Nachrichtenartikel zu korrigieren. Darüber hinaus kann er bei der Caching-Strategie einer Website eine entscheidende Rolle spielen.

  Wenn ein CDN ein nahezu sofortiges dauerhaftes Löschen unterstützt, kann das dauerhafte Löschen als Verfahren zum Verwalten des Caching dynamischer Inhalte verwendet werden: Dynamische Inhalte werden über eine lange TTL im Cache gespeichert und bei jeder Aktualisierung dauerhaft gelöscht. Auf diese Weise ist es möglich, die Caching-Dauer einer dynamischen Ressource zu maximieren, auch wenn im Voraus nicht bekannt ist, wann sich die Ressource ändert. Diese Technik wird manchmal als „Hold-Till-Told-Caching“ bezeichnet.

  Das dauerhafte Löschen erfolgt in der Regel zusammen mit einem Konzept, das als „Cache-Tags“ oder „Ersatz-Cache-Schlüssel“ bezeichnet wird. Mit diesem Mechanismus können Websiteinhaber eine oder mehrere zusätzliche Kennungen (manchmal auch als „Tags“ bezeichnet) mit einer im Cache gespeicherten Ressource verknüpfen. Diese Tags können dann für ein sehr detailliertes dauerhaftes Löschen verwendet werden. Beispielsweise können Sie allen Ressourcen (z. B. /about, /blog), die die Fußzeile Ihrer Website enthalten, ein „Fußzeile“-Tag hinzufügen. Wenn die Fußzeile aktualisiert wird, weisen Sie Ihr CDN an, alle mit dem Tag „footer“ verknüpften Ressourcen dauerhaft zu löschen.

Im Cache speicherbare Ressourcen

Ob und wie eine Ressource im Cache gespeichert werden sollte, hängt davon ab, ob sie öffentlich oder privat bzw. statisch oder dynamisch ist.

Private und öffentliche Ressourcen

• Private Ressourcen

  Private Ressourcen enthalten Daten, die für einen einzelnen Nutzer bestimmt sind, und sollten daher nicht von einem CDN im Cache gespeichert werden. Private Ressourcen sind am Header Cache-Control: private zu erkennen.

• Öffentliche Ressourcen

  Öffentliche Ressourcen enthalten keine nutzerspezifischen Informationen und können daher von einem CDN im Cache gespeichert werden. Eine Ressource kann von einem CDN als im Cache speicherbar betrachtet werden, wenn sie keinen Cache-Control: no-store- oder Cache-Control: private-Header hat. Wie lange eine öffentliche Ressource im Cache gespeichert werden kann, hängt davon ab, wie häufig sich das Asset ändert.

Dynamische und statische Inhalte

• Dynamische Inhalte

  Dynamische Inhalte sind Inhalte, die sich häufig ändern. Eine API-Antwort und eine Store-Startseite sind Beispiele für diesen Inhaltstyp. Die Tatsache, dass sich dieser Inhalt häufig ändert, verhindert jedoch nicht unbedingt, dass er im Cache gespeichert wird. Bei hohem Traffic-Aufkommen kann das Speichern dieser Antworten für sehr kurze Zeiträume (z. B. 5 Sekunden) die Belastung des Ursprungsservers erheblich reduzieren, während die Auswirkungen auf die Datenaktualität kaum beeinträchtigt werden.

• Statische Inhalte

  Statische Inhalte ändern sich selten oder gar nicht. Bilder, Videos und versionierte Bibliotheken sind in der Regel Beispiele für diesen Inhaltstyp. Da sich statische Inhalte nicht ändern, sollten sie mit einer langen Gültigkeitsdauer (TTL) im Cache gespeichert werden, z. B. 6 Monate oder 1 Jahr.

CDN auswählen

Die Leistung ist in der Regel ein wichtiger Faktor bei der Auswahl eines CDN. Bei der Auswahl eines CDN müssen Sie jedoch alle anderen Features eines CDN (z. B. Sicherheits- und Analysefunktionen) sowie die Preise, den Support und das Onboarding berücksichtigen.

Leistung

Grundsätzlich kann die Leistungsstrategie eines CDN als Kompromiss zwischen der Minimierung der Latenz und der Maximierung der Cache-Trefferquote betrachtet werden. CDNs mit vielen Points of Presence (PoPs) können eine geringere Latenz bieten. Allerdings können dadurch die Cache-Trefferquoten geringer ausfallen, da der Traffic auf mehr Caches aufgeteilt wird. Umgekehrt können CDNs mit weniger PoPs geografisch weiter vom Nutzer entfernt sein, aber höhere Cache-Trefferquoten erzielen.

Aus diesem Grund verwenden einige CDNs einen mehrstufigen Caching-Ansatz: PoPs, die sich in der Nähe der Nutzer befinden (auch als „Edge-Caches“ bezeichnet), werden durch zentrale PoPs ergänzt, die höhere Cache-Trefferraten haben. Wenn ein Edge-Cache eine Ressource nicht finden kann, sucht er von einem zentralen PoP nach der Ressource. Bei diesem Ansatz wird eine geringfügig höhere Latenz eingetauscht, um die Wahrscheinlichkeit zu erhöhen, dass die Ressource aus einem CDN-Cache – aber nicht unbedingt von einem Edge-Cache – bereitgestellt werden kann.

Der Kompromiss zwischen der Minimierung der Latenz und der Maximierung der Cache-Trefferquote ist ein Spektrum. Es gibt keinen bestimmten Ansatz, der generell besser ist. Je nach Art Ihrer Website und deren Nutzerbasis werden Sie jedoch feststellen, dass eine dieser Ansätze eine deutlich bessere Leistung liefert als der andere.

Die CDN-Leistung kann je nach Region, Tageszeit und sogar aktuellen Ereignissen stark variieren. Es ist zwar immer sinnvoll, die Leistung eines CDNs selbst zu recherchieren, aber es kann schwierig sein, die genaue Leistung vorherzusagen, die Sie von einem CDN erhalten.

Auswirkungen auf Largest Contentful Paint (LCP)

Wie bereits in diesem Artikel erläutert, besteht der Hauptzweck eines CDN darin, die Latenz zu verringern, indem Ressourcen an Server verteilt werden, die sich geografisch näher bei den Nutzern befinden. Der Hauptvorteil eines CDN ist daher, dass es die Ladeleistung verbessert. Insbesondere die Time to First Byte (TTFB) einer Ressource kann erheblich verbessert werden, wenn ein CDN in die serverseitige Architektur Ihrer Website eingebunden wird.

TTFB ist zwar kein nutzerbezogener Leistungsmesswert, aber ein wichtiger Messwert für die Diagnose von Problemen mit dem nutzerbezogenen Messwert (Largest Contentful Paint).

CDNs sind besonders effektiv bei der Verbesserung des LCP, da sie sowohl die Dokumentübermittlung (durch Reduzierung der TTFB bei der Verbindungseinrichtung und Caching des Dokuments) als auch die Bereitstellung aller statischen Ressourcen verbessern können, die zum Rendern des LCP-Elements erforderlich sind.

Zusätzliche Funktionen

CDNs bieten neben ihrem zentralen CDN-Angebot in der Regel eine Vielzahl von Features. Zu den häufig angebotenen Funktionen gehören: Load-Balancing, Bildoptimierung, Videostreaming, Edge-Computing und Sicherheitsprodukte.

CDN einrichten und konfigurieren

Idealerweise sollten Sie für die Bereitstellung Ihrer gesamten Website ein CDN verwenden. Der Einrichtungsprozess besteht aus der Registrierung bei einem CDN-Anbieter und dem Aktualisieren des CNAME-DNS-Eintrags, sodass er auf den CDN-Anbieter verweist. Der CNAME-Eintrag für www.example.com könnte beispielsweise auf example.my-cdn.com verweisen. Aufgrund dieser DNS-Änderung wird der Traffic zu Ihrer Website über das CDN weitergeleitet.

Wenn die Verwendung eines CDN für die Bereitstellung aller Ressourcen nicht infrage kommt, können Sie ein CDN so konfigurieren, dass nur ein Teil der Ressourcen bereitgestellt wird – z. B. nur statische Ressourcen. Dazu erstellen Sie einen separaten CNAME-Eintrag, der nur für Ressourcen verwendet wird, die vom CDN bereitgestellt werden sollen. Sie könnten beispielsweise einen static.example.com-CNAME-Eintrag erstellen, der auf example.my-cdn.com verweist. Außerdem müssen Sie die URLs der vom CDN bereitgestellten Ressourcen so umschreiben, dass sie auf die von Ihnen erstellte Subdomain static.example.com verweisen.

Ihr CDN wird zwar jetzt eingerichtet, Ihre Konfiguration kann jedoch ineffizient sein. In den nächsten beiden Abschnitten dieses Artikels erfahren Sie, wie Sie Ihr CDN optimal nutzen, indem Sie die Cache-Trefferquote erhöhen und Leistungsfeatures aktivieren.

Cache-Trefferquote verbessern

Bei einer effektiven CDN-Einrichtung werden so viele Ressourcen wie möglich aus dem Cache bereitgestellt. Dies wird normalerweise anhand der Cache-Trefferquote (CHR) gemessen. Die Cache-Trefferquote ist definiert als die Anzahl der Cache-Treffer geteilt durch die Gesamtzahl der Anfragen während eines bestimmten Zeitintervalls.

Ein neu initialisierter Cache hat einen CHR von 0, dieser erhöht sich jedoch, wenn der Cache mit Ressourcen gefüllt wird. Für die meisten Websites ist eine CHR von 90% ein gutes Ziel. Ihr CDN-Anbieter stellt Ihnen Analysen und Berichte zu Ihrer CHR zur Verfügung.

Wenn Sie die CHR optimieren, müssen Sie als Erstes überprüfen, ob alle im Cache speicherbaren Ressourcen für den richtigen Zeitraum im Cache gespeichert werden. Dies ist eine einfache Bewertung, die von allen Websites durchgeführt werden sollte.

Die nächste Stufe der CHR-Optimierung ist grundsätzlich die Feinabstimmung der CDN-Einstellungen, damit logisch äquivalente Serverantworten nicht separat im Cache gespeichert werden. Diese Ineffizienz tritt häufig auf, weil Faktoren wie Suchparameter, Cookies und Anfrageheader das Caching beeinflussen.

Erste Prüfung

Die meisten CDNs bieten Cache-Analysen. Darüber hinaus können Sie auch Tools wie WebPageTest und Lighthouse verwenden, um schnell zu überprüfen, ob alle statischen Ressourcen einer Seite für den richtigen Zeitraum im Cache gespeichert werden. Dies wird erreicht, indem die HTTP-Cache-Header jeder Ressource geprüft werden. Wenn Sie eine Ressource mit der maximal geeigneten Gültigkeitsdauer (TTL) zwischenspeichern, werden unnötige Ursprungsabrufe in Zukunft vermieden und dadurch die CHR erhöht.

In der Regel muss mindestens einer der folgenden Header festgelegt werden, damit eine Ressource von einem CDN im Cache gespeichert werden kann:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

Außerdem wird empfohlen, die Anweisung Cache-Control: immutable festzulegen, obwohl dies keinen Einfluss darauf hat, ob oder wie eine Ressource von einem CDN im Cache gespeichert wird.Cache-Control: immutable gibt an, dass eine Ressource „während ihrer Lebensdauer nicht aktualisiert wird“. Daher validiert der Browser die Ressource nicht noch einmal, wenn sie aus dem Browsercache bereitgestellt wird, wodurch eine unnötige Serveranfrage eliminiert wird. Diese Anweisung wird nur von Firefox und Safari unterstützt – von Chromium-basierten Browsern nicht. Dieses Problem verfolgt die Chromium-Unterstützung für Cache-Control: immutable. Wenn Sie dieses Problem markieren, können Sie die Unterstützung für diese Funktion fördern.

Eine ausführlichere Erläuterung des HTTP-Cachings finden Sie unter Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern.

Abstimmung

Eine etwas vereinfachte Erklärung der Funktionsweise von CDN-Caches besteht darin, dass die URL einer Ressource als Schlüssel zum Caching und Abrufen der Ressource aus dem Cache verwendet wird. In der Praxis gilt dies immer noch vorwiegend, wird aber durch die Auswirkungen von Anfrage-Headern und Abfrageparametern etwas kompliziert. Daher ist das Umschreiben von Anfrage-URLs eine wichtige Technik, um die CHR zu maximieren und sicherzustellen, dass den Nutzern der richtige Inhalt angezeigt wird. Eine ordnungsgemäß konfigurierte CDN-Instanz sorgt für das richtige Gleichgewicht zwischen einem übermäßig detaillierten Caching (was die CHR schadet) und einem nicht ausreichend detaillierten Caching (was dazu führt, dass Nutzern falsche Antworten geliefert werden).

Abfrageparameter

CDNs berücksichtigen beim Speichern einer Ressource standardmäßig Abfrageparameter. Kleine Änderungen an der Verarbeitung von Abfrageparametern können jedoch erhebliche Auswirkungen auf die CHR haben. Beispiel:

• Unnötige Abfrageparameter

  Standardmäßig speichert ein CDN example.com/blog und example.com/blog?referral_id=2zjk getrennt im Cache, obwohl es sich wahrscheinlich um dieselbe zugrunde liegende Ressource handelt. Dieses Problem lässt sich beheben, indem die CDN-Konfiguration so angepasst wird, dass der referral\_id-Abfrageparameter ignoriert wird.

• Reihenfolge des Abfrageparameters

  Ein CDN speichert example.com/blog?id=123&query=dogs getrennt von example.com/blog?query=dogs&id=123 im Cache. Bei den meisten Websites spielt die Reihenfolge der Abfrageparameter keine Rolle. Daher wird die CHR erhöht, wenn Sie das CDN so konfigurieren, dass die Suchparameter sortiert werden (wodurch die URL normalisiert wird, die zum Speichern der Serverantwort verwendet wird).

Variieren

Der Antwortheader Vary informiert Cache darüber, dass die Serverantwort für eine bestimmte URL je nach den für die Anfrage festgelegten Headern variieren kann (z. B. die Anfrageheader Accept-Language oder Accept-Encoding). Daher wird ein CDN angewiesen, diese Antworten separat im Cache zu speichern. Der Vary-Header wird von CDNs nicht umfassend unterstützt und kann dazu führen, dass eine ansonsten im Cache speicherbare Ressource nicht aus einem Cache bereitgestellt wird.

Obwohl die Vary-Kopfzeile ein nützliches Tool sein kann, schadet eine unangemessene Verwendung der CHR. Wenn Sie Vary verwenden, hilft die Normalisierung von Anfrageheadern außerdem dabei, die CHR zu verbessern. Ohne Normalisierung würden beispielsweise die Anfrageheader Accept-Language: en-US und Accept-Language: en-US,en;q=0.9 zwei separate Cache-Einträge ergeben, obwohl ihr Inhalt wahrscheinlich identisch wäre.

Kekse

Cookies werden bei Anfragen über den Header Cookie gesetzt, bei Antworten im Header Set-Cookie. Die unnötige Verwendung des Set-Cookie-Headers sollte vermieden werden, da Caches normalerweise Serverantworten, die diesen Header enthalten, normalerweise nicht im Cache speichern.

Leistungsfunktionen

In diesem Abschnitt werden die Leistungsfunktionen erläutert, die häufig von CDNs als Bestandteil ihres zentralen Produktangebots angeboten werden. Viele Websites vergessen diese Funktionen zu aktivieren, was zu Leistungseinbußen führen könnte.

Komprimierung

Alle textbasierten Antworten sollten mit gzip oder Brotli komprimiert werden. Wenn Sie die Wahl haben, entscheiden Sie sich für Brotli statt gzip. Brotli ist ein neuerer Komprimierungsalgorithmus, mit dem im Vergleich zu gzip höhere Komprimierungsverhältnisse erzielt werden können.

Es gibt zwei CDN-Unterstützung für die Brotli-Komprimierung: „Brotli vom Ursprung“ und „automatische Brotli-Komprimierung“.

Brotli ab dem Ursprung

Bei Brotli aus dem Ursprung stellt ein CDN Ressourcen bereit, die vom Ursprung nach Brotli komprimiert wurden. Obwohl dies wie eine Funktion erscheint, die von allen CDNs sofort unterstützt werden sollte, erfordert sie, dass ein CDN mehrere Versionen (mit anderen Worten: mit GZIP und Brotli komprimierte Versionen) der Ressource für eine bestimmte URL im Cache speichern kann.

Automatische Brotli-Komprimierung

Bei der automatischen Brotli-Komprimierung werden Ressourcen durch das CDN komprimiert. CDNs können sowohl im Cache speicherbare als auch nicht im Cache speicherbare Ressourcen komprimieren.

Wenn eine Ressource zum ersten Mal angefordert wird, wird sie mit einer Komprimierung bereitgestellt, die ausreichend ist, z. B. Brotli-5. Diese Art der Komprimierung kann sowohl auf im Cache speicherbare als auch auf nicht speicherbare Ressourcen angewendet werden.

Ist eine Ressource im Cache speicherbar, verwendet das CDN Offlineverarbeitung, um sie mit einer leistungsstärkeren, aber deutlich langsameren Komprimierung zu komprimieren – zum Beispiel mit Brotli-11. Nach Abschluss dieser Komprimierung wird die stärker komprimierte Version im Cache gespeichert und für nachfolgende Anfragen verwendet.

Best Practices für Komprimierung

Websites, die die Leistung maximieren möchten, sollten die Brotli-Komprimierung sowohl auf ihren Ursprungsserver als auch auf das CDN anwenden. Mit der Brotli-Komprimierung am Ursprung wird die Übertragungsgröße von Ressourcen minimiert, die nicht aus dem Cache bereitgestellt werden können. Um Verzögerungen bei der Verarbeitung von Anfragen zu vermeiden, sollte der Ursprung dynamische Ressourcen mit einer ziemlich konservativen Komprimierung komprimieren – z. B. Brotli-4. Statische Ressourcen können mit Brotli-11 komprimiert werden. Wenn ein Ursprung Brotli nicht unterstützt, kann gzip-6 zum Komprimieren dynamischer Ressourcen verwendet werden; mit gzip-9 können Sie statische Ressourcen komprimieren.

TLS 1.3

TLS 1.3 ist die neueste Version von Transport Layer Security (TLS), das von HTTPS verwendete kryptografische Protokoll. TLS 1.3 bietet im Vergleich zu TLS 1.2 einen besseren Datenschutz und eine bessere Leistung.

TLS 1.3 verkürzt den TLS-Handshake von zwei Roundtrips auf einen. Bei Verbindungen mit HTTP/1 oder HTTP/2 reduziert die Verkürzung des TLS-Handshakes auf einen Roundtrip die Verbindungseinrichtungszeit um 33%.

HTTP/2 und HTTP/3

HTTP/2 und HTTP/3 bieten beide Leistungsvorteile gegenüber HTTP/1. HTTP/3 bietet potenzielle Leistungsvorteile. HTTP/3 ist noch nicht vollständig standardisiert, wird aber weitgehend unterstützt.

HTTP/2

Falls HTTP/2 noch nicht standardmäßig für Ihr CDN aktiviert ist, sollten Sie das in Betracht ziehen. HTTP/2 bietet gegenüber HTTP/1 mehrere Leistungsvorteile und wird von allen gängigen Browsern unterstützt. Zu den Leistungsmerkmalen von HTTP/2 gehören Multiplexverfahren, Streampriorisierung und Header-Komprimierung.

• Multiplexverfahren

  Multiplexing ist wahrscheinlich die wichtigste Funktion von HTTP/2. Mit Multiplexing kann eine einzelne TCP-Verbindung mehrere Anfrage-Antwort-Paare gleichzeitig verarbeiten. Dadurch werden unnötige Verbindungseinrichtungen vermieden. Da die Anzahl der Verbindungen, die ein Browser zu einem bestimmten Zeitpunkt öffnen kann, begrenzt ist, hat dies auch die Folge, dass der Browser jetzt in der Lage ist, mehr Ressourcen einer Seite gleichzeitig anzufordern. Beim Multiplexing sind theoretisch keine HTTP/1-Optimierungen wie Verkettung und Sprite Sheets erforderlich. In der Praxis bleiben diese Verfahren jedoch relevant, da größere Dateien besser komprimiert werden können.

• Streampriorisierung

  Multiplexing ermöglicht mehrere gleichzeitige Streams. Die Streampriorisierung bietet eine Schnittstelle zum Kommunizieren der relativen Priorität jedes dieser Streams. So kann der Server die wichtigsten Ressourcen zuerst senden, auch wenn sie nicht zuerst angefordert wurden.

Die Stream-Priorisierung wird vom Browser über eine Abhängigkeitsstruktur festgelegt und ist lediglich eine Präferenz. Mit anderen Worten: Der Server ist nicht verpflichtet, die vom Browser vorgegebenen Prioritäten zu erfüllen oder zu berücksichtigen. Die Streampriorisierung wird effektiver, wenn ein größerer Teil einer Website über ein CDN bereitgestellt wird.

CDN-Implementierungen der HTTP/2-Ressourcenpriorisierung variieren stark. Um herauszufinden, ob Ihr CDN die HTTP/2-Ressourcenpriorisierung vollständig und ordnungsgemäß unterstützt, lesen Sie Is HTTP/2 Fast Yet? (Ist HTTP/2 Fast Yet?).

Der Wechsel Ihrer CDN-Instanz zu HTTP/2 muss zwar größtenteils umgeschaltet werden, aber es ist wichtig, diese Änderung gründlich zu testen, bevor Sie sie in der Produktion aktivieren. HTTP/1 und HTTP/2 verwenden dieselben Konventionen für Anfrage- und Antwortheader, aber HTTP/2 ist weitaus weniger nachsichtig, wenn diese Konventionen nicht eingehalten werden. Daher können nicht spezifikationsgemäße Praktiken wie das Einfügen von Nicht-ASCII- oder Großbuchstaben in Headern zu Fehlern führen, sobald HTTP/2 aktiviert ist. In diesem Fall schlägt der Browser-Download der Ressource fehl. Der fehlgeschlagene Downloadversuch wird in den Entwicklertools auf dem Tab „Netzwerk“ angezeigt. Außerdem wird in der Konsole die Fehlermeldung „ERR_HTTP2_PROTOCOL_ERROR“ angezeigt.

HTTP/3

HTTP/3 ist der Nachfolger von HTTP/2. Seit September 2020 bieten alle gängigen Browser experimentelle Unterstützung für HTTP/3 und einige CDNs unterstützen diese Funktion. Die Leistung ist der Hauptvorteil von HTTP/3 gegenüber HTTP/2. HTTP/3 vermeidet Head-of-Line-Blockierung auf Verbindungsebene und verkürzt die Zeit zum Einrichten der Verbindung.

• Keine Head-of-Line-Blockierungen

  Mit HTTP/2 wurde Multiplexing eingeführt, eine Funktion, mit der über eine einzelne Verbindung mehrere Datenstreams gleichzeitig übertragen werden können. Bei HTTP/2 blockiert ein einzelnes gelöschtes Paket jedoch alle Streams einer Verbindung. Dies wird als Head-of-Line-Blockierung bezeichnet. Bei HTTP/3 blockiert ein verworfenes Paket nur einen einzelnen Stream. Diese Verbesserung ist hauptsächlich auf HTTP/3 mit UDP (HTTP/3 über QUIC) anstelle von TCP zurückzuführen. Daher ist HTTP/3 besonders nützlich für die Datenübertragung über überlastete oder verlustbehaftete Netzwerke.

• Schnellere Einrichtungszeit für Verbindungen

  HTTP/3 nutzt TLS 1.3 und teilt daher auch seine Leistungsvorteile: Zum Herstellen einer neuen Verbindung ist nur ein einziger Umlauf erforderlich, zum Fortsetzen einer bestehenden Verbindung sind keine Umläufe erforderlich.

HTTP/3 wird die größten Auswirkungen auf Nutzer mit schlechter Netzwerkverbindung haben: nicht nur, weil HTTP/3 Paketverluste besser verarbeitet als seine Vorgänger, sondern auch, weil die absolute Zeitersparnis durch eine 0-RTT- oder 1-RTT-Verbindung in Netzwerken mit hoher Latenz größer ist.

Bildoptimierung

CDN-Bildoptimierungsdienste konzentrieren sich in der Regel auf Bildoptimierungen, die automatisch angewendet werden können, um die Größe der Bildübertragung zu reduzieren. Beispiele: EXIF-Daten entfernen, verlustfreie Komprimierung anwenden und Bilder in neuere Dateiformate konvertieren (z. B. WebP) Bilder machen etwa 50% der Übertragungsbyte auf der durchschnittlichen Webseite aus. Durch die Optimierung von Bildern kann die Seitengröße also erheblich reduziert werden.

Reduzierung

Durch die Reduzierung werden unnötige Zeichen aus JavaScript, CSS und HTML entfernt. Wir empfehlen, die Minifizierung auf dem Ursprungsserver und nicht im CDN durchzuführen. Websiteinhaber haben mehr Kontext zu dem Code, der reduziert werden soll, und verwenden daher oft aggressivere Verfahren zur Komprimierung als bei CDNs. Wenn die Komprimierung des Codes am Ursprung jedoch keine Option ist, ist die Reduzierung durch das CDN eine gute Alternative.

Fazit

• CDN verwenden: CDNs stellen Ressourcen schnell bereit, reduzieren die Last auf dem Ursprungsserver und sind hilfreich beim Umgang mit Trafficspitzen.
• Inhalte so aggressiv wie möglich im Cache speichern:Statische und dynamische Inhalte können und sollten im Cache gespeichert werden, allerdings unterschiedlich lang. Überprüfen Sie Ihre Website regelmäßig, um sicherzustellen, dass Inhalte optimal im Cache gespeichert werden.
• CDN-Leistungsfeatures aktivieren:Funktionen wie Brotli, TLS 1.3, HTTP/2 und HTTP/3 verbessern die Leistung.