Was sind HTTP/2 und HTTP/3? Ein praktischer Leitfaden für WordPress-Seiten

HTTP/2 und HTTP/3 sind die beiden aktuellen Versionen des Hypertext Transfer Protocol, also der Sprache, in der Browser Seiten von Webservern anfordern. HTTP/2 wurde 2015 standardisiert und wird von 100% der modernen Browser unterstützt. HTTP/3 wurde 2022 als RFC 9114 finalisiert und wird seit 2024 von allen großen Browsern unterstützt. Beide sind nahtlose Upgrades gegenüber HTTP/1.1: gleiche URLs, gleiches HTML, aber deutlich schnellere Seitenladezeiten, vor allem in Mobilfunknetzen und auf Verbindungen mit hoher Latenz.

Schnelle Antwort: welche Version sollte meine WordPress-Seite nutzen?

Die richtige Antwort 2026 lautet "HTTP/3 mit HTTP/2 als Fallback". Jeder Browser handelt automatisch die höchste Version aus, die beide Seiten unterstützen, du musst dich also nicht entscheiden. Wenn dein Server HTTP/3 spricht, nutzen moderne Browser HTTP/3; ältere Browser fallen auf HTTP/2 zurück; sehr alte Clients auf HTTP/1.1. Es gibt kein Szenario, in dem HTTP/2 oder HTTP/3 für eine reale WordPress-Seite langsamer wäre als HTTP/1.1, also stellt sich nur die Frage, ob dein Hosting-Stack das unterstützt.

Welches Problem löst HTTP/2 gegenüber HTTP/1.1?

HTTP/1.1, das Protokoll, das das Web von 1997 bis 2015 getragen hat, hat auf einer modernen Seite einen entscheidenden Konstruktionsfehler: es öffnet eine TCP-Verbindung pro Ressource und nur sechs parallel pro Domain. Eine typische WordPress-Seite lädt 50 bis 150 Ressourcen (CSS, JS, Bilder, Fonts, Tracking-Skripte). Unter HTTP/1.1 werden diese 100+ Requests durch eine Warteschlange von sechs Verbindungen serialisiert, jede wartet darauf, dass die vorherige fertig wird. Der Browser sitzt buchstäblich untätig herum und wartet darauf, dass Slots frei werden.

HTTP/2 löst das mit drei Änderungen:

• Multiplexing. Eine einzige TCP-Verbindung transportiert beliebig viele parallele Request/Response-Paare (sogenannte Streams). Alle 150 Ressourcen laufen über eine Verbindung, ineinander verschachtelt.
• Header-Kompression (HPACK). HTTP-Header (Cookies, User-Agent, Referer) machen pro Request oft mehrere KB aus. HPACK komprimiert sie und merkt sich wiederkehrende Header, was den Overhead pro Request von Kilobytes auf Bytes reduziert.
• Binär-Framing. HTTP/1.1 ist text-basiert und mehrdeutig zu parsen. HTTP/2 nutzt ein binäres Frame-Format, das für Server und Proxies schneller zu verarbeiten ist und eine ganze Klasse von Smuggling- und Parsing-Angriffen eliminiert.

Netto-Effekt: eine WordPress-Seite, die über HTTP/1.1 in 4 Sekunden lädt, lädt über HTTP/2 typischerweise in 1,5 bis 2,5 Sekunden, auf demselben Server. Der Effekt ist im Mobilfunk größer, weil sich der Verbindungs-Overhead über alle Requests verteilt.

Was bringt HTTP/3 zusätzlich gegenüber HTTP/2?

HTTP/3 behält alles, was HTTP/2 eingeführt hat (Multiplexing, Header-Kompression, Binär-Framing), ersetzt aber den darunterliegenden Transport. Statt TCP läuft HTTP/3 über QUIC, ein Transport-Protokoll, das auf UDP aufbaut. Klingt nach Implementierungsdetail, behebt aber drei reale Performance-Probleme:

• Head-of-Line-Blocking auf TCP-Ebene. HTTP/2 multiplext Streams über eine TCP-Verbindung, aber TCP selbst liefert Pakete in der Reihenfolge aus, in der sie geschickt wurden. Geht ein Paket verloren, blockieren alle Streams auf dieser Verbindung, bis die erneute Übertragung ankommt. QUIC behandelt Paketverluste pro Stream, sodass ein verlorenes Paket nur den Stream betrifft, zu dem es gehört.
• Schnellerer Verbindungsaufbau. Eine HTTPS-Verbindung über TCP braucht drei Roundtrips (TCP-Handshake, dann TLS-Handshake). QUIC kombiniert das in einen Roundtrip für neue Verbindungen und in null Roundtrips für wiederkehrende Verbindungen innerhalb weniger Minuten (0-RTT genannt). Auf einer Mobilfunkverbindung mit 100ms Latenz spart das 200-300ms, bevor das erste Byte Content überhaupt loslädt.
• Connection Migration. QUIC-Verbindungen werden über eine Connection-ID identifiziert, nicht über IP + Port. Wenn ein Handy von WLAN auf Mobilfunk wechselt, überlebt die QUIC-Verbindung. TCP-Verbindungen müssten sich neu aufbauen.

Realer Gewinn obendrauf gegenüber HTTP/2: typisch 5-15% schneller bei initialen Seitenladezeiten, mehr in verlustbehafteten Mobilfunknetzen, weniger auf einer stabilen kabelgebundenen Verbindung.

Wie prüfe ich, welche HTTP-Version meine WordPress-Seite gerade nutzt?

Vier zuverlässige Methoden, vom schnellsten zum autoritativsten:

1. InspectWP-Report. Der Performance-Abschnitt jedes InspectWP-Reports listet die für das Hauptdokument ausgehandelte HTTP-Version. Eine Zeile, kein Setup.
2. Chrome DevTools. DevTools öffnen (F12), Netzwerk-Tab, Seite neu laden, mit Rechtsklick auf einen Spaltenkopf "Protocol" aktivieren. Die Spalte zeigt h2 für HTTP/2 und h3 für HTTP/3 (in manchen Chrome-Versionen auch http/3).
3. Kommandozeile mit curl. curl -I --http2 https://deineseite.de für HTTP/2 oder curl -I --http3 https://deineseite.de für HTTP/3 (curl 7.66+ nötig). Die Antwortzeile zeigt HTTP/2 200 oder HTTP/3 200.
4. Öffentliche Test-Tools. https://http3check.net testet speziell HTTP/3-Unterstützung. https://tools.keycdn.com/http2-test testet HTTP/2-Unterstützung. Beide liefern die ausgehandelte Version und den Alt-Svc-Header (der HTTP/3-Unterstützung ankündigt).

Ein Stolperdraht: eine Seite kann HTTP/3 im Alt-Svc-Header ankündigen, ohne dass HTTP/3 tatsächlich funktioniert. Der Header sagt dem Browser "versuche es beim nächsten Mal mit HTTP/3 auf UDP-Port 443", aber wenn UDP irgendwo auf dem Weg blockiert wird, fällt der Browser still auf HTTP/2 zurück. Immer mit einem echten Request verifizieren, nicht nur über den Alt-Svc-Header.

Wie aktiviere ich HTTP/2 oder HTTP/3 auf einer WordPress-Seite?

HTTP-Versionen werden auf Webserver-Ebene ausgehandelt. WordPress selbst hat damit nichts zu tun; die Wahl läuft zwischen deinem Hosting-Stack und dem Browser. Drei Szenarien decken nahezu alle Seiten ab:

Szenario 1: Managed WordPress Hosting

Fast jeder Managed-WordPress-Hoster (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) liefert HTTP/2 seit 2018 standardmäßig aus. HTTP/3-Unterstützung ist 2026 weit verbreitet, aber nicht universell. Kinsta, Cloudways, SiteGround, Raidboxes und Pressable haben HTTP/3 standardmäßig aktiviert. WP Engine bietet es als Toggle. Wenn dein Hoster nicht in dieser Liste ist, frag den Support; es ist meist ein One-Click-Change.

Szenario 2: Shared Hosting mit cPanel oder Plesk

cPanel-Hoster (IONOS, Hostinger, viele Reseller) liefern HTTP/2 meist standardmäßig aus und HTTP/3 auf neueren Accounts. Prüfen, ob EasyApache 4 mit dem Modul mod_http2 aktiviert ist. HTTP/3 in Apache braucht das Modul mod_http3, das immer noch als experimentell gilt. Der pragmatische Weg auf Shared Hosting ist, Cloudflare vorzuschalten (Free-Tier reicht) und Cloudflare die HTTP/3-Terminierung übernehmen zu lassen, was deren Default seit 2019 ist.

Szenario 3: Selbst verwalteter VPS oder Root-Server

Die Konfiguration hängt vom Webserver ab:

• nginx. HTTP/2 braucht nginx 1.9.5+ und die http2-Direktive in der listen-Zeile: listen 443 ssl http2;. HTTP/3 braucht nginx 1.25+ kompiliert mit QUIC-Unterstützung: listen 443 quic reuseport; listen 443 ssl; plus add_header Alt-Svc 'h3=":443"; ma=86400';. Das reuseport-Flag ist kritisch, sonst startet HTTP/3 still nicht.
• Apache. HTTP/2 braucht aktiviertes mod_http2 und die Direktive Protocols h2 h2c http/1.1 im VirtualHost. HTTP/3 in Apache ist weiterhin experimentell; die meisten Apache-Produktionssetups bleiben bei HTTP/2 und schalten nginx, Caddy oder Cloudflare davor für HTTP/3.
• Caddy. HTTP/3 ist seit Caddy 2.6 standardmäßig aktiv. Nichts zu konfigurieren; wenn HTTPS läuft, läuft HTTP/3.
• LiteSpeed und OpenLiteSpeed. Beide liefern HTTP/3 standardmäßig aus. Einer der Gründe, warum LiteSpeed im WordPress-Hosting-Markt Anteile gewonnen hat.

Eine Anforderung, die auf selbst verwalteten Setups oft übersehen wird: HTTP/3 braucht UDP-Port 443 in der Firewall offen. Viele Default-Server-Konfigurationen öffnen nur TCP 443. Auf Ubuntu sudo ufw allow 443/udp, in anderen Firewall-Stacks das Äquivalent.

Welche Rolle spielen Cloudflare und andere CDNs?

Ein CDN vor deinem Origin-Server terminiert üblicherweise das moderne Protokoll an der Edge und spricht dann mit deinem Origin über HTTP/1.1 oder HTTP/2. Aus Sicht des Besuchers läuft die Verbindung zum Edge-Knoten (oft 20-50ms entfernt) über HTTP/3, schnell und modern. Die Verbindung vom CDN zum Origin läuft Server-zu-Server in Rechenzentrumsnetzen, wo das Protokoll deutlich weniger zählt. Genau deshalb bringt Cloudflare vor einem Shared-Hoster, der nur HTTP/1.1 spricht, trotzdem den Großteil des Speedgewinns. Der Besucher fasst den Origin nie direkt an.

Haken: liefert dein Origin einen Cache-Bust-Header (no-cache, no-store) oder sind deine Inhalte nicht cachebar (eingeloggte WordPress-Seiten, WooCommerce-Warenkorb), muss das CDN bei jedem Request den Origin anfragen, und der langsame Origin-zu-CDN-Hop wird zum Flaschenhals. Für diese Fälle zählt das Protokoll am Origin weiterhin.

Häufige Fehler und wie du sie vermeidest

• HTTP/2 als Wundermittel für langsame Seiten behandeln. HTTP/2 behebt Verbindungs-Overhead. Es behebt kein langsames PHP, keine unoptimierten Queries, keine 5MB Hero-Bilder, kein render-blockierendes JavaScript. Wenn dein TTFB (Time to First Byte) 2 Sekunden ist, sparen dir HTTP/3-Umstieg 200ms. Die anderen 1800ms sind weiterhin PHP und Datenbank.
• HTTP/1.1 deaktivieren. Suchmaschinen-Crawler, Monitoring-Tools und ältere Client-Bibliotheken sprechen manchmal nur HTTP/1.1. HTTP/1.1 ganz auszuschalten bricht sie. Moderne Webserver verhandeln automatisch die höchste gemeinsam unterstützte Version; alle drei (h3, h2, http/1.1) aktiviert lassen.
• Assets aus HTTP/1.1-Gewohnheit zusammenfassen und inlinen. Unter HTTP/1.1 war es ein großer Gewinn, 30 CSS-Dateien zu einer zu kombinieren, wegen des Verbindungslimits. Unter HTTP/2 und HTTP/3 verliert diese Optimierung an Bedeutung und kann sogar schaden (ein einziges großes Bundle invalidiert den Cache bei jeder Änderung; 30 kleine Dateien invalidieren nur die, die sich geändert haben). Die meisten WordPress-Performance-Plugins setzen weiterhin standardmäßig auf "alle kombinieren", weil Nutzer das erwarten, aber das ist 2026 nicht mehr der richtige Default.
• Annehmen, dass Alt-Svc bedeutet, HTTP/3 läuft. Der Header kündigt HTTP/3-Unterstützung an; er garantiert nicht, dass die Verbindung tatsächlich zustande kommt. Immer mit curl oder DevTools verifizieren.
• UDP an der Firewall blockieren. Eine häufige Ursache dafür, dass HTTP/3 still nicht funktioniert. Sowohl Server-Firewall als auch Netzwerk-Firewall prüfen (Security Group beim Cloud-Anbieter, ISP-Filterung auf Consumer-Verbindungen).

HTTP/2, HTTP/3 und Core Web Vitals

Googles Core Web Vitals messen Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Von den drei wird LCP am stärksten von der HTTP-Version beeinflusst. Das LCP-Element (meist das Hero-Bild oder der größte Block über dem Falz) muss komplett geladen sein, bevor LCP gemeldet wird, und Ladegeschwindigkeit ist genau das, was HTTP/2 und HTTP/3 verbessern. Seiten, die von HTTP/1.1 auf HTTP/2 wechseln, sehen LCP im Schnitt um 300-800ms sinken. Der Sprung von HTTP/2 auf HTTP/3 ist kleiner, typisch 50-200ms, aber in Mobilfunknetzen mit Paketverlust kann er größer ausfallen.

Was InspectWP prüft

Der Performance-Abschnitt jedes InspectWP-Reports zeigt, welche HTTP-Version für das Hauptdokument ausgehandelt wurde, dazu Content Encoding (gzip, Brotli) und HTML-Gesamtgröße. Läuft deine Seite 2026 noch auf HTTP/1.1, markiert der Report das als Warnung, weil es einer der wirkungsvollsten Performance-Gewinne mit dem geringsten Aufwand ist, meist ein einzelner Schalter im Hosting-Panel. Wenn du auf HTTP/2 bist, aber nicht auf HTTP/3, erscheint das als Hinweis; HTTP/3 ist der moderne Default, HTTP/2 aber weiterhin völlig akzeptabel. Die Version, die dein Browser sieht, ist die Version, die deine Besucher bekommen, der Report spiegelt also reale Performance, nicht theoretische Konfiguration.