HTTP/2 verbessert die Übertragung durch mehrere Streams auf einer Verbindung und komprimierte Header. HTTP/3 verwendet QUIC, das Verluste eines Streams stärker von anderen isolieren und Verbindungswechsel unterstützen kann. Ein neueres Protokoll entfernt jedoch weder Anwendungsarbeit noch große Ressourcen oder Rendering. Prüfen Sie die tatsächlich ausgehandelte Version und messen Sie relevante Nutzerwege.
Erkennen Sie die Grenzen von HTTP/1.1
HTTP-Semantik beschreibt Methoden, Statuscodes, Header und Ressourcen. Der Transport bestimmt deren Übertragung. HTTP/2 oder HTTP/3 verändert keine GET-Operation und macht Antworten nicht automatisch cachebar. Untersuchen Sie Protokoll- und Cache-Änderungen deshalb getrennt.
HTTP/1.1 unterstützt dauerhafte Verbindungen, erlaubt im üblichen Browserbetrieb aber kein freies Verschachteln von Antworten auf einer Verbindung. Pipelining hat Reihenfolgeprobleme und wurde keine praktikable allgemeine Browserlösung. Deshalb verwenden Browser mehrere Verbindungen mit implementierungsabhängigen Grenzen. Zusätzliche Verbindungen benötigen Aufbau und konkurrieren um Netzwerkressourcen.
Das begünstigte zusammengefasste Dateien und mehrere Asset-Hostnamen. Manchmal verkürzte dies Wartezeiten, erzeugte aber große Bundles, DNS-Arbeit und Verbindungsaufbau. Moderne Protokolle verschieben die Abwägung, ohne jede frühere Optimierung automatisch überflüssig zu machen.
Der Leitfaden zur Serverantwortzeit trennt Verbindungswartezeit von Anwendungswartezeit. Dominiert HTML-Erzeugung, kann der größte Engpass trotz neuem Transport nahezu unverändert bleiben.
Verstehen Sie HTTP/2-Multiplexing
HTTP/2 zerlegt Nachrichten in binäre Frames auf Streams. Mehrere Streams teilen eine TCP-Verbindung und können fortschreiten, ohne das Ende jeder vollständigen Antwort abzuwarten. HPACK komprimiert Headerfelder und reduziert wiederholten Headeraufwand.
Multiplexing liefert keine unbegrenzte Bandbreite. Streams konkurrieren um Kapazität und hängen von Scheduling und Flusskontrolle ab. Sofortige Anfragen aller optionalen Ressourcen können kritische Bilder oder Stylesheets verdrängen. Ressourcenerkennung und Priorisierung bleiben wichtig, auch wenn die Verbindungswarteschlangen anders aussehen.
HTTP/2 behält TCPs geordneten Bytestrom. Verlorene Pakete hinterlassen Lücken, die vor geordneter Auslieferung späterer Bytes geschlossen werden müssen. Das kann unabhängige HTTP-Streams verzögern. Dieses Head-of-Line-Blocking des Transports unterscheidet sich von der Antwortreihenfolge in HTTP/1.1 und erklärt einen möglichen HTTP/3-Vorteil.
Server Push gehört zur HTTP/2-Geschichte, ist aber keine allgemeine moderne Browseroptimierung, auf die Sie bauen sollten. Es ersetzt keine klare Ressourcenerkennung. Prüfen Sie reale Browser- und Serverunterstützung und verwenden Sie unterstützte Lademechanismen für kritische Ressourcen.
Ordnen Sie QUIC und HTTP/3 ein
HTTP/3 bildet HTTP auf QUIC ab, einen sicheren multiplexierten Transport über UDP-Datagramme. QUIC liefert zuverlässige Streams, Verlustbehebung und Überlastkontrolle. UDP bedeutet also nicht, dass Webseitenbytes unrepariert verloren gehen. Verschlüsselung ist in den Verbindungsaufbau integriert.
Ein Verlust in einem Stream zwingt andere Streams nicht auf dieselbe Weise zum Warten wie HTTP/2 über TCP. Gemeinsame Überlastkontrolle, Kapazität und Protokollabhängigkeiten bleiben bestehen. HTTP/3 beseitigt deshalb nicht jede Blockierung und ist nicht grundsätzlich auf jedem verlustbehafteten Netz schneller.
QUIC-Verbindungskennungen können einen Pfadwechsel überstehen, abhängig von Endpunktunterstützung und Pfadvalidierung. Der Wechsel zwischen WLAN und Mobilfunk ist ein sinnvoller Testfall, keine universelle Kontinuitätsgarantie. Manche Netze blockieren oder beschränken UDP, weshalb Rückfallverhalten wichtig bleibt.
Wiederaufgenommene Verbindungen können frühe Daten, oft 0-RTT genannt, unterstützen. Das gilt nicht für jeden Erstbesuch. Wiederholungsangriffe erfordern Schutz in Server und Anwendung. Aktivieren Sie frühe Daten nicht unkritisch für Kontoveränderungen oder Zahlungen. Ein erfolgreicher HTTP/3-Rollout braucht nicht jede optionale Funktion.
Die Protokolle unterscheiden sich in diesen Eigenschaften.
| Eigenschaft | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Üblicher Browsertransport | TCP, bei HTTPS mit TLS | TCP mit TLS | QUIC über UDP |
| Parallele Antworten auf einer Verbindung | Durch Antwortreihenfolge begrenzt | Multiplexierte Streams | Multiplexierte QUIC-Streams |
| Headerkomprimierung | Kein HPACK oder QPACK | HPACK | QPACK |
| Verlustisolation | TCP-Reihenfolge gilt | TCP kann sämtliche Streams verzögern | Unabhängigere Stream-Auslieferung |
| Anwendungsengpässe | Bleiben | Bleiben | Bleiben |
Prüfen Sie das ausgehandelte Browserprotokoll
Aktivieren Sie im Network-Panel der Chrome DevTools die Spalte Protocol über das Tabellenkopfmenü. Laden Sie neu und betrachten Sie Dokument sowie wichtige Ressourcen einzeln. h2 oder h3 beschreiben die jeweilige Anfrage. Verschiedene Ursprünge einer Seite können unterschiedliche Protokolle verwenden.
Terminiert ein CDN die Verbindung, beschreibt die Spalte Browser zu Edge. Zum Ursprung kann das CDN eine andere Version verwenden. Ein h3-Dokument beweist keine HTTP/3-Unterstützung des Ursprungsservers. Ein älterer Ursprungstransport hebt umgekehrt nicht jeden Vorteil der Besucherstrecke auf. Der CDN- und Edge-Caching-Leitfaden erläutert diese Trennung.
HTTP/3 kann durch Alt-Svc oder unterstützte DNS-Verfahren entdeckt werden. Erste und spätere Anfragen können sich unterscheiden. Bestehende Verbindungen, gespeicherte Ankündigungen, Zertifikate und blockiertes UDP beeinflussen das Ergebnis. Dokumentieren Sie, ob eine neue Verbindung verwendet wurde.
Prüfen Sie vor curl-Aufrufen dessen Build-Fähigkeiten, da nicht jede Installation HTTP/3 unterstützt.
curl --version
curl --http2 -sS -o /dev/null -w '%{http_version}\n' https://example.com/
curl --http3-only -sS -o /dev/null -w '%{http_version}\n' https://example.com/Der reine HTTP/3-Aufruf verhindert absichtlich Fallback und zeigt mögliche Verbindungs- oder Unterstützungsfehler. Er ist eine Diagnose, keine vollständige Browsersimulation. Die ausgegebene Version zählt mehr als die Annahme, eine angeforderte Option garantiere die Aushandlung.
Aktivieren Sie die kontrollierbare Ebene
Beginnen Sie bei Managed Hosting oder CDN mit aktueller Dokumentation und Verwaltungsoberfläche. Prüfen Sie betroffenen Hostnamen und Verbindungsschritt, gültiges Zertifikat, Ursprungsverbindung und HTTP/2-Fallback. Ein aktivierter Schalter und eine tatsächliche h3-Anfrage sind unterschiedliche Nachweise.
Apache HTTP Server 2.4 mit geladenem mod_http2 dokumentiert Protocols. Ein TLS-Virtual-Host kann HTTP/2 mit HTTP/1.1-Fallback so anbieten.
Protocols h2 http/1.1Erhalten Sie bestehende TLS- und Zertifikatseinstellungen. Aus mod_http2 folgt keine HTTP/3-Unterstützung. Prüfen Sie Serverpaket und unterstütztes Frontend, bevor Sie die Terminierung wählen.
Die eigenständige Nginx-Direktive http2 on gibt es seit 1.25.1. HTTP/3 benötigt das HTTP/3-Modul und eine kompatible TLS-Bibliothek; die Dokumentation bezeichnet das Modul als experimentell. Diese Zeilen gehören in einen vorhandenen TLS-Serverblock mit gültigen Zertifikaten und erforderlichen Modulen.
Das Fragment aktiviert TCP-HTTPS und QUIC auf derselben Portnummer mit unterschiedlichen Transporten.
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';Integrieren Sie vorhandene Listener, statt sie zu duplizieren, besonders bei gemeinsam genutzten Adressen. Prüfen Sie Headervererbung vor add_header. Erlauben Sie UDP 443 durch Firewalls und Loadbalancer und erhalten Sie TCP 443. Die Ankündigungsdauer ist ein Beispiel und beweist keine QUIC-Erreichbarkeit.
Prüfen Sie mit nginx -t und anschließend von außen. Build-Optionen, TLS und Early-Data-Unterstützung variieren; verwenden Sie die Dokumentation der installierten Version. Weder das Fragment noch eine Syntaxprüfung ersetzt eine vollständige Sicherheitskonfiguration.
Bewerten Sie Sharding, Sprites und große Bundles neu
Domain Sharding verteilt Dateien auf Hostnamen für zusätzliche Parallelverbindungen. Bei Multiplexing kann es unnötige DNS- und Verbindungsarbeit verursachen und Wiederverwendung mindern. Konsolidieren Sie erst nach Prüfung von Zertifikaten, Caching, Prioritäten und Seitenverhalten. Mögliches Connection Coalescing macht beliebige Hostnamen nicht kostenlos.
Sprites bündeln Bilder und können in bestimmten Designs sinnvoll sein. Große Sprites laden aber möglicherweise ungenutzte Pixel und invalidieren bei Änderungen unbeteiligte Inhalte. Ein einziges großes JavaScript-Bundle kann Anfragen sparen, aber jede Route mit unbenötigten Funktionen belasten.
Vermeiden Sie auch zahllose winzige Dateien: Anfragen, Header, Komprimierung und Abhängigkeiten kosten weiterhin. Nutzen Sie sinnvolle Funktionsgrenzen und vergleichen Start mit Wiederholungsnavigation. Der Browser-Caching-Leitfaden erklärt den Einfluss stabiler Fingerprint-Dateien.
Messen Sie mehr als einen schnellen Reload
Vergleichen Sie repräsentative Geräte und Netze bei gleichen Ressourcen, Cachezuständen und Serverbedingungen. Prüfen Sie neue und wiederaufgenommene Verbindungen, Wiederholungsbesuche und einen Weg ohne HTTP/3. Erfassen Sie das ausgehandelte Protokoll statt nur die gewünschte Einstellung.
Messen Sie Verbindungsaufbau, TTFB, kritische Ressourcen und sichtbare Nutzerleistung. Ändern Sie CDN-Routing, Komprimierung, Caching und Protokoll nicht gleichzeitig, wenn Sie Ursachen zuordnen möchten. Ein warmer Cache oder anderer Edge kann sonst wie ein Protokollgewinn wirken.
Dokumentieren Sie Einstellungen und Fallback im Performance-Check. Vertiefung bieten die Sammlung zur Serverleistung und die HTTP/3-Spezifikation. Behalten Sie den Rollout bei, wenn unterstützte Nutzerwege zuverlässig bleiben und Messungen den Nutzen tragen, auch unterhalb theoretischer Erwartungen.
