Was ist HTTP/3 und warum ist es wichtig?

HTTP/3 ist die dritte Hauptversion des Protokolls, auf dem das Web basiert, und baut auf QUIC statt auf TCP auf. Es verkürzt die Latenz beim Handshake, verhindert das „Head-of-Line-Blocking“ zwischen Anfragen und hält Verbindungen aufrecht, wenn ein mobiler Nutzer zwischen Netzwerken wechselt. In diesem Artikel erfährst du, was HTTP/3 ist, wann es messbare Vorteile bringt, wann nicht und wie du es in deiner Hosting-Umgebung aktivieren kannst.

HTTP/3 ist die dritte Hauptversion des Hypertext Transfer Protocol, also der Regeln, nach denen Browser und Server Daten austauschen. Es wurde 2022 von der IETF als RFC 9114 im Rahmen einer Reihe von Standards zur Modernisierung von HTTP fertiggestellt und wird heute von allen gängigen Browsern nativ unterstützt. Anfang 2026 macht HTTP/3 etwa 21 % des weltweiten Datenverkehrs im Cloudflareaus, wobei HTTP/2 mit etwa 51 % dominiert und HTTP/1.x immer noch 27 % ausmacht.

Die wichtigste Änderung betrifft die Transportschicht. HTTP/3 verzichtet auf TCP und läuft auf QUIC, einem auf UDP basierenden Protokoll. Allein diese Umstellung löst eine Reihe von Leistungsproblemen, die HTTP/2 nie ganz beheben konnte, insbesondere in mobilen und verlustbehafteten Netzwerken

Welches Problem löst HTTP/3?

HTTP/1.1 bearbeitete jeweils nur eine Anfrage pro TCP-Verbindung, was die Browser dazu zwang, mehrere Verbindungen parallel zu öffnen, nur um eine Seite zu laden. HTTP/2 hat das Problem behoben, indem es viele Anfragen über eine einzige TCP-Verbindung multiplexte. Das funktionierte gut, bis ein einziges Paket verloren ging.

TCP überträgt Daten als geordneten Datenstrom. Wenn auch nur ein einziges Paket verloren geht, müssen alle nachfolgenden Pakete auf die erneute Übertragung warten, unabhängig davon, zu welchem HTTP-Stream sie gehören. In Umgebungen mit hohem Paketverlust kann der Multi-Connection-Ansatz von HTTP/1.1 tatsächlich besser abschneiden als die Einzelverbindung von HTTP/2. Dies wird als „Head-of-Line-Blocking“ bezeichnet und verschlimmert sich in Mobilfunk-, WLAN- und überlasteten Netzwerken. HTTP/3 behebt dieses Problem, indem es jeder Anfrage einen eigenen, unabhängigen Stream innerhalb von QUIC zuweist, sodass ein verlorenes Paket nur den einen Stream verzögert, zu dem es gehört.

Wie unterscheidet sich HTTP/3 von HTTP/2?

Das sichtbare Verhalten ist ähnlich: Multiplex-Anfragen, Header-Komprimierung, Verschlüsselung als Standard. Auf der Transportschicht ändert sich jedoch alles.

Der verkürzte Handshake ist vor allem bei Erstbesuchen und beim erneuten Verbindungsaufbau wichtig. Die Verbindungsmigration ist besonders wichtig für mobile Nutzer, die zwischen Netzwerken wechseln, ohne dass die Sitzung unterbrochen wird – eine häufige Ursache für Abbrüche während des Bezahlvorgangs.

Was ist QUIC und warum wird es bei HTTP/3 verwendet?

QUIC ist ein Transportprotokoll, das ursprünglich bei Google entwickelt und von der IETF als RFC 9000 standardisiert wurde. Es läuft über UDP, da TCP nicht sinnvoll geändert werden kann, ohne die Betriebssystemkerne und die Netzwerk-Middleboxen zwischen Nutzern und Servern anzupassen – beides ist im Internet-Maßstab nicht praktikabel.

QUIC übernimmt die Zuverlässigkeitsfunktionen von TCP – Wiederholungsübertragung, Überlastungskontrolle und geordnete Zustellung –, setzt diese jedoch im Userspace mit unabhängigen Streams pro Anfrage um. Die TLS 1.3-Verschlüsselung ist Teil des Protokolls selbst und keine zusätzliche Schicht darüber. Jeder QUIC-Stream behandelt Paketverluste unabhängig, sodass eine Bildanfrage, bei der Pakete verloren gehen, das Laden der JavaScript-Datei nicht blockiert.

Warum ist HTTP/3 für die Website-Performance wichtig?

Die größten Verbesserungen zeigen sich dort, wo die Netzwerke unzuverlässig sind. Akamai hat bei HTTP/3 eine Latenzreduzierung von rund 30 % in Netzwerken mit hoher Latenz und hoher Paketverlustrate gemessen, wie sie in Mobilfunknetzen und auf Schwellenmärkten vorkommen – genau dort, wo Nutzer bei langsamen Seiten abspringen.

Bei reinen Glasfaser-Breitbandverbindungen sieht die Lage etwas komplizierter aus. Eine auf der ACM Web Conference 2024 vorgestellte, von Fachkollegen begutachtete Studie mit dem Titel „QUIC is not Quick Enough over Fast Internet“ von Zhang et al. ergab, dass QUIC in Chrome bei 1 Gbit/s bis zu 45,2 % weniger Durchsatz liefert als HTTP/2, wobei der Leistungsunterschied bereits bei 500 bis 600 Mbit/s einsetzt. Die Hauptursachen sind die ACK-Verarbeitung im User-Space von QUIC und die fehlende Unterstützung für UDP Generic Receive Offload in gängigen Kerneln. Die Verbreitung von HTTP/3 erreichte 2023 mit fast 28 % ihren Höhepunkt und hat sich 2026 bei etwa 21 % eingependelt, was zum Teil auf diese Durchsatzlücke in schnellen Netzwerken zurückzuführen ist. Die Technologie ist real, die Vorteile sind real, aber es ist kein kostenloses Upgrade für jede Workload.

Wer profitiert am meisten von HTTP/3?

Websites, die mobilen Traffic, ein internationales Publikum oder Besucher mit instabilen Netzverbindungen bedienen, verzeichnen die deutlichsten Verbesserungen. Am besten geeignet sind:

• E-Commerce-Shops, bei denen sich der Bezahlvorgang über WLAN- und Mobilfunk-Wechsel erstreckt. Durch die Verbindungsumschaltung wird verhindert, dass die Sitzung mitten im Zahlungsvorgang abbricht, was sich direkt auf die Konversionsraten auswirkt.
• Medien- und Streaming-Seiten mit Mobilnutzern. Unabhängige Streams bedeuten, dass ein verlorenes Videopaket die JavaScript- oder CSS-Darstellung des Players nicht verzögert.
• SaaS-Anwendungen mit Nutzern weltweit. Der schnellere Handshake verkürzt die Zeit bis zur Interaktivität bei jeder neuen Sitzung.
• WordPress und E-Commerce-Seiten, die bereits über ein CDN laufen. Die HTTP/3-Terminierung am Edge ist in der Regel mit einem Klick erledigt, ohne dass Änderungen am Ursprungsserver nötig sind.

Websites, die sich in erster Linie an Desktop-Nutzer mit schnellem Breitbandanschluss richten, werden möglicherweise kaum messbare Verbesserungen feststellen und in manchen durchsatzbegrenzten Szenarien sogar eine leicht schlechtere Leistung verzeichnen.

Was sind die Einschränkungen von HTTP/3?

Bevor du HTTP/3 für den Produktionsdatenverkehr aktivierst, solltest du dir über ein paar praktische Aspekte im Klaren sein.

Der UDP-Durchsatz auf Linux-Servern wird durch die Paketverarbeitung auf Kernel-Ebene begrenzt. In gängigen Kerneln fehlt die Unterstützung für UDP GRO, und ohne diese Funktion kann HTTP/3 die CPU auslasten, bevor das Netzwerk ausgelastet ist. Einige Firewalls und Middleboxen in Unternehmen blockieren UDP auf Port 443 oder drosseln dessen Datenrate. Browser erkennen dies und wechseln nahtlos auf HTTP/2 zurück, doch dieser Fallback verursacht eine zusätzliche Latenz bei der ersten Anfrage.

Suchmaschinen- und Social-Media-Crawler nutzen nach wie vor überwiegend HTTP/1.1 und HTTP/2. Eine Analyse Cloudflareergab, dass Such- und Social-Media-Bots auch Jahre nach Veröffentlichung des Standards HTTP/3 praktisch ignorierten, sodass SEO und Crawling-Effizienz nicht direkt davon profitieren. Auch das Debugging ist schwieriger. QUIC ist auf der Transportschicht verschlüsselt, sodass Paketaufzeichnungen weitaus weniger nützlich sind als bei TCP, es sei denn, du hast Zugriff auf die TLS-Schlüssel.

Wie aktivierst du HTTP/3 auf deinem Server?

Die Umsetzung hängt vom jeweiligen Stack ab. Bei den meistenVPS- und Dedicated-Server-Umgebungen InMotion Hosting stehen dir drei praktische Möglichkeiten zur Verfügung.

Über ein CDN. Das ist für die meisten Websites der schnellste Weg. Cloudflare im Bereich „Netzwerk“ seines Dashboards eine Umschaltfunktion für HTTP/3 Cloudflare , wobei die Terminierung am Cloudflare erfolgt, während dein Origin weiterhin HTTP/2 oder HTTP/1.1 verwendet. Lies dir unseren Leitfaden zur Einrichtung von Cloudflare deinem Konto durch.

Über NGINX. NGINX in Version 1.25.0 über das ngx_http_v3_module eine experimentelle HTTP/3-Unterstützung NGINX , die mit dem Konfigurationsparameter –with-http_v3_module aktiviert werden muss und OpenSSL 1.1.1 oder höher erfordert. Die Unterstützung für QUIC und HTTP/3 ist ab dieser Version in den offiziellen NGINX enthalten, wobei TLS 1.3 standardmäßig in der ssl_protocols-Direktive aktiviert ist, da QUIC dies erfordert. Du fügst ein listen 443 quic reuseport; Füge die Anweisung in deinen Serverblock ein und öffne den UDP-Port 443 in der Firewall.

Über LiteSpeed. Der LiteSpeed Web Server und OpenLiteSpeed werden seit Jahren standardmäßig mit aktiviertem HTTP/3 ausgeliefert. Der einzige Konfigurationsschritt besteht darin, sicherzustellen, dass der UDP-Port 443 offen ist.

Der Apache HTTP Server bietet in keiner Produktionsversion (Stand 2026) native HTTP/3-Unterstützung. Die gängige Abhilfe besteht darin, NGINX LiteSpeed als Reverse-Proxy vor Apache zu schalten oder den Datenverkehr über ein CDN zu leiten, das HTTP/3 am Edge-Punkt terminiert.

cPanel HTTP/3?

Nicht direkt. cPanel und EasyApache 4 enthalten kein HTTP/3-Modul, da Apache selbst es nicht unterstützt. Administratoren, die HTTP/3 auf einem cPanel Server nutzen möchten, setzen in der Regel einen Reverse-Proxy vor Apache ein oder lassen HTTP/3 über ein CDN laufen.

Das ist eher eine echte architektonische Entscheidung als nur eine Option, die man ankreuzen kann. Wenn dein Traffic hauptsächlich von Desktop-Nutzern und Such-Bots stammt, hat HTTP/3 keine hohe Priorität. Wenn du jedoch viel mobilen Traffic bedienst und Wert auf einen reibungslosen Checkout-Ablauf oder die Reaktionsgeschwindigkeit deiner App legst, ist die Terminierung von HTTP/3 am CDN der einfachste Weg.

Wie kannst du überprüfen, ob HTTP/3 funktioniert?

Öffne die Entwicklertools in einem beliebigen aktuellen Browser, wechsle zum Reiter „Netzwerk“, klicke mit der rechten Maustaste auf die Spaltenüberschriften und füge die Spalte „Protokoll“ hinzu. Seiten, die über HTTP/3 bereitgestellt werden, werden angezeigt h3 in dieser Spalte.

Benutzer der Befehlszeile können folgenden Befehl ausführen:

curl -I --http3 https://www.yourwebsite.com

curl -I --http3 https://www.yourwebsite.com

Moderne Curl-Builds werden standardmäßig mit HTTP/3-Unterstützung ausgeliefert. Online-Prüfprogramme wie HTTP3Check.net bestätigen, ob ein Hostname von außerhalb deines Netzwerks HTTP/3 aushandelt.

Solltest du HTTP/3 schon heute priorisieren?

Für die meisten Produktionswebsites ist HTTP/3 eher eine sinnvolle als eine unverzichtbare Verbesserung. Websites, die bereits HTTP/2 über HTTPS hinter einem CDN nutzen, haben die meisten der möglichen Leistungssteigerungen auf Protokollebene bereits ausgeschöpft. Die Aktivierung von HTTP/3 bringt einen zusätzlichen Nutzen, vor allem für mobile Nutzer und Besucher in Netzwerken mit hoher Paketverlustrate.

Die Vorgehensweise, die bei den meisten Websites wirklich den Ausschlag gibt:

1. Stelle sicher, dass HTTPS mit einem gültigen SSL-Zertifikat siteweit erzwungen wird.
2. Stelle sicher, dass HTTP/2 auf deinem Origin-Server aktiviert ist, und überprüfe dies anhand echter Seiten.
3. Aktiviere HTTP/3 im CDN, falls du eines nutzt. Es sind keine Änderungen am Ursprungsserver erforderlich.
4. Werte HTTP/3 auf Ursprungsebene nur dann aus, wenn dein Stack dies nativ unterstützt – wie beispielsweise NGINX LiteSpeed – und du über messbaren mobilen Datenverkehr verfügst.

Die größten Leistungssteigerungen lassen sich bei den meisten Websites durch die Optimierung von Datenbankabfragen, das Caching auf Anwendungsebene mit Redis und OPcache, die Bildoptimierung sowie die Anpassung der Infrastruktur an das Datenaufkommen erzielen. UltraStack InMotion Hostingkombiniert NGINX PHP-FPM, OPcache und Redis – genau für diese Art von Leistungsoptimierung auf Stack-Ebene.

Wenn du dir nicht sicher bist, wo dein Engpass liegt, kann das InMotion Hosting die tatsächlichen Kennzahlen deines Kontos – TTFB, Serverauslastung und Abfrageleistung – mit dir durchgehen und herausfinden, wo der nächste Euro aus deinem Optimierungsbudget den größten messbaren Effekt erzielt.