HTTP/2 vs. HTTP/1.1: Wie wirken sie sich auf die Web-Performance aus?

Mit HTTP/2 können Entwickler die Priorisierung oder die Reihenfolge anpassen, in der Webressourcen geladen werden. HTTP/2 bietet eine Reihe weiterer Performance-Verbesserungen gegenüber HTTP/1.

Share facebook icon linkedin icon twitter icon email icon

HTTP/2 & HTTP/1.1

Lernziele

Nach Lektüre dieses Artikels können Sie Folgendes:

  • Was ist HTTP und wie unterscheiden sich HTTP-Versionen untereinander?
  • Wie funktioniert Priorisierung im HTTP/2?
  • Wie HTTP/2 die Web-Performance verbessern kann?

Was ist HTTP? Warum ist HTTP/2 schneller als HTTP/1.1?

HTTP steht für Hypertext Transfer Protocol und ist die Basis für fast alle Webanwendungen. Genauer gesagt, ist HTTP die Methode, mit der Computer und Server Informationen anfordern und senden. Wenn beispielsweise jemand auf seinem Laptop zu cloudflare.com geht, sendet sein Webbrowser eine HTTP-Anfrage an die Cloudflare-Server für den Inhalt, der auf der Seite angezeigt wird. Anschließend senden Cloudflare-Server HTTP-Antworten mit dem Text, den Bildern und der Formatierung, die der Browser dem Benutzer anzeigt.

Die erste verwendbare Version von HTTP wurde 1997 erstellt. Da sie mehrere Entwicklungsstufen durchlief, wurde diese erste Version von HTTP als HTTP/1.1 bezeichnet. Diese Version wird immer noch im Web verwendet. Im Jahr 2015 wurde eine neue Version von HTTP mit dem Namen HTTP/2 erstellt.

HTTP/2 löst mehrere Probleme, die die Entwickler von HTTP/1.1 nicht vorausgesehen haben. Insbesondere ist HTTP/2 viel schneller und effizienter als HTTP/1.1. HTTP/2 ist unter anderem schneller, wenn es darum geht, Inhalte während des Ladevorgangs zu priorisieren.

Was ist Priorisierung?

Im Kontext von Web-Performance bezieht sich die Priorisierung auf die Reihenfolge, in der Inhalte geladen werden. Angenommen, ein Benutzer besucht eine Nachrichtenwebsite und navigiert zu einem Artikel. Sollte das Foto im oberen Teil des Artikel zuerst geladen werden? Sollte der Text des Artikels zuerst geladen werden? Sollte die Bannerwerbung zuerst geladen werden?

Priorisierung wirkt sich auf die Ladezeit einer Webseite aus. Beispielsweise können bestimmte Ressourcen wie große JavaScript-Dateien das Laden der restlichen Seite blockieren, wenn sie zuerst geladen werden müssen. Ein größerer Teil der Seite kann sofort geladen werden, wenn diese Render-Blocking Resources als letztes geladen werden.

Darüber hinaus wirkt sich die Reihenfolge, in der diese Seitenressourcen geladen werden, darauf aus, wie der Benutzer die Seitenladedauer wahrnimmt. Wenn nur Inhalte hinter den Kulissen (wie eine CSS-Datei) oder Inhalte, die der Benutzer nicht sofort sehen kann (wie Banneranzeigen am Ende der Seite), zuerst geladen werden, wird der Benutzer denken, dass die Seite überhaupt nicht lädt. Werden aber die für den Benutzer wichtigste Inhalte zuerst geladen, z. B. das Bild im oberen Teil der Seite, wird der Benutzer die Seite als schneller wahrnehmen.

Wie wirkt sich die Priorisierung in HTTP/2 auf die Performance aus?

In HTTP/2 haben Entwickler eine praktische und detaillierte Kontrolle über die Priorisierung. Auf diese Weise können sie die wahrgenommene und tatsächliche Geschwindigkeit beim Laden von Seiten auf ein Maß maximieren, das in HTTP/1.1 nicht möglich war.

HTTP/2 bietet eine Funktion namens gewichtete Priorisierung. Auf diese Weise können Entwickler jedes Mal entscheiden, welche Seitenressourcen zuerst geladen werden. Wenn ein Client in HTTP/2 eine Anfrage für eine Webseite stellt, sendet der Server mehrere Datenströme gleichzeitig an den Client, anstatt eine Sache nach der anderen zu senden. Diese Methode der Datenübertragung wird als Multiplexing bezeichnet. Entwickler können jedem dieser Datenströme einen anderen gewichteten Wert zuweisen, und der Wert sagt dem Client, welcher Datenstrom zuerst gerendert werden soll.

Stellen Sie sich vor, Alice möchte einen Roman lesen, den ihr Freund Bob geschrieben hat, aber sowohl Alice als auch Bob kommunizieren nur über die gewöhnliche Post. Alice schickt einen Brief an Bob und bittet Bob, ihr seinen Roman zu schicken. Bob beschließt, den Roman im HTTP/1.1-Stil zu senden: Er verschickt jeweils ein Kapitel pro Brief und sendet das nächste Kapitel erst, nachdem Alice in einem Antwortbrief den Erhalt des vorherigen Kapitels bestätigt hat. Mit dieser Methode der Inhaltsbereitstellung braucht Alice viele Wochen, um Bobs Roman zu lesen.

Stellen Sie sich nun vor, Bob beschließt, Alice seinen Roman im HTTP/2-Stil zu senden: In diesem Fall sendet er zwar jedes Kapitel des Romans in einem separaten Brief (um innerhalb der Größenbeschränkungen des Postdienstes zu bleiben), jedoch verschickt er alle Kapitel gleichzeitig. Er nummeriert auch jedes Kapitel: Kapitel 1, Kapitel 2 usw. Jetzt erhält Alice den Roman auf einmal und kann ihn in ihrer eigenen Zeit in der richtigen Reihenfolge zusammenstellen. Wenn ein Kapitel fehlt, sendet sie möglicherweise eine kurze Antwort und bittet um dieses bestimmte Kapitel. Andernfalls ist der Vorgang abgeschlossen und Alice kann den Roman in nur wenigen Tagen durchlesen.

In HTTP/2 werden Daten auf einmal gesendet, ähnlich wie Bob, wenn er Alice mehrere Kapitel gleichzeitig schickt. Und genau wie Bob können Entwickler die Kapitel in HTTP/2 nummerieren. Sie können entscheiden, ob der Text einer Webseite zuerst geladen wird – oder die CSS-Dateien oder das JavaScript oder was auch immer ihrer Meinung nach für die Benutzererfahrung am wichtigsten ist.

Was sind die anderen Unterschiede zwischen HTTP/2 und HTTP/1.1, die sich auf die Performance auswirken?

Multiplexing: HTTP/1.1 lädt Ressourcen nacheinander. Wenn also eine Ressource nicht geladen werden kann, werden alle anderen dahinter liegenden Ressourcen blockiert. Im Gegensatz dazu kann HTTP/2 eine einzelne TCP-Verbindung verwenden, um mehrere Datenströme gleichzeitig zu senden, sodass keine Ressource eine andere Ressource blockiert. HTTP/2 teilt dazu Daten in Binärcode-Nachrichten auf und nummeriert diese Nachrichten, damit der Client weiß, zu welchem Stream jede Binärnachricht gehört.

Server-Push: In der Regel stellt ein Server einem Client-Gerät nur dann Inhalte zur Verfügung, wenn der Client diese anfordert. Dieser Ansatz ist jedoch für moderne Webseiten, die häufig mehrere Dutzend separate Ressourcen umfassen, die der Client anfordern muss, nicht immer praktikabel. HTTP/2 löst dieses Problem, indem es einem Server ermöglicht, Inhalte an einen Client zu „pushen“, bevor der Client danach fragt. Der Server sendet auch eine Nachricht, in der der Client darüber informiert wird, welche Inhalte zu erwarten sind – beispielsweise, wenn Bob Alice zuerst ein Inhaltsverzeichnis seines Romans schickt.

die

Header-Komprimierung: Kleine Dateien werden schneller geladen als große. Um die Webleistung zu beschleunigen, komprimieren sowohl HTTP/1.1 als auch HTTP/2 HTTP-Nachrichten, um sie zu verkleinern. HTTP/2 verwendet jedoch eine erweiterte Komprimierungsmethode namens HPACK. HPACK eliminiert redundante Informationen in HTTP-Header-Paketen. Dadurch werden einige Bytes aus jedem HTTP-Paket entfernt. Angesichts der Menge an HTTP-Paketen, die beim Laden einer einzelnen Webseite beteiligt sind, summieren sich diese Bytes schnell, was zu schnelleren Ladezeiten führt.

Was ist HTTP/3?

HTTP/3 ist die als nächstes geplante Version des HTTP-Protokolls. HTTP/3 findet im Web noch keine breite Akzeptanz, wird jedoch immer häufiger verwendet. Der Hauptunterschied zwischen HTTP/3 und früheren Versionen des Protokolls besteht darin, dass HTTP/3 über QUIC anstelle von TCP ausgeführt wird. QUIC ist ein schnelleres und sichereres Transport-Layer-Protokoll, das entwickelt wurde, um die Anforderungen des modernen Internets zu erfüllen.

Wie hilft Cloudflare Entwicklern bei der Implementierung von HTTP/2 für eine schnellere Performance?

Cloudflare unterstützt alle Features von HTTP/2. Websites auf Cloudflare können HTTP/2 kostenlos mit nur einem Klick aktivieren. Cloudflare unterstützt neben HTTP/2 auch HTTP/3.