Was ist HTTP/2?

HTTP/2 ist die zweite Hauptversion des Hypertext Transfer Protocol, finalisiert als RFC 7540 im Mai 2015. Es war das erste bedeutende Update von HTTP seit der Standardisierung von HTTP/1.1 im Jahr 1997 und adressierte fundamentale Performance-Probleme, die das Web fast zwei Jahrzehnte lang geplagt hatten. Wenn deine WordPress-Seite noch Inhalte über HTTP/1.1 ausliefert, verschenkst du wahrscheinlich erhebliche Performance-Gewinne.

Das Protokoll ging aus Googles experimentellem SPDY-Protokoll hervor, das seit 2012 im Einsatz war und bewiesen hatte, dass die Kernideen hinter HTTP/2 (Multiplexing, Header-Komprimierung, Priorisierung) im Produktivbetrieb gut funktionieren. Als die IETF HTTP/2 standardisierte, wurde SPDY eingestellt, und seine Ideen wurden zum Fundament des neuen Standards.

Wichtige Verbesserungen gegenüber HTTP/1.1

Um zu verstehen, warum HTTP/2 wichtig ist, musst du zuerst verstehen, was an HTTP/1.1 problematisch war. Unter dem alten Protokoll konnte jede TCP-Verbindung nur eine Anfrage gleichzeitig verarbeiten. Wenn dein Browser 40 Ressourcen laden musste (eine typische WordPress-Seite), musste er mehrere Verbindungen öffnen (Browser erlauben typischerweise 6 pro Domain) und die restlichen Anfragen in die Warteschlange stellen. Das erzeugte künstliche Engpässe, die jeden Seitenaufbau verlangsamten.

HTTP/2 behebt dies und mehr:

Multiplexing: Das ist die wichtigste einzelne Verbesserung. HTTP/2 ermöglicht es, mehrere Anfragen und Antworten gleichzeitig über eine einzige TCP-Verbindung zu übertragen. Dein Browser kann deine CSS-Datei, drei JavaScript-Dateien und zehn Bilder alle gleichzeitig über eine Verbindung anfordern. Kein Warten mehr, keine Warteschlange mehr, keine künstlichen Limits mehr. Der Server sendet Antworten zurück, sobald sie verfügbar sind, und der Browser setzt sie zusammen. Allein diese eine Änderung kann die Ladezeiten für ressourcenintensive WordPress-Seiten dramatisch reduzieren.

Header-Komprimierung (HPACK): HTTP-Header werden mit jeder einzelnen Anfrage und Antwort gesendet. In HTTP/1.1 sind diese Header Klartext und oft repetitiv. Dieselben Cookies, User-Agent-Strings und Accept-Header werden immer wieder gesendet. HTTP/2 verwendet einen Komprimierungsalgorithmus namens HPACK, der eine gemeinsame Tabelle häufiger Header-Felder zwischen Client und Server pflegt. Nach der ersten Anfrage müssen nachfolgende Header nur noch die Unterschiede senden. Für eine WordPress-Seite, die 50+ Ressourcen pro Seitenaufruf lädt, kann das Dutzende Kilobytes pro Seitenaufruf einsparen.

Binäres Framing: HTTP/1.1 ist ein textbasiertes Protokoll, was bedeutet, dass der Parser nach Zeilenumbrüchen suchen, verschiedene Text-Kodierungen handhaben und diverse Sonderfälle bewältigen muss. HTTP/2 verwendet eine binäre Framing-Schicht, die alle Kommunikation in wohldefinierte Frames verpackt. Binäre Daten sind schneller zu parsen, weniger fehleranfällig und kompakter. Als Nutzer wirst du das nie bemerken, aber es reduziert den Verarbeitungs-Overhead sowohl auf dem Server als auch auf dem Client.

Stream-Priorisierung: HTTP/2 lässt den Browser dem Server mitteilen, welche Ressourcen wichtiger sind. Zum Beispiel kann der Browser signalisieren, dass die Haupt-CSS-Datei vor Hintergrundbildern geliefert werden soll. Der Server kann dann die Bandbreite entsprechend zuteilen. In der Praxis variieren die Browser-Implementierungen der Priorisierung, und nicht alle Server handhaben es perfekt, aber es bietet trotzdem bedeutsame Verbesserungen für viele Seiten.

Server Push: Diese Funktion erlaubt es dem Server, Ressourcen an den Browser zu senden, bevor der Browser sie überhaupt anfordert. Wenn der Browser eine HTML-Seite anfragt, kann der Server die CSS- und JavaScript-Dateien pushen, von denen er weiß, dass der Browser sie als Nächstes braucht. Das eliminiert die Round-Trip-Verzögerung, bis der Browser entdeckt, dass er eine Ressource braucht und sie dann anfordert. Server Push hat in der Praxis jedoch begrenzte Verbreitung gefunden. Es ist schwierig, korrekt zu implementieren (Ressourcen zu pushen, die der Browser bereits im Cache hat, verschwendet Bandbreite), und einige CDNs haben die Unterstützung eingestellt. Chrome hat die Server-Push-Unterstützung in Version 106 (2022) entfernt. Das Konzept lebt im 103-Early-Hints-Mechanismus weiter, der einfacher und praktischer ist.

Warum Domain-Sharding nicht mehr nötig ist

In der HTTP/1.1-Ära verwendeten Webentwickler einen Trick namens Domain-Sharding, um das Limit von 6 Verbindungen pro Domain zu umgehen. Sie lieferten Bilder von img1.example.com, CSS von cdn.example.com und Schriftarten von wieder einer anderen Subdomain aus. Das vervielfachte die Anzahl paralleler Verbindungen, die der Browser öffnen konnte.

Mit HTTP/2 ist Domain-Sharding nicht nur überflüssig, sondern sogar kontraproduktiv. Weil HTTP/2 alle Anfragen über eine einzige Verbindung multiplext, zwingt das Aufteilen von Ressourcen auf mehrere Domains den Browser, zusätzliche TCP-Verbindungen und TLS-Handshakes aufzubauen. Jede neue Verbindung fügt Latenz hinzu. Eine WordPress-Seite, die mit Domain-Sharding für HTTP/1.1 optimiert wurde, sollte ihre Ressourcen auf weniger Domains konsolidieren, wenn sie auf HTTP/2 wechselt.

Ebenso wird das Zusammenführen von CSS- und JavaScript-Dateien in einzelne Bundles (eine weitere gängige HTTP/1.1-Optimierung) mit HTTP/2 weniger wichtig. Das Senden vieler kleinerer Dateien funktioniert dank Multiplexing effizient, und es hat den zusätzlichen Vorteil besseren Cachings: Wenn sich eine kleine Datei ändert, muss nur diese Datei neu heruntergeladen werden, nicht das gesamte zusammengeführte Bundle.

HTTP/2 erfordert in der Praxis HTTPS

Die HTTP/2-Spezifikation erfordert technisch gesehen keine Verschlüsselung. Man kann HTTP/2 über einfaches TCP nutzen (genannt h2c, für HTTP/2 Cleartext). Allerdings haben alle großen Browser (Chrome, Firefox, Safari, Edge) entschieden, HTTP/2 nur über TLS zu implementieren (genannt h2). Das bedeutet, dass du für alle praktischen Zwecke ein SSL/TLS-Zertifikat brauchst, um HTTP/2 zu nutzen.

Das ist heutzutage keine wirkliche Einschränkung mehr. Kostenlose Zertifikate von Let's Encrypt haben HTTPS für jeden zugänglich gemacht, und die meisten WordPress-Hosting-Anbieter inkludieren SSL-Zertifikate in ihren Tarifen. Wenn deine WordPress-Seite noch auf reinem HTTP läuft, ist der Wechsel zu HTTPS eine Voraussetzung für HTTP/2 und bringt eigene Sicherheitsvorteile mit sich.

HTTP/3 und QUIC: Der nächste Schritt

HTTP/3 (RFC 9114, finalisiert Juni 2022) ist die nächste Evolution. Während HTTP/2 auf TCP aufsetzt, ersetzt HTTP/3 TCP komplett durch ein neues Transportprotokoll namens QUIC. QUIC basiert auf UDP und integriert TLS-1.3-Verschlüsselung direkt in die Transportschicht. Die wichtigsten Vorteile von HTTP/3 gegenüber HTTP/2 sind:

• Schnellerer Verbindungsaufbau: QUIC kombiniert den TCP-Handshake und den TLS-Handshake in einen einzigen Round-Trip und reduziert so die Verbindungsaufbauzeit. Für wiederkehrende Besucher kann es sogar eine Verbindungswiederaufnahme ohne Round-Trip erreichen.
• Kein Head-of-Line-Blocking: Bei HTTP/2 über TCP blockieren alle Streams auf einer Verbindung, wenn ein einzelnes Paket verloren geht, bis das Paket erneut übertragen wird. QUIC behandelt Paketverluste pro Stream, sodass ein verlorenes Paket nur den betroffenen Stream verzögert, nicht alles andere.
• Bessere Mobile-Performance: QUIC handhabt Netzwerkwechsel (wie den Wechsel von WLAN zu Mobilfunk) eleganter, weil Verbindungen durch eine Verbindungs-ID identifiziert werden statt durch IP-Adresse und Port.

Große CDN-Anbieter wie Cloudflare und Fastly unterstützen bereits HTTP/3. Die meisten Hosting-Anbieter sind noch im Prozess der Einführung. Für WordPress-Betreiber ist HTTP/3-Unterstützung weitgehend eine serverseitige Angelegenheit; du musst nichts in WordPress selbst ändern.

Wie du prüfst, ob dein Host HTTP/2 unterstützt

Es gibt mehrere Möglichkeiten zu überprüfen, ob deine WordPress-Seite über HTTP/2 ausgeliefert wird:

• Browser DevTools: Öffne den Netzwerk-Tab in Chrome DevTools, klicke mit der rechten Maustaste auf die Spaltenheader und aktiviere die „Protokoll"-Spalte. Du solltest h2 für HTTP/2-Anfragen sehen.
• Online-Tools: Seiten wie der KeyCDN HTTP/2-Test oder der HTTP/2-Checker auf tools.keycdn.com können die HTTP/2-Unterstützung für jede URL überprüfen.
• Kommandozeile: Führe curl -I --http2 -s https://deineseite.de aus und suche nach HTTP/2 200 in der Antwort.
• InspectWP: Der Report enthält die erkannte HTTP-Version für deine WordPress-Seite.

Wenn dein Host kein HTTP/2 unterstützt, kann ein CDN wie Cloudflare vor deiner Seite HTTP/2- (und HTTP/3-)Unterstützung bieten, selbst wenn dein Origin-Server nur HTTP/1.1 spricht. Das CDN übernimmt die HTTP/2-Verbindung mit dem Browser des Besuchers und kommuniziert mit deinem Origin-Server über das Protokoll, das er unterstützt.

WordPress-Performance-Auswirkungen

Eine typische WordPress-Seite lädt zwischen 20 und 80 einzelne Ressourcen: Stylesheets vom Theme und Plugins, JavaScript-Dateien, Web-Fonts, Bilder und manchmal externe Ressourcen von CDNs und Drittanbieter-Diensten. Unter HTTP/1.1 war das Laden all dieser Ressourcen der größte einzelne Faktor für die Seitenladezeit, wegen der Verbindungs- und Warteschlangen-Einschränkungen.

Nach dem Wechsel zu HTTP/2 sehen die meisten WordPress-Seiten bedeutsame Verbesserungen bei der Time to First Contentful Paint und der gesamten Seitenladezeit. Die genaue Verbesserung hängt davon ab, wie viele Ressourcen deine Seite lädt, aber Reduktionen von 20–50 % der Ladezeit sind üblich für Seiten, die vorher auf HTTP/1.1 liefen. Seiten mit vielen kleinen Ressourcen (was typisch für WordPress mit mehreren aktiven Plugins ist) profitieren am meisten.

Bedenke, dass HTTP/2 andere Performance-Optimierungen nicht ersetzt. Du brauchst weiterhin ordentliches Caching, Bildoptimierung und effizienten Code. Aber HTTP/2 beseitigt einen signifikanten Engpass auf Infrastruktur-Ebene, den keine noch so gute WordPress-Plugin-Optimierung beheben kann.

Was InspectWP prüft

InspectWP erkennt die HTTP-Protokollversion deiner WordPress-Seite anhand der Response-Header. Wenn deine Seite über HTTP/1.1 ausgeliefert wird, markiert der Report dies als Performance-Bedenken und empfiehlt ein Upgrade auf HTTP/2. Wenn HTTP/2 oder HTTP/3 erkannt wird, wird es als positiver Befund gemeldet. Die HTTP-Version wird im Performance-Abschnitt des Reports angezeigt, zusammen mit anderen Server-Level-Metriken wie Komprimierung und Response-Headern.