Was ist HTTP/2? Testen Sie Ihre Website

Das Hypertext Transfer Protocol (HTTP) ist ein Satz von Standards, über den Menschen im Internet die Informationen einer Website austauschen. Seit seiner Einführung 1991 sind vier HTTP-Versionen entstanden.

HTTP/2 kam 2015 als große Überarbeitung des Protokolls HTTP/1.1 heraus und brachte deutliche Fortschritte beim Tempo. Es ging aus SPDY hervor, entwickelt vor allem für Seiten mit vielen Ressourcen: Es sollte die Ladegeschwindigkeit heben und die Umlaufzeit (RTT) senken.

Dieser Beitrag zeigt, warum das neue Protokoll nötig wurde, wie es sich von SPDY zu HTTP/2 entwickelt hat, worin es sich von HTTP/1.1 unterscheidet und wie ein CDN (Content Delivery Network) dabei hilft, Ihre Inhalte HTTP/2-tauglich zu machen. Sie können außerdem gleich hier testen, ob Ihre eigene Website HTTP/2 unterstützt.

HTTP/2 Test

HTTP/2 Testwerkzeug

Websites, die über HTTP/2 laufen, stehen bei der SEO besser da, weil Tempo und Sicherheit für sie sprechen.

Von SPDY zu HTTP/2

HTTP/1.1 war die dritte HTTP-Version und über 15 Jahre lang der Standard. Es hob die Leistung durch dauerhafte Verbindungen und schuf die Grundlage für die Standardanfragen GET, HEAD, PUT und POST.

Je größer die Websites wurden und je mehr Ressourcen sie zogen, desto deutlicher traten die Grenzen von HTTP/1.1 hervor. Vor allem eines wog schwer: Pro TCP-Verbindung war nur eine offene Anfrage möglich, und dieser Zusatzaufwand bremste in 1.1 die Ladezeiten spürbar.

2010 stellte Google das Protokoll SPDY vor, um zu ändern, wie HTTP Anfragen und Antworten abwickelt. SPDY zielte auf weniger Verzögerung durch TCP-Pipelining und brachte Eigenschaften wie eine verpflichtende Komprimierung mit.

HTTP/2 baute anfangs auf SPDY auf, wurde aber rasch umgebaut, um eigene Eigenschaften aufzunehmen, etwa einen festen Algorithmus zur Komprimierung der Header. Danach kündigte Google an, SPDY fallen zu lassen und HTTP/2 zu unterstützen.

Die Unterschiede zwischen HTTP/1.1 und HTTP/2

Eigenschaft	HTTP/1.1	HTTP/2
Multiplexing	Nein – jede Anfrage braucht eine eigene TCP-Verbindung	Ja – mehrere Anfragen und Antworten gleichzeitig über eine einzige TCP-Verbindung
Header-Komprimierung	Nein – Header gehen als Klartext über die Leitung	HPACK verkleinert die Header um bis zu 80 %
Datenübertragung	Der Reihe nach und blockierend	Parallel und non-blocking
Server Push	Nein	Ja – der Server kann Ressourcen schicken, bevor der Client sie anfordert
Head-of-Line Blocking	Ja – eine neue Anfrage wartet, bis die vorige fertig ist	Nein – die Streams laufen unabhängig voneinander
Binäres Protokoll	ASCII-Format	Binärformat – effizienteres Parsing
Priorität der Streams	Nein	Ja – Sie können festlegen, was Vorrang hat
Sicherheit	TLS freiwillig	TLS als empfohlener Standard
Verbindungsverwaltung	Über Connection: keep-alive	Dauerhafte Verbindung als Voreinstellung
Leistung	Grundniveau	50 bis 70 % schnelleres Laden der Seite

Die Umstellung auf HTTP/2 und die Rolle des CDN

Als Google die Unterstützung für SPDY beendete, wurde der Wechsel zu HTTP/2 für Websites zur Pflicht, die ihre RTT senken und ihre Seiten schneller ausliefern wollten.

Der Wechsel zu HTTP/2 kann allerdings ein paar heikle Schritte enthalten:

1. HTTPS-Tauglichkeit: Die neue Erweiterung von TLS setzt voraus, dass eine Website zuerst HTTPS-tauglich gemacht wird.
2. Server-Upgrades: Alle Server müssen von HTTP/1.1 auf HTTP/2 gehoben werden. Das ist aufwendig und fehleranfällig.
3. Fehlerbereinigung: Fehler aus HTTP/1.1 können beim Wechsel auf HTTP/2 Ärger machen. Entwickler müssen dann neue Lösungen finden.

Hier machen CDNs die Sache leichter, weil sie sich als Vermittler zwischen Nutzer und Server stellen. Imperva CDN etwa macht Ihre Server automatisch HTTP/2-tauglich, ohne dass Sie von Hand etwas hochrüsten müssen.

Wenn Sie nur eine deutschsprachige Website mit Besuchern aus Deutschland haben, kann ein CDN eher bremsen als beschleunigen. Messen Sie die Wirkung deshalb vorher und nachher.

Ein Rechenbeispiel

Die Frage: Wie lange braucht der Server, um 100 Dateien mit 10 MB Gesamtgewicht an den Client zu übertragen? Bei den Zahlen dieses Beispiels hat uns ChatGPT geholfen.

Laden über HTTP/1.1

1. Eine eigene Anfrage pro Datei: Bei HTTP/1.1 kommt jede Datei über eine eigene TCP-Verbindung. Browser öffnen dafür meist 6 Verbindungen parallel.
   • Für 100 Dateien werden also laufend Verbindungen auf- und wieder abgebaut.
   • Der Aufbau der Verbindung (der TCP-Handschlag) und die Verzögerung (RTT) treiben die Ladezeit nach oben, je mehr Dateien es sind.
2. Langsamer Start: Jede TCP-Verbindung nutzt anfangs nur einen Teil der Bandbreite und wird erst mit der Zeit schneller. Auch das zieht die Ladezeit in die Länge.
3. Zusatzlast durch Header: Für jede Datei gehen eigene HTTP-Header über die Leitung, das vergrößert die Gesamtmenge an Daten.

Geschätzte Dauer

• Verzögerung (RTT): ~50 ms (als Beispielwert angenommen).
• Gesamter Verbindungsaufbau: 100 Dateien ÷ 6 parallele Verbindungen ≈ 17 Runden.
• Nur der Aufbau der Verbindungen: 17 x 50 ms = 850 ms.
• Eigentliche Übertragung plus Zusatzlast: 10 MB Daten und Header ≈ 1,2 bis 1,5 Sekunden.
• Gesamtdauer: ~2 bis 2,5 Sekunden.

Laden über HTTP/2

Eine einzige Verbindung: HTTP/2 überträgt alle Dateien über eine einzige TCP-Verbindung. Der Zusatzaufwand für den Verbindungsaufbau fällt damit weg.

1. Multiplexing: Über dieselbe Verbindung laufen die Dateien parallel. Sie werden also gleichzeitig geladen.
2. Komprimierung der Header: HTTP/2 verkleinert die HTTP-Header mit HPACK.
3. Weniger Verzögerung: Die RTT-Verzögerungen fallen dank der parallelen Streams kaum noch ins Gewicht.

Geschätzte Dauer

• Verbindungsaufbau: RTT für eine einzige Verbindung = 50 ms.
• Eigentliche Übertragung: 10 MB Daten ≈ 1 Sekunde (bei 100 Mbit/s).
• Gesamtdauer: ~1 bis 1,1 Sekunden.

Fazit

Nach allem, was wir hier durchgegangen sind, hat HTTP/2 bei Tempo und Sicherheit sehr viel für sich. Auch für die Suchmaschinenoptimierung ist HTTP/2 deshalb die richtige Wahl.