HTTP/3-Adoption verharrt bei 21 % – die physikalische Ursache

Als die IETF HTTP/3 im Jahr 2022 standardisierte, war das Versprechen klar: ein auf QUIC basierendes Protokoll, das TCPs Head-of-Line-Blocking eliminiert, schnellere Verbindungsaufbauten und bessere Performance auf unzuverlässigen Netzwerken bietet. Vier Jahre später unterstützen 39,5 % der Websites HTTP/3 – aber nur 21,11 % der tatsächlichen Anfragen nutzen es, ein Rückgang vom Höchstwert von 22,16 % im Januar 2026. Die Adoptionskurve ist abgeflacht.

Das ist keine Geschichte darüber, dass Entwickler langsam upgraden. Es ist eine Geschichte über Physik.

Das Schnellnetz-Paradoxon

Auf Verbindungen mit hoher Bandbreite und niedriger Latenz – der Art, die die meisten Unternehmensnutzer und Rechenzentren nutzen – schneidet HTTP/3 schlechter ab als HTTP/2. Ein 2024 auf der ACM Web Conference vorgestelltes Papier maß eine 45,2-prozentige Datenratenreduktion für QUIC gegenüber HTTP/2 auf Netzwerken über 500 Mbit/s. Der Grund: QUICs Staukontrollalgorithmen wurden für verlustbehaftete, unberechenbare Mobilfunknetze entwickelt. Auf Glasfaser werden sie konservativ, wo TCPs jahrzehntealte Algorithmen das nicht sind.

QUIC läuft zudem über UDP, was bedeutet, dass es die Hardware-Offloading-Fähigkeiten moderner Netzwerkkarten für TCP nicht nutzen kann. Jedes QUIC-Paket benötigt CPU-Zyklen, die TCP-Pakete nicht brauchen. Im Maßstab, in Rechenzentren mit Millionen von Anfragen pro Sekunde, ist dieser Overhead signifikant.

Wo HTTP/3 wirklich gewinnt

Auf Mobilfunknetzen und in Schwellenländern sieht die Performance anders aus. Akamais Performance-Report 2025 fand eine 30-prozentige Latenzreduktion bei Verbindungen mit Paketverlust über 2 % – eine häufige Bedingung in zellularen Netzen in Afrika, Südasien und ländlichen Teilen Europas. Für Nutzer auf überlastetem WLAN oder beim Wechsel zwischen Funkzellen während einer Sitzung ist HTTP/3s Connection Migration (die eine Sitzung auch dann aufrechterhält, wenn sich die IP des Clients ändert) eine echte Verbesserung gegenüber TCPs Anforderung, Verbindungen neu aufzubauen.

Das schafft eine seltsame Kluft: HTTP/3 hilft den Nutzern, die es am meisten brauchen – denen mit schlechten Verbindungen –, macht es aber für Nutzer auf schnellen Verbindungen, die das meiste Traffic-Volumen tragen, marginal schlechter.

CDN-Adoption versus Traffic-Realität

Große CDN-Anbieter – Cloudflare, Fastly, Akamai – unterstützen HTTP/3 nativ. Der Markt für QUIC-fähige CDN-Edge-Dienste wächst von 2,84 Milliarden Dollar im Jahr 2025 auf 3,79 Milliarden Dollar im Jahr 2026 bei einer CAGR von 33 %. Aber ein Protokoll zu unterstützen und Traffic darüber zu routen, sind unterschiedliche Entscheidungen. CDNs bieten zunehmend selektive HTTP/3-Aktivierung basierend auf Client-Eigenschaften an: Mobilfunk-Clients mit hoher gemessener Latenz bekommen QUIC, Desktop-Clients auf Glasfaser bekommen HTTP/2.

Diese selektive Bereitstellung ist wahrscheinlich gesünder als eine pauschale Einführung. Sie konzentriert die Gewinne von HTTP/3 dort, wo sie real sind, und hält die Kosten für Nutzer unsichtbar, die nicht profitieren würden.

Das 21%-Plateau ist kein Misserfolg

Die Adoptionskurve als Misserfolg zu betrachten, verkennt, was passiert ist. HTTP/3 hat genau das erreicht, wofür es entwickelt wurde – es verbesserte die Performance für verlustbehaftete, hochlatenzige Verbindungen. Der Fehler war die breitere Erzählung, dass es HTTP/2 universell für allen Traffic ersetzen würde. Protokolle funktionieren nicht so.

Die genauere Lesart: HTTP/3 wird der Standard für mobilfunklastigen Traffic, CDN-Client-Verbindungen mit variabler Qualität und alle Szenarien bleiben, in denen Connection Migration oder multiplexe Streams den UDP-Overhead rechtfertigen. HTTP/2 wird dominant bleiben für Server-zu-Server-, Rechenzentrums- und hochbandbreitigen Client-Traffic, wo TCPs Hardware-Optimierungen und ausgereifte Staukontrolle Vorteile haben.

Für Ingenieure, die heute Bereitstellungsentscheidungen treffen, ist die Erkenntnis praktisch: Messen Sie Ihr tatsächliches Traffic-Profil, bevor Sie annehmen, dass HTTP/3 es verbessert. Wenn Ihre Nutzer hauptsächlich auf Hochbandbreitenverbindungen mit geringem Paketverlust sind, kann der Protokollwechsel Ihren Durchsatz kosten. Wenn sie mobil in Märkten mit variabler Abdeckung sind, hilft es wahrscheinlich.

Was als Nächstes kommt

Die QUIC-Arbeitsgruppe bei der IETF ist sich der Performance-Lücke bei hohen Bandbreiten bewusst. Es wird an QUIC-Staukontrollalgorithmen gearbeitet, die Bandbreite auf zuverlässigen Netzen besser ausnutzen, sowie an Hardware-Level-UDP-Offloading-Unterstützung, die die CPU-Kostenlücke zu TCP schließen könnte. Diese Verbesserungen werden Zeit brauchen, um sich im Ökosystem zu verbreiten.

In der Zwischenzeit ist HTTP/3s Nutzungsanteil von 21 % keine Obergrenze – es ist der Punkt, an dem sich das Protokoll aufgrund seines Performance-Profils natürlich eingependelt hat. Ob es weiter wächst, hängt weniger vom Browser-Support ab (der universell ist) und mehr davon, ob sich die Performance-Eigenschaften des Protokolls auf den Netzwerktypen verbessern, die am meisten Traffic tragen.