Der technische Leiter aktiviert im CDN „HTTP/3 aktivieren“. Lighthouse gewinnt drei Punkte. Der TTFB-Server hat sich nicht bewegt: 890 ms auf der Warenkorbseite. Das Management kommt zu dem Schluss, dass „Hosting langsam ist“. In Wirklichkeit optimiert HTTP/3 hauptsächlich den Transport – nicht die PHP-Generierung oder eine überlastete Datenbank.
HTTP/3 basiert auf QUIC (UDP) statt TCP. Es reduziert den Handshake hin und her und widersteht Paketverlusten bei Mobilfunk- und Netzwerkänderungen besser (Wi-Fi → 4G). Dies ist eine nützliche Entwicklung – kein Zauberstab für nicht zwischengespeichertes WordPress.
Was HTTP/3 verbessert – und was es ignoriert
| Schicht | HTTP/3 funktioniert? | Beispiel |
|---|---|---|
| TLS-Handshake + Transport | Ja | Schnellere Verbindung bei instabilem 4G |
| Multiplexing-Anfragen | Ja (wie h2) | Viele kleine Vermögenswerte |
| TTFB PHP/SQL | Nein | Langsame dynamische Seite |
| Gewichtsbilder / JS | Nein | Hoher LCP |
| Langsames DNS | Nein | Auflösung noch vor QUIC |
Auf einer statischen Site, die von einem nahegelegenen CDN aus bedient wird und viele kurze Verbindungen aufweist, kann HTTP/3 eine wahrgenommene Latenz von 50–150 ms einsparen. Bei einer API mit großem POST oder einem langsamen WordPress-Administrator ist der Effekt unsichtbar.
Beim Aktivieren macht es Sinn
Ja, aktivieren, wenn:
- TTFB-Ursprung bereits akzeptabel (< 400 ms dynamischer oder effektiver Cache).
- Erheblicher mobiler Traffic, internationales Publikum.
- CDN verwaltet QUIC ohne komplexe Serverkonfiguration.
- Sie messen vorher/nachher mit RUM.
Melden, wenn:
- OPcache aus, kein Seitencache, langsame SQL-Abfragen.
- Sie haben Core Web Vitals auf der LCP/CLS-Seite noch nicht korrigiert.
– Der Host kündigt HTTP/3 an, erzwingt jedoch einen schlecht konfigurierten Proxy (Schleifen, inkonsistente Header).
Typische Bereitstellung: CDN vs. Ursprung
Die meisten in HTTP/3 aktiven Websites nutzen ein CDN:
- Besucher ↔ edge QUIC (HTTP/3)
- Edge ↔ Ursprung oft noch HTTP/1.1 oder HTTP/2
Der Host „unterstützt HTTP/3“ über seinen CDN-Partner, nicht unbedingt auf dem bloßen VPS. Überprüfen Sie den Vertrag: TLS-Terminierungsort, Zertifikate, Cache-Regeln.
Mindesttests:
„Bash curl --http3-only -sI https://example.com | Kopf -5
Vergleichen Sie „--http2“ und „--http1.1“ auf derselben statischen Ressource.
## Der Gipfel: Optimieren Sie das Protokoll vor der Anwendung
:::Höhepunkt
**HTTP/3 ist eine Transportoptimierung für eine bereits gesunde Pipeline.** Die Aktivierung von QUIC auf einer Website, deren Warenkorb auf der PHP-Seite 1,2 Sekunden benötigt, um generiert zu werden, ist wie das Polieren der Karosserie eines Autos ohne Motor. „No-Win“-Audits nach der H3-Migration verbergen fast immer einen unbehandelten Ursprung.
:::
CDN-Marketing liebt den Begriff „HTTP/3-ready“. Es ersetzt nicht OPcache, SQL-Indizes oder Bildkomprimierung.
## Entscheide dich und gehe ohne blinden Fleck voran
1. **Messung** des ursprünglichen TTFB und des aktuellen LCP.
2. **Fix** PHP, Cache, Assets, wenn TTFB > 600 ms oder LCP rot.
3. **HTTP/3 über CDN aktivieren**; Vergleichen Sie RUM Mobile 7 Tage.
4. **Dokument** Edge vs. Origin-Protokoll zur Unterstützung.
Vergleichen Sie kompatible Hosts und CDNs über das [Verzeichnis](/de/verzeichnis/) und den [Vergleich](/de/vergleich/).
## Häufig gestellte Fragen
### Ist HTTP/3 im Jahr 2026 obligatorisch?
Nein – priorisieren Sie TTFB und Inhalte vor QUIC, wenn der Server den Engpass darstellt.
### Mein gemeinsam genutzter Anbieter bietet HTTP/3 an: Soll ich es aktivieren?
Ja, ohne Risiko mit Maß umschalten; Nein, wenn dies eine echte Originaldiagnose vermeidet.
### HTTP/3 ohne CDN?
Ursprünglich möglich (Nginx/Caddy), aber in der Praxis selten – die meisten verwenden Edge-CDN.
### Wie teste ich HTTP/3?
DevTools Protocol h3 oder curl --http3-only; vergleiche mit h2.
---
Bevor wir HTTP/3 feiern, eine Frage: *Ist das ursprüngliche TTFB schon grün?* Ansonsten beschleunigen Sie hauptsächlich eine PHP-Warteschlange – nicht das Netzwerk.