Bessere HTTP/2-Priorisierung für ein schnelleres Web

HTTP/2 versprach ein viel schnelleres Web und Cloudflare hat vor langer, langer Zeit den HTTP/2-Zugang für alle unsere Kunden eingeführt. Aber ein Merkmal von HTTP/2, die Priorisierung, konnte die Erwartungen nicht erfüllen. Nicht, weil es damit grundsätzliche Probleme gab, sondern wegen der Art und Weise, wie Browser sie implementierten.

Heute führt Cloudflare eine Änderung der HTTP/2-Priorisierung ein, die unseren Servern die Kontrolle über Priorisierungsentscheidungen gibt, die das Web wirklich viel schneller machen.

In der Vergangenheit hatte der Browser die Kontrolle darüber, wie und wann Webinhalte geladen werden. Heute führen wir für alle kostenpflichtigen Tarife eine radikale Änderung dieses Modells ein, durch die die Kontrolle direkt in die Hände des Besitzers der Website gelegt wird. Kunden können die „Enhanced HTTP/2 Prioritization“ (Verbesserte HTTP/2-Priorisierung) auf der Registerkarte „Speed“ im Cloudflare Dashboard aktivieren. Dadurch werden die Standardeinstellungen des Browsers mit einem verbesserten Ablaufschema überschrieben, das zu einer deutlich schnelleren Besuchererfahrung führt (wir haben mehrfach eine Beschleunigung um 50 % festgestellt). Mit Cloudflare Workers können die Besitzer von Webseiten noch einen Schritt weiter gehen und die Erfahrung vollständig an ihre konkreten Bedürfnisse anpassen.

Webseiten bestehen aus Dutzenden (manchmal Hunderten) von separaten Ressourcen, die vom Browser geladen und zum endgültigen angezeigten Inhalt zusammengefügt werden. Dazu gehören der sichtbare Inhalt, mit dem der Benutzer interagiert (HTML, CSS, Bilder), sowie die Anwendungslogik (JavaScript) für die Webseite selbst, Anzeigen, Analysen zur Nachverfolgung der Nutzung der Website und Marketing-Tracking-Beacons. Die Reihenfolge, wie diese Ressourcen geladen werden, kann einen wesentlichen Einfluss darauf haben, wie lange es dauert, bis der Benutzer den Inhalt sieht und mit der Seite interagieren kann.

Ein Browser ist im Grunde ein HTML-Verarbeitungseinheit, die das HTML-Dokument durchgeht, den Anweisungen des HTML-Codes vom Anfang bis zum Ende folgt und dabei die Seite aufbaut. Verweise auf Stylesheets (CSS) zeigen dem Browser an, wie der Seiteninhalt formatiert werden soll, und der Browser verzögert die Anzeige von Inhalten, bis er das Stylesheet geladen hat (damit weiß er, wie der anzuzeigende Inhalt zu formatieren ist). Skripte, auf die im Dokument verwiesen wird, können mehrere unterschiedliche Verhaltensweisen aufweisen. Wenn das Skript als „async“ oder „defer“ markiert ist, kann der Browser das Dokument weiter verarbeiten und den Skriptcode einfach ausführen, wenn die Skripte verfügbar sind. Wenn die Skripte nicht als „async“ oder „defer“ markiert sind, MUSS der Browser die Verarbeitung des Dokuments stoppen, bis das Skript heruntergeladen und ausgeführt wurde, bevor er fortfährt. Diese werden als „blockierende“ Skripte bezeichnet, da sie den Browser daran hindern, das Dokument weiter zu verarbeiten, bis sie geladen und ausgeführt wurden.

Das HTML-Dokument ist in zwei Teile unterteilt. Der Kopf des Dokuments () befindet sich am Anfang und enthält Stylesheets, Skripte und andere Anweisungen für den Browser, die zum Anzeigen des Inhalts benötigt werden. Der Körper des Dokuments () folgt auf den Kopf und enthält den eigentlichen Seiteninhalt, der im Browserfenster angezeigt wird (obwohl Skripte und Stylesheets auch im Textkörper enthalten sein dürfen). Bis der Browser zum Textkörper des Dokuments gelangt, kann er dem Benutzer nichts anzeigen und die Seite bleibt leer, weshalb es wichtig ist, den Kopf des Dokuments so schnell wie möglich durchzuarbeiten. „HTML5 rocks“ hat ein großartiges Tutorial zur Funktionsweise von Browsern, falls Sie tiefer in die Materie eintauchen wollen.

Der Browser bestimmt in der Regel selbst die Reihenfolge des Ladens der verschiedenen Ressourcen, die er zum Aufbau der Seite und zur weiteren Verarbeitung des Dokuments benötigt. Im Fall von HTTP/1.x ist der Browser bezüglich der Anzahl der Dinge, die er von einem Server gleichzeitig anfordern kann, eingeschränkt (in der Regel 6 Verbindungen und je Verbindung nur eine Ressource auf einmal), sodass die Reihenfolge strikt durch die Anforderungen des Browsers geregelt wird. Mit HTTP/2 ändert sich das signifikant. Der Browser kann alle Ressourcen auf einmal anfordern (zumindest sobald er Kenntnis von ihnen hat) und gibt dem Server detaillierte Anweisungen, wie die Ressourcen bereitzustellen sind.

Für die meisten Teile des Seitenladezyklus gibt es eine optimale Reihenfolge der Ressourcen, die zum schnellsten Benutzererlebnis führt (und der Unterschied zwischen optimal und nicht optimal kann signifikant sein – bis hin zu einer Verbesserung um 50 % oder mehr).

Wie oben beschrieben, wird der Browser zu Beginn des Seitenladezyklus – bevor er Inhalte rendern kann – durch die im HTML- enthaltenen CSS und JavaScript blockiert. Während dieses Teils des Ladezyklus ist es am besten, wenn 100 % der Bandbreite der Verbindung zum Herunterladen der blockierenden Ressourcen verwendet werden und diese nacheinander in der Reihenfolge heruntergeladen werden, in der sie im HTML festgelegt sind. Dadurch kann der Browser jedes Element analysieren und ausführen, während er die nächste blockierende Ressource herunterlädt, sodass als Pipeline Download und Ausführung aufeinander folgen.

Das Herunterladen der Skripte nimmt die gleiche Zeit in Anspruch, egal ob sie parallel oder nacheinander heruntergeladen werden. Aber durch das sequenzielle Herunterladen kann das erste Skript verarbeitet und ausgeführt werden, während das zweite Skript heruntergeladen wird.

Sobald die Inhalte, die das Rendern blockieren, geladen sind, werden die Dinge etwas interessanter und das optimale Laden kann von der spezifischen Webseite oder sogar den Unternehmensprioritäten abhängen (Benutzerinhalte oder Werbung oder Analysen usw.). Insbesondere Schriftarten können schwierig sein, da der Browser erst dann entdeckt, welche Schriften er benötigt, wenn die Stylesheets auf den Inhalt angewendet wurden, der angezeigt werden soll. Wenn der Browser also von einer Schriftart erfährt, benötigt er sie schon, um Text anzuzeigen, der bereit ist, auf dem Bildschirm zu erscheinen. Verzögerungen beim Laden der Schriftart führen zu fehlendem Text auf dem Bildschirm (oder Text, der in der falschen Schriftart angezeigt wird).

Im Allgemeinen gibt es einige Umstände, die berücksichtigt werden müssen:

• Benutzerdefinierte Schriftarten und sichtbare Bilder auf dem sichtbaren Teil der Seite (Ansichtsfenster) sollten so schnell wie möglich geladen werden. Sie wirken sich direkt auf das visuelle Erlebnis des Benutzers beim Laden der Seite aus.

• Nicht blockierende JavaScript-Ressourcen sollten im Vergleich zu anderen JavaScript-Ressourcen nacheinander heruntergeladen werden, damit die Ausführung jeweils auf den Download folgen kann. JavaScript kann sowohl benutzerorientierte Anwendungslogik als auch Beacons zur Analyseverfolgung und für das Marketing enthalten. Deren Verzögerung könnte zu einem Rückgang der Messgrößen führen, die das Unternehmen verfolgt.

• Bilder profitieren vom parallelen Download. Die ersten Byte einer Bilddatei enthalten die Bildabmessungen, die für das Browser-Layout erforderlich sein können. Progressive Bilder, die parallel heruntergeladen werden, können schon bei 50 % der übertragenen Byte visuell vollständig erscheinen.

Unter Abwägung dieser Umstände sieht eine Strategie, die in den meisten Fällen gut funktionierend, folgendermaßen aus:

• Benutzerdefinierte Schriftarten werden sequenziell heruntergeladen und teilen sich die verfügbare Bandbreite mit sichtbaren Bildern.

• Sichtbare Bilder werden parallel heruntergeladen, wobei der „Bilder“-Anteil an der Bandbreite unter ihnen aufgeteilt wird.

• Wenn keine Schriftarten oder sichtbaren Bilder mehr anstehen:

• Nicht blockierende Skripte werden sequenziell heruntergeladen und teilen sich die verfügbare Bandbreite mit nicht sichtbaren Bildern.

• Nicht sichtbare Bilder werden parallel heruntergeladen, wobei der „Bilder“-Anteil an der Bandbreite unter ihnen aufgeteilt wird.

Auf diese Weise werden die für den Benutzer sichtbaren Inhalte so schnell wie möglich geladen, die Anwendungslogik wird so wenig wie möglich verzögert und die nicht sichtbaren Bilder werden so geladen, dass das Layout so schnell wie möglich fertiggestellt werden kann.

Zur Veranschaulichung verwenden wir eine vereinfachte Produktkategorie-Seite von einer typischen E-Commerce-Website. In diesem Beispiel hat die Seite:

• Die HTML-Datei für die Seite selbst, dargestellt durch ein blaues Feld.

• 1 externes Stylesheet (CSS-Datei), dargestellt durch ein grünes Feld.

• 4 externe Skripte (JavaScript), dargestellt durch orangefarbene Felder. Zwei der Skripte blockieren zu Beginn der Seite und zwei sind asynchron. Die blockierenden Skript-Felder erscheinen in einem dunkleren Orangeton.

• 1 benutzerdefinierte Webschriftart, dargestellt durch ein rotes Feld.

• 13 Bilder, dargestellt durch violette Felder. Das Logo der Seite und vier Produktbilder sind im Ansichtsfenster sichtbar, für acht Produktbilder muss gescrollt werden. Die fünf sichtbaren Bilder erscheinen in einem dunkleren Violettton.

Der Einfachheit halber gehen wir davon aus, dass alle Ressourcen die gleiche Größe haben und ihr Herunterladen über die Verbindung des Besuchers jeweils eine Sekunde dauert. Das Laden aller Bestandteile dauert insgesamt 20 Sekunden, aber WIE sie geladen werden, kann einen großen Einfluss auf das Erlebnis haben.

So würde der beschriebene optimale Ladevorgang im Browser aussehen, während die Ressourcen geladen werden:

• Die Seite ist die ersten vier Sekunden lang leer, während HTML, CSS und blockierende Skripte geladen werden, die zusammen 100 % der Verbindung nutzen.

• Bei der 4-Sekunden-Marke werden Hintergrund und Struktur der Seite ohne Text oder Bilder angezeigt.

• Eine Sekunde später, nach fünf Sekunden, wird der Text der Seite angezeigt.

• Von 5–10 Sekunden werden die Bilder geladen, zuerst verschwommen, dann sehr schnell schärfer werdend. Um die 7-Sekunden-Marke ist die Seite fast nicht mehr von der endgültigen Version zu unterscheiden.

• Bei der 10-Sekunden-Marke ist der gesamte visuelle Inhalt im Ansichtsfenster geladen.

• In den nächsten zwei Sekunden wird das asynchrone JavaScript geladen und ausgeführt (nicht kritische Logik: Analysen, Marketing-Tags usw.).

• In den letzten acht Sekunden werden die restlichen Produktbilder geladen, damit sie bereit sind, wenn der Benutzer scrollt.

Alle aktuellen Browser-Engines implementieren unterschiedliche Priorisierungsstrategien, von denen keine optimal ist.

Microsoft Edge und Internet Explorer unterstützen keine Priorisierung, sodass der HTTP/2-Standard angewandt wird, der darin besteht, alles parallel zu laden und die Bandbreite gleichmäßig zwischen allem aufzuteilen. Microsoft Edge wird in zukünftigen Windows-Versionen die Browser-Engine Chromium verwenden, was zur Verbesserung der Situation beitragen wird. Für unserer Beispielseite bedeutet das, dass der Browser den Großteil der Ladezeit für den Kopf aufwendet, da die Bilder die Übertragung der blockierenden Skripte und Stylesheets verlangsamen.

Optisch führt dies zu der ziemlich schmerzhaften Erfahrung, 19 Sekunden lang auf einen leeren Bildschirm zu starren, bevor die meisten Inhalte angezeigt werden, gefolgt von der Anzeige des Textes nach einer weiteren Verzögerung von einer Sekunde. Seien Sie geduldig, wenn Sie den animierten Fortschritt beobachten, denn während der 19 Sekunden mit leerem Bildschirm kann es sich anfühlen, als würde nichts passieren (auch wenn doch etwas passiert):

Safari lädt alle Ressourcen parallel und teilt die Bandbreite zwischen ihnen auf, je nachdem für wie wichtig Safari sie hält (wobei Ressourcen wie Skripte und Stylesheets, die das Rendern blockieren, wichtiger sind als Bilder). Bilder werden parallel, aber auch zeitgleich mit das Rendern blockierenden Inhalten geladen.

Obwohl ähnlich wie bei Edge alles gleichzeitig geladen wird, kann Safari den Inhalt viel früher anzeigen, weil den Ressourcen, die das Rendern blockieren, mehr Bandbreite zugewiesen wird:

• Nach etwa acht Sekunden sind das Stylesheet und die Skripte geladen, sodass die Seite angezeigt werden kann. Da die Bilder parallel geladen wurden, können sie in ihrem Teilzustand gerendert werden (verschwommen für progressive Bilder). Das ist immer noch doppelt so langsam wie der Optimalfall, aber viel besser als das, was wir mit Edge gesehen haben.

• Nach etwa elf Sekunden ist die Schriftart geladen, sodass der Text angezeigt werden kann, und es wurden mehr Bilddaten heruntergeladen, wodurch die Bilder etwas schärfer sind. Dies ist vergleichbar mit dem Erlebnis bei der 7-Sekunden-Marke im Fall optimalen Ladens.

• In den restlichen neun Sekunden des Ladens werden die Bilder schärfer, da immer mehr Daten für sie heruntergeladen werden, bis sie schließlich nach 20 Sekunden fertig sind.

Firefox erstellt eine Abhängigkeitsstruktur, die Ressourcen gruppiert und dann vorsieht, dass die Gruppen entweder nacheinander geladen werden oder die Bandbreite zwischen Gruppen aufgeteilt wird. Innerhalb einer bestimmten Gruppe teilen sich die Ressourcen die Bandbreite und werden gleichzeitig heruntergeladen. Die Bilder sollen nach den Stylesheets, die das Rendern blockieren, und parallel geladen werden, aber das Rendern blockierende Skripte und Stylesheets werden ebenfalls parallel geladen und bekommen nicht die Pipeline-Vorteile.

In unserem Beispielfall ist das am Ende ein etwas schnelleres Erlebnis als mit Safari, da die Bilder bis zum Abschluss der Stylesheets verzögert werden:

• Bei der 6-Sekunden-Marke wird der anfängliche Seiteninhalt mit Hintergrund und verschwommenen Versionen der Produktbilder gerendert (im Vergleich zu acht Sekunden mit Safari und vier Sekunden im optimalen Fall).

• Nach acht Sekunden ist die Schriftart geladen und der Text kann zusammen mit etwas schärferen Versionen der Produktbilder angezeigt werden (im Vergleich zu elf Sekunden mit Safari und sieben Sekunden im optimalen Fall).

• In den restlichen zwölf Sekunden des Ladens werden die Produktbilder schärfer, während der verbleibende Inhalt geladen wird.

Chrome priorisiert (wie alle Chromium-basierten Browser) Ressourcen in einer Liste. Das funktioniert wirklich gut bei den das Rendern blockierenden Inhalten, die vom Laden profitieren, aber weniger gut für Bilder. Jedes Bild wird zu 100 % vollständig geladen, bevor das nächste Bild startet.

In der Praxis ist dies fast so gut wie der optimale Fall des Ladens, mit dem einzigen Unterschied, dass die Bilder nacheinander statt parallel geladen werden:

• Bis zur 5-Sekunden-Marke ist das Chrome-Erlebnis identisch mit dem optimalen Fall, in dem der Hintergrund bei vier Sekunden und den Textinhalt bei fünf Sekunden angezeigt werden.

• In den nächsten 5 Sekunden werden die sichtbaren Bilder nacheinander geladen, bis sie bei der 10-Sekunden-Marke alle fertig sind (im Vergleich zum optimalen Fall, in dem sie nach sieben Sekunden nur leicht verschwommen sind und in den verbleibenden drei Sekunden scharf werden).

• Nachdem der sichtbare Teil der Seite nach zehn Sekunden abgeschlossen ist (identisch mit dem optimalen Fall), werden in den verbleibenden zehn Sekunden die asynchronen Skripte ausgeführt und die ausgeblendeten Bilder geladen (wie beim optimalen Ladefall).

Optisch kann der Unterschied ziemlich drastisch sein, auch wenn eigentlich alle die gleiche Zeit benötigen, um den gesamten Inhalt zu laden:

Die HTTP/2-Priorisierung wird vom Client (Browser) angefordert und es obliegt dem Server, auf Basis der Anforderung zu entscheiden, was zu tun ist. Eine große Anzahl von Servern unterstützt keinerlei Priorisierung, aber diejenigen, die es tun, richten sich nach der Anforderung des Clients. Eine andere Möglichkeit wäre, unter Berücksichtigung der Anforderung des Clients auf Serverseite eine Entscheidung über die beste Priorisierung zu treffen.

Gemäß der Spezifikation ist die HTTP/2-Priorisierung eine Abhängigkeitsstruktur, die die vollständige Kenntnis aller laufenden Anforderungen erfordert, um die Ressourcen priorisieren zu können. Das ermöglicht unglaublich komplexe Strategien, ist aber auf Browser- oder Serverseite nur schwer zu implementieren (wie die verschiedenen Browser-Strategien und das unterschiedliche Ausmaß der Unterstützung durch die Server belegen). Um die Priorisierung einfacher zu handhaben, haben wir ein einfacheres Priorisierungsschema entwickelt, das dennoch die nötige Flexibilität für eine optimale Planung bietet.

Das Priorisierungsschema von Cloudflare besteht aus 64 „Prioritätsstufen“ und innerhalb jeder Prioritätsstufe gibt es Gruppen von Ressourcen, die bestimmen, wie die Verbindung zwischen ihnen aufgeteilt wird:

Alle Ressourcen einer höheren Prioritätsstufe werden übertragen, bevor zur nächst niedrigeren Prioritätsstufe übergegangen wird.

Innerhalb einer gegebenen Prioritätsstufe gibt es drei verschiedene „Gleichzeitigkeitsgruppen“ (concurrency groups):

• 0 : Alle Ressourcen der Gleichzeitigkeitsgruppe „0“ werden in der angeforderten Reihenfolge nacheinander gesendet und nutzen dabei 100 % der Bandbreite. Erst nachdem alle Ressourcen der Gleichzeitigkeitsgruppe „0“ heruntergeladen sind, werden andere Gruppen auf derselben Stufe berücksichtigt.

• 1 : Alle Ressourcen in der Gleichzeitigkeitsgruppe „1“ werden in der angeforderten Reihenfolge nacheinander gesendet. Die verfügbare Bandbreite wird gleichmäßig zwischen der Gleichzeitigkeitsgruppe „1“ und der Gleichzeitigkeitsgruppe „n“ aufgeteilt.

• n : Die Ressourcen in der Gleichzeitigkeitsgruppe „n“ werden parallel gesendet, wobei die der Gruppe zur Verfügung stehende Bandbreite zwischen ihnen aufgeteilt wird.

Aus praktischer Sicht ist die Gleichzeitigkeitsgruppe „0“ für kritische Inhalte nützlich, die sequenziell verarbeitet werden müssen (Skripte, CSS usw.). Die Gleichzeitigkeitsgruppe „1“ ist nützlich für weniger wichtige Inhalte, die Bandbreite mit anderen Ressourcen teilen können, bei denen jedoch die Ressourcen selbst weiterhin von der sequenziellen Verarbeitung profitieren (asynchrone Skripte, nicht-progressive Bilder usw.). Die Gleichzeitigkeitsgruppe „n“ ist nützlich für Ressourcen, die von der parallelen Verarbeitung profitieren (progressive Bilder, Video, Audio usw.).

Wenn die verbesserte Priorisierung aktiviert ist, implementiert sie die oben beschriebene „optimale“ Planung der Ressourcen. Die angewendeten spezifischen Priorisierungen sehen wie folgt aus:

Dieses Priorisierungsschema ermöglicht das serielle Senden von Inhalten, die das Rendern blockieren, gefolgt von den sichtbaren Bildern parallel und dem Rest des Seiteninhalts mit einer gewissen Aufteilung, um das Laden von Anwendung und Inhalt auszugleichen. Der Vorbehalt „* If Detectable“ bedeutet, dass nicht alle Browser zwischen den verschiedenen Arten von Stylesheets und Skripten unterscheiden, aber in jedem Fall dennoch deutlich schneller sein werden. Standardmäßig 50 % schneller ist insbesondere für Edge- und Safari-Besucher nicht ungewöhnlich:

Standardmäßig schneller ist großartig, aber wirklich interessant ist die Möglichkeit, die Priorisierung zu konfigurieren. Diese Möglichkeit steht auf Cloudflare Workers zur Verfügung, sodass Seiten die Standardpriorisierung von Ressourcen überschreiben oder ihre eigenen vollständigen Priorisierungsschemata implementieren können.

Wenn ein Worker der Antwort einen „cf-Priority“-Header hinzufügt, wenden die Edge-Server von Cloudflare die spezifizierte Priorität und Gleichzeitigkeit auf diese Antwort an. Das Format des Headers ist /, also würde für die gegebene Antwort etwas wie response.headers.set ('cf-priority', "30/0"); die Priorität auf 30 mit einer Gleichzeitigkeit von 0 festlegen. In ähnlicher Weise würde „30/1“ die Gleichzeitigkeit auf 1 und „30/n“ die Gleichzeitigkeit auf n setzen.

Mit dieser Flexibilität kann eine Seite die Ressourcenpriorisierung optimieren, um ihren eigenen Anforderungen gerecht zu werden. So kann beispielsweise die Priorität einiger kritischer asynchroner Skripte oder die Priorität von Titelbildern erhöht werden, bevor der Browser erkannt hat, dass diese sich im Ansichtsfenster befinden.

Um die Entscheidung über die Priorisierung zu erleichtern, stellt die Laufzeitumgebung von Workers auch die vom Browser angeforderten Priorisierungsinformationen in dem Anforderungsobjekt bereit, das an den Fetch-Event-Listener des Workers weitergegeben wurde (request.cf.requestPriority). Die eingehende angeforderte Priorität ist eine durch Strichpunkte getrennte Liste von Attributen, die etwa wie folgt aussieht: „weight=192;exclusive=0;group=3;group-weight=127“.

• weight: Die vom Browser angeforderte Gewichtung für die HTTP/2-Priorisierung.

• exclusive: Das vom Browser angeforderte ausschließende HTTP/2-Flag (1 für Chromium-basierte Browser, 0 für andere).

• group: HTTP/2-Stream-ID für die Anforderungsgruppe (nur ungleich Null für Firefox).

• group-weight: HTTP/2-Gewichtung für die Anforderungsgruppe (nur ungleich Null für Firefox).

Die Möglichkeit, die Priorisierung von Antworten zu optimieren und zu steuern, ist der grundlegende Baustein, von dem viele zukünftige Arbeiten profitieren werden. Wir werden darüber hinaus unsere eigenen fortgeschrittenen Optimierungen implementieren, aber durch die Offenlegung in Workers bieten wir Websites und Forschern die Möglichkeit, selbst mit verschiedenen Priorisierungsstrategien zu experimentieren. Mit dem Apps Marketplace ist es Unternehmen auch möglich, neue Optimierungsdienste auf der Workers-Plattform aufzubauen und anderen Websites zur Verfügung zu stellen.

Wenn Sie einen Pro-Tarif oder höher haben, gehen Sie im Cloudflare Dashboard auf die Registerkarte „Speed“ und aktivieren Sie „Enhanced HTTP/2 Prioritization“ (Verbesserte HTTP/2-Priorisierung), um Ihre Seite zu beschleunigen.