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 ueber 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 gegenueber 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 oeffnen (Browser erlauben typischerweise 6 pro Domain) und die restlichen Anfragen in die Warteschlange stellen. Das erzeugte kuenstliche Engpaesse, die jeden Seitenaufbau verlangsamten.

HTTP/2 behebt dies und mehr:

Multiplexing: Das ist die wichtigste einzelne Verbesserung. HTTP/2 ermoeglicht es, mehrere Anfragen und Antworten gleichzeitig ueber eine einzige TCP-Verbindung zu uebertragen. Dein Browser kann deine CSS-Datei, drei JavaScript-Dateien und zehn Bilder alle gleichzeitig ueber eine Verbindung anfordern. Kein Warten mehr, keine Warteschlange mehr, keine kuenstlichen Limits mehr. Der Server sendet Antworten zurueck, sobald sie verfuegbar sind, und der Browser setzt sie zusammen. Allein diese eine Aenderung kann die Ladezeiten fuer 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 haeufiger Header-Felder zwischen Client und Server pflegt. Nach der ersten Anfrage muessen nachfolgende Header nur noch die Unterschiede senden. Fuer eine WordPress-Seite, die 50+ Ressourcen pro Seitenaufruf laedt, kann das Dutzende Kilobytes pro Seitenaufruf einsparen.

Binaeres Framing: HTTP/1.1 ist ein textbasiertes Protokoll, was bedeutet, dass der Parser nach Zeilenumbruechen suchen, verschiedene Text-Kodierungen handhaben und diverse Sonderfaelle bewaeltigen muss. HTTP/2 verwendet eine binaere Framing-Schicht, die alle Kommunikation in wohldefinierte Frames verpackt. Binaere Daten sind schneller zu parsen, weniger fehleranfaellig 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 laesst 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 fuer viele Seiten.

Server Push: Diese Funktion erlaubt es dem Server, Ressourcen an den Browser zu senden, bevor der Browser sie ueberhaupt anfordert. Wenn der Browser eine HTML-Seite anfragt, kann der Server die CSS- und JavaScript-Dateien pushen, von denen er weiss, dass der Browser sie als naechstes braucht. Das eliminiert die Round-Trip-Verzoegerung, 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 Unterstuetzung eingestellt. Chrome hat die Server-Push-Unterstuetzung in Version 106 (2022) entfernt. Das Konzept lebt im 103-Early-Hints-Mechanismus weiter, der einfacher und praktischer ist.

Warum Domain-Sharding nicht mehr noetig ist

In der HTTP/1.1-Aera 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 oeffnen konnte.

Mit HTTP/2 ist Domain-Sharding nicht nur ueberfluessig, sondern sogar kontraproduktiv. Weil HTTP/2 alle Anfragen ueber eine einzige Verbindung multiplext, zwingt das Aufteilen von Ressourcen auf mehrere Domains den Browser, zusaetzliche TCP-Verbindungen und TLS-Handshakes aufzubauen. Jede neue Verbindung fuegt Latenz hinzu. Eine WordPress-Seite, die mit Domain-Sharding fuer HTTP/1.1 optimiert wurde, sollte ihre Ressourcen auf weniger Domains konsolidieren, wenn sie auf HTTP/2 wechselt.

Ebenso wird das Zusammenfuehren von CSS- und JavaScript-Dateien in einzelne Bundles (eine weitere gaengige HTTP/1.1-Optimierung) mit HTTP/2 weniger wichtig. Das Senden vieler kleinerer Dateien funktioniert dank Multiplexing effizient, und es hat den zusaetzlichen Vorteil besseren Cachings: Wenn sich eine kleine Datei aendert, muss nur diese Datei neu heruntergeladen werden, nicht das gesamte zusammengefuehrte Bundle.

HTTP/2 erfordert in der Praxis HTTPS

Die HTTP/2-Spezifikation erfordert technisch gesehen keine Verschluesselung. Man kann HTTP/2 ueber einfaches TCP nutzen (genannt h2c, fuer HTTP/2 Cleartext). Allerdings haben alle grossen Browser (Chrome, Firefox, Safari, Edge) entschieden, HTTP/2 nur ueber TLS zu implementieren (genannt h2). Das bedeutet, dass du fuer alle praktischen Zwecke ein SSL/TLS-Zertifikat brauchst, um HTTP/2 zu nutzen.

Das ist heutzutage keine wirkliche Einschraenkung mehr. Kostenlose Zertifikate von Let's Encrypt haben HTTPS fuer jeden zugaenglich gemacht, und die meisten WordPress-Hosting-Anbieter inkludieren SSL-Zertifikate in ihren Tarifen. Wenn deine WordPress-Seite noch auf reinem HTTP laeuft, ist der Wechsel zu HTTPS eine Voraussetzung fuer HTTP/2 und bringt eigene Sicherheitsvorteile mit sich.

HTTP/3 und QUIC: Der naechste Schritt

HTTP/3 (RFC 9114, finalisiert Juni 2022) ist die naechste Evolution. Waehrend 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-Verschluesselung direkt in die Transportschicht. Die wichtigsten Vorteile von HTTP/3 gegenueber HTTP/2 sind:

• Schnellerer Verbindungsaufbau: QUIC kombiniert den TCP-Handshake und den TLS-Handshake in einen einzigen Round-Trip und reduziert so die Verbindungsaufbauzeit. Fuer wiederkehrende Besucher kann es sogar eine Verbindungswiederaufnahme ohne Round-Trip erreichen.
• Kein Head-of-Line-Blocking: Bei HTTP/2 ueber TCP blockieren alle Streams auf einer Verbindung, wenn ein einzelnes Paket verloren geht, bis das Paket erneut uebertragen wird. QUIC behandelt Paketverluste pro Stream, sodass ein verlorenes Paket nur den betroffenen Stream verzoegert, 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.

Grosse CDN-Anbieter wie Cloudflare und Fastly unterstuetzen bereits HTTP/3. Die meisten Hosting-Anbieter sind noch im Prozess der Einfuehrung. Fuer WordPress-Betreiber ist HTTP/3-Unterstuetzung weitgehend eine serverseitige Angelegenheit; du musst nichts in WordPress selbst aendern.

Wie du pruefst, ob dein Host HTTP/2 unterstuetzt

Es gibt mehrere Moeglichkeiten zu ueberpruefen, ob deine WordPress-Seite ueber HTTP/2 ausgeliefert wird:

• Browser DevTools: oeffne den Netzwerk-Tab in Chrome DevTools, klicke mit der rechten Maustaste auf die Spaltenheader und aktiviere die "Protokoll"-Spalte. Du solltest h2 fuer HTTP/2-Anfragen sehen.
• Online-Tools: Seiten wie der KeyCDN HTTP/2-Test oder der HTTP/2-Checker auf tools.keycdn.com koennen die HTTP/2-Unterstuetzung fuer jede URL ueberpruefen.
• Kommandozeile: fuehre curl -I --http2 -s https://deineseite.de aus und suche nach HTTP/2 200 in der Antwort.
• InspectWP: der Report enthaelt die erkannte HTTP-Version fuer deine WordPress-Seite.

Wenn dein Host kein HTTP/2 unterstuetzt, kann ein CDN wie Cloudflare vor deiner Seite HTTP/2- (und HTTP/3-)Unterstuetzung bieten, selbst wenn dein Origin-Server nur HTTP/1.1 spricht. Das CDN uebernimmt die HTTP/2-Verbindung mit dem Browser des Besuchers und kommuniziert mit deinem Origin-Server ueber das Protokoll, das er unterstuetzt.

WordPress-Performance-Auswirkungen

Eine typische WordPress-Seite laedt 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 groesste einzelne Faktor fuer die Seitenladezeit, wegen der Verbindungs- und Warteschlangen-Einschraenkungen.

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 haengt davon ab, wie viele Ressourcen deine Seite laedt, aber Reduktionen von 20-50% der Ladezeit sind ueblich fuer Seiten, die vorher auf HTTP/1.1 liefen. Seiten mit vielen kleinen Ressourcen (was typisch fuer 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 prueft

InspectWP erkennt die HTTP-Protokollversion deiner WordPress-Seite anhand der Response-Header. Wenn deine Seite ueber 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.