HTTP/2 vs. HTTP/3: Was sich für die Performance ändert

1. HTTP/1.1 Head-of-Line-Blocking: das Ursprungsproblem

HTTP/1.1 erlaubt pro TCP-Verbindung praktisch nur eine ausstehende Anfrage gleichzeitig, weil Pipelining nie zuverlässig implementiert wurde und in der Praxis kaum genutzt wird. Browser umgehen das, indem sie bis zu sechs parallele TCP-Verbindungen pro Host öffnen, aber jede zusätzliche Verbindung kostet einen eigenen TCP- und TLS-Handshake. Beim Laden einer Produktseite mit vierzig Ressourcen, CSS, JS, Bilder und Fonts eingeschlossen, muss der Browser also entweder warten oder Verbindungen vervielfachen, was Verbindungsaufbau-Overhead und Serverlast spürbar erhöht.

Das eigentliche Problem heißt Head-of-Line-Blocking auf Anwendungsebene: Eine langsame Ressource am Anfang der Warteschlange blockiert alle nachfolgenden Anfragen auf derselben Verbindung, selbst wenn diese längst fertig wären. Domain-Sharding, also das künstliche Verteilen von Ressourcen über mehrere Subdomains, war eine verbreitete Notlösung. Sie erzeugt jedoch zusätzliche DNS-Lookups und TLS-Handshakes und kostet in der Praxis häufig mehr, als sie an Parallelität einspart.

2. HTTP/2 Multiplexing über eine einzige TCP-Verbindung

HTTP/2 löst das Anwendungsebene-Problem durch echtes Multiplexing: Eine einzige TCP-Verbindung pro Host reicht aus, weil Anfragen und Antworten in kleine Frames zerlegt und über nummerierte Streams parallel übertragen werden. Der Browser kann hunderte Anfragen gleichzeitig auf derselben Verbindung ausstehend haben, der Server beantwortet sie in beliebiger Reihenfolge, und die Frames werden beim Empfänger anhand ihrer Stream-ID wieder den richtigen Ressourcen zugeordnet.

In der Praxis bedeutet das: Domain-Sharding wird kontraproduktiv, weil es die Vorteile des Multiplexing pro Verbindung wieder aufhebt und stattdessen mehrere TCP-Handshakes erzwingt. Für Magento-Shops mit vielen kleinen Assets, Icons, CSS-Fragmenten und JS-Chunks, ist eine einzige HTTP/2-Verbindung fast immer schneller als das alte Sharding-Muster, weil Verbindungsaufbau und die Slow-Start-Phase des TCP-Fensters nur einmal statt mehrfach durchlaufen werden müssen.

3. HTTP/2 Server Push: gute Idee, gescheitert

Server Push sollte es Servern erlauben, Ressourcen proaktiv zu senden, bevor der Browser sie überhaupt angefragt hat, etwa CSS und kritisches JavaScript direkt beim HTML-Response. Die Idee dahinter: Der Server kennt die Abhängigkeiten der Seite und kann Roundtrips einsparen, die sonst durch das Parsen des HTML und das anschließende Anfragen referenzierter Ressourcen entstehen.

In der Praxis scheiterte Server Push an mehreren Problemen gleichzeitig. Browser-Caches wurden ignoriert, sodass bereits gecachte Ressourcen unnötig erneut gepusht wurden. Server konnten kaum einschätzen, was der Client tatsächlich noch braucht, was zu verschwendeter Bandbreite führte. Chrome entfernte die Unterstützung 2022 vollständig, andere Browser folgten kurz darauf. Der Ersatz sind <link rel="preload">-Hinweise und der HTTP-Statuscode 103 Early Hints, der kritische Ressourcen ankündigt, während der Server noch die eigentliche Antwort berechnet, ohne die Nachteile des Cache-Ignorierens.

<!-- Hyva phtml: replace Server Push with priority hints and preload -->
<!-- Server Push ignored the browser cache and was removed from Chrome in 2022 -->
<link rel="preload" href="{{$block->getViewFileUrl('css/critical.css')}}" as="style">
<link rel="preload" href="{{$block->getViewFileUrl('js/critical.js')}}" as="script">

<!-- Modern replacement for push: HTTP 103 Early Hints -->
<!-- Sent by the server before the full HTML response is ready -->
<!--
HTTP/1.1 103 Early Hints
Link: </css/critical.css>; rel=preload; as=style
Link: </js/critical.js>; rel=preload; as=script
-->

4. HPACK: Header-Kompression in HTTP/2

HTTP-Header wiederholen sich fast identisch bei jeder Anfrage: User-Agent, Cookies, Accept-Header, Referer. Unkomprimiert verursacht das bei vielen kleinen Requests erheblichen Overhead, besonders bei Cookie-lastigen Magento-Sessions. HPACK löst das mit einer statischen Tabelle häufiger Header-Namen-Wert-Paare und einer dynamischen Tabelle, die sich Header merkt, die bereits über die Verbindung übertragen wurden. Wiederholte Header werden danach nur noch als kurzer Index referenziert statt als vollständiger String gesendet.

Für Magento-Shops mit langen Session-Cookies und vielen XHR-Requests, etwa Mini-Cart-Updates oder Layered-Navigation-Filter, reduziert HPACK die Headergröße pro Request spürbar, weil sich wiederholende Cookie- und Accept-Werte nach der ersten Übertragung nur noch referenziert werden. Wichtig: HPACK komprimiert nicht den Body, nur die Header. Das ist ein separater Mechanismus von der eigentlichen Content-Kompression über Gzip oder Brotli.

5. HTTP/3 und QUIC: Transport über UDP statt TCP

HTTP/3 ist keine inkrementelle Weiterentwicklung von HTTP/2 auf Anwendungsebene, sondern ein Wechsel des darunterliegenden Transportprotokolls. Statt auf TCP baut HTTP/3 auf QUIC auf, das seinerseits über UDP läuft. QUIC wurde von Google entwickelt und 2021 als RFC 9000 standardisiert. Der Grund für den Wechsel: TCP ist ein Kernel-Protokoll, dessen Verhalten, Congestion Control, Retransmission und Handshake fest im Betriebssystem verankert ist und sich nur langsam über Jahre weiterentwickeln lässt.

QUIC implementiert die mit TCP vergleichbare Zuverlässigkeit, also Reihenfolge, Bestätigung und Neuübertragung verlorener Pakete, vollständig im User-Space, meist direkt in der Anwendung oder Bibliothek. Das erlaubt schnellere Iteration, weil neue QUIC-Versionen nicht auf Kernel-Updates auf Millionen Endgeräten warten müssen. Zusätzlich integriert QUIC TLS 1.3 direkt in den Transport, statt es als separate Schicht obendrauf zu legen. Das spart einen kompletten Roundtrip beim Verbindungsaufbau.

# nginx.conf - enable HTTP/3 (QUIC) alongside HTTP/2
server {
    # HTTP/2 over TCP, still required as fallback
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    # HTTP/3 over QUIC/UDP - requires nginx 1.25.0+ built with --with-http_v3_module
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    ssl_certificate     /etc/nginx/ssl/mironsoft.de.crt;
    ssl_certificate_key /etc/nginx/ssl/mironsoft.de.key;
    ssl_protocols TLSv1.3;

    # Advertise HTTP/3 to browsers already connected via HTTP/2 or HTTP/1.1
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # QUIC needs its own congestion control tuning, not TCP's
    quic_retry on;
    ssl_early_data on;
}

6. Wie QUIC das TCP-Head-of-Line-Blocking löst

HTTP/2 löste das Head-of-Line-Blocking auf Anwendungsebene, hat aber weiterhin ein Problem auf Transportebene: TCP garantiert strikte Byte-Reihenfolge. Geht ein einzelnes TCP-Paket verloren, blockiert der gesamte Stream, bis das verlorene Paket neu übertragen wurde, selbst wenn die Daten mehrerer unabhängiger HTTP/2-Streams betroffen sind. Ein einziges verlorenes Paket auf einer mobilen Verbindung mit Paketverlust bremst also plötzlich alle parallelen Downloads gleichzeitig aus.

QUIC behandelt jeden Stream unabhängig auf Transportebene. Geht ein Paket verloren, das nur zu Stream A gehört, blockiert das ausschließlich Stream A, während Stream B und C ungestört weiterlaufen. Das ist der entscheidende architektonische Unterschied zu HTTP/2 über TCP: Multiplexing findet nicht nur logisch auf Anwendungsebene statt, sondern auch tatsächlich unabhängig auf Transportebene. Auf Verbindungen mit spürbarer Paketverlustrate, etwa mobilen Netzen in Funklöchern oder überlasteten WLANs, macht sich dieser Unterschied in messbar saubereren Ladezeiten bemerkbar.

7. 0-RTT, schnellere Handshakes und Connection Migration

Ein klassischer TCP-plus-TLS-1.3-Handshake benötigt bei einer neuen Verbindung typischerweise zwei Roundtrips, bevor die ersten Anwendungsdaten fließen: einen für den TCP-SYN-SYN-ACK-Austausch, einen für den TLS-Handshake. QUIC kombiniert Transport- und Verschlüsselungs-Handshake in einem einzigen Roundtrip, also 1-RTT, für neue Verbindungen. Bei einer bereits bekannten Verbindung, deren Client zuvor schon einmal verbunden war, ermöglicht QUIC sogar 0-RTT: Der Client sendet Anwendungsdaten direkt mit dem ersten Paket, ohne auf eine Serverantwort zu warten.

Der praktische Effekt für wiederkehrende Besucher eines Magento-Shops: Die erste Anfrage nach einem Verbindungsabbau, etwa durch App-Wechsel auf dem Smartphone, kommt spürbar schneller an, weil kein zusätzlicher Roundtrip verloren geht. Wichtig ist die Kehrseite: 0-RTT-Daten sind anfällig für Replay-Angriffe, weshalb sie nur für idempotente Anfragen wie GET-Requests auf statische Ressourcen verwendet werden sollten, niemals für Checkout- oder Zahlungsanfragen.

Ein weiterer Vorteil von QUIC betrifft mobile Nutzer direkt: Connection Migration erlaubt es, eine bestehende Verbindung fortzusetzen, wenn sich die IP-Adresse des Clients ändert, etwa beim Wechsel von WLAN auf Mobilfunk beim Verlassen des Hauses. QUIC identifiziert Verbindungen über eine Connection-ID statt über das klassische Vierer-Tupel aus Quell-IP, Quell-Port, Ziel-IP und Ziel-Port. Bei TCP erzwingt ein IP-Wechsel einen kompletten Verbindungsabbruch und Neuaufbau samt Handshake, bei QUIC läuft der Download nahtlos weiter, ein spürbarer Unterschied für Nutzer, die während des Checkouts das Gebäude verlassen oder in die U-Bahn einsteigen.

# Force curl to negotiate HTTP/3 directly and show timing
curl --http3 -o /dev/null -s -w \
  "protocol: %{http_version}\nconnect: %{time_connect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" \
  https://mironsoft.de/

# Verify 0-RTT session resumption on a second connection
# (requires a TLS session ticket from a prior connection)
curl --http3 --tlsv1.3 --tls-max 1.3 -v https://mironsoft.de/ 2>&1 | grep -i "early data\|0-RTT"

8. Server- und CDN-Unterstützung: Nginx, Varnish, Cloudflare, ALPN, Alt-Svc

Damit ein Browser HTTP/3 überhaupt nutzt, müssen Client und Server sich auf das Protokoll einigen. Das geschieht über zwei Mechanismen: ALPN, Application-Layer Protocol Negotiation, signalisiert während des TLS-Handshakes, welche Protokolle unterstützt werden, und der Alt-Svc-Response-Header kündigt über HTTP/2 oder HTTP/1.1 an, dass unter derselben Domain auch HTTP/3 verfügbar ist. Der erste Seitenaufruf läuft deshalb praktisch immer über HTTP/2, erst nachfolgende Anfragen wechseln zu HTTP/3, sobald der Browser den Alt-Svc-Header gesehen hat.

Auf Serverseite ist die Unterstützung uneinheitlich gewachsen. Nginx unterstützt HTTP/3 seit Version 1.25.0 nativ, zuvor nur über einen separaten Quic-Branch. Cloudflare, Fastly und die meisten großen CDNs bieten HTTP/3 seit Jahren produktiv an. Varnish spricht bis heute kein natives QUIC oder HTTP/3 und terminiert es nicht selbst, deshalb läuft HTTP/3 in typischen Magento-Setups über einen vorgeschalteten Reverse Proxy oder ein CDN, das auf HTTP/2 oder HTTP/1.1 zu Varnish zurückfällt. Das ist unkritisch, weil der größte Performancegewinn von QUIC ohnehin auf der letzten Meile zum Endgerät entsteht, nicht zwischen Cache und Applikationsserver im eigenen Rechenzentrum.

# Check which protocols the server offers via ALPN during the TLS handshake
openssl s_client -alpn h3,h2,http/1.1 -connect mironsoft.de:443 </dev/null 2>&1 | grep "ALPN protocol"

# Confirm the server advertises HTTP/3 to HTTP/2 clients
curl -I --http2 https://mironsoft.de/ | grep -i "alt-svc"
# Expected: alt-svc: h3=":443"; ma=86400

9. HTTP/1.1, HTTP/2 und HTTP/3 im direkten Vergleich

Der Wechsel von HTTP/1.1 über HTTP/2 zu HTTP/3 löst technische Probleme in klar abgegrenzten Schichten, aber keines der drei Protokolle ersetzt Optimierungsarbeit auf Anwendungsebene. Für einen Magento- oder Hyvä-Shop ist der praktische Rollout unspektakulär: Wer ein CDN wie Cloudflare oder Fastly einsetzt, aktiviert HTTP/3 meist über einen einzigen Schalter im Dashboard, ohne die Magento- oder Nginx-Konfiguration überhaupt anzufassen. Wer HTTP/3 direkt am Origin-Server terminieren will, muss sicherstellen, dass UDP-Port 443 in Firewall, Loadbalancer und Security-Groups freigegeben ist, ein Punkt, der in bestehenden, auf TCP ausgelegten Netzwerk-Regelwerken häufig übersehen wird.

Die Tabelle zeigt auch, was HTTP/3 explizit nicht leistet: Es beschleunigt weder PHP-Rendering noch Datenbankabfragen, komprimiert keine Bilder und verkleinert keine JavaScript-Bundles. Realistisch ist der größte messbare Effekt bei mobilen Besuchern mit instabiler Verbindung, während Desktop-Nutzer mit stabilem Glasfaseranschluss kaum einen Unterschied bemerken. Ob echte Besucher tatsächlich über HTTP/3 verbinden, statt es nur serverseitig zu konfigurieren, sollte über die Resource Timing API im Real User Monitoring verifiziert werden, nicht über einzelne manuelle Tests.

// Real User Monitoring: verify which protocol resources actually used
function reportProtocolUsage() {
  const entries = performance.getEntriesByType('resource');
  const byProtocol = {};

  entries.forEach((entry) => {
    // nextHopProtocol reports "h3", "h2", "http/1.1" per resource
    const protocol = entry.nextHopProtocol || 'unknown';
    byProtocol[protocol] = (byProtocol[protocol] || 0) + 1;
  });

  // Send to analytics backend to see real-world HTTP/3 adoption
  navigator.sendBeacon('/rum/protocol-usage', JSON.stringify(byProtocol));
}

window.addEventListener('load', () => setTimeout(reportProtocolUsage, 0));

10. Zusammenfassung

Die Reise von HTTP/1.1 zu HTTP/2 und HTTP/3 löst ein Problem nach dem anderen in klar abgegrenzten Schichten. HTTP/2 behebt das Head-of-Line-Blocking auf Anwendungsebene durch Multiplexing über eine einzige Verbindung und komprimiert Header mit HPACK, hat aber weiterhin ein strukturelles Problem auf TCP-Ebene, wo ein einzelnes verlorenes Paket alle Streams gleichzeitig blockiert. HTTP/3 löst genau das, indem es TCP durch QUIC über UDP ersetzt, Streams unabhängig auf Transportebene multiplext, Verbindungsaufbau auf 1-RTT oder sogar 0-RTT reduziert und mit Connection Migration nahtlose Netzwerkwechsel für mobile Nutzer ermöglicht.

Keines dieser Protokolle ist ein Ersatz für solide Grundlagenarbeit. Ein Shop mit unoptimierten Bildern, blockierendem JavaScript oder einem schlecht konfigurierten Full Page Cache bleibt auch über HTTP/3 langsam. Der größte messbare Nutzen entsteht bei Verbindungen mit hoher Latenz, Paketverlust und häufigen Netzwerkwechseln, also vor allem bei mobilen Besuchern. Serverseitig ist die Aktivierung heute meist unkompliziert über CDN-Einstellungen möglich, während Varnish als Origin-Cache weiterhin auf HTTP/2 oder HTTP/1.1 angewiesen bleibt.

11. FAQ: HTTP/2 vs. HTTP/3