Das Team verkettet weitere dreißig JavaScript-Dateien „wegen HTTP/1“ – obwohl Nginx bereits seit zwei Jahren HTTP/2 bereitstellt. Das monolithische Bundle unterbricht den Cache bei jedem Patch. Gleichzeitig verteilt ein anderes Projekt seine Assets auf „static1“, „static2“, „static3“: drei TLS-Handshakes, Multiplexing wird durch von HTTP/1 geerbte Gewohnheiten aufgehoben.
HTTP/2 multiplext mehrere Anfragen über eine einzige TCP/TLS-Verbindung. Keine HTTP/1.1-Warteschlange mit sechs parallelen Slots mehr – aber keine JavaScript-Renderblockierung und keine Vier-Megabyte-Bilder mehr. Um Multiplexing zu verstehen, muss man wissen, was es reguliert und was es intakt lässt.
Multiplexing: Was sich tatsächlich ändert
Unter HTTP/1.1 beschränkten Browser parallele Verbindungen zur gleichen Domäne – daher Domänen-Sharding, CSS-Sprites und Dateiverkettung. HTTP/2 öffnet unabhängige Streams auf einer einzelnen Verbindung mit HPACK-Header-Komprimierung.
| Praktisches HTTP/1 | Unter HTTP/2 |
|---|---|
| Domain-Sharding | Kontraproduktiv |
| CSS-Sprites | Weniger notwendig |
| Großes Einzelpaket | Module + Cache nach Hash |
| Sechs Keep-Alive-Verbindungen | Eine reiche Verbindung |
Multiplexing beschleunigt den Transport – nicht die Dateigröße** oder die JavaScript-Ausführungsreihenfolge.
Eine Site, die zwölf synchrone Skripte in den „<head>“ lädt, bleibt langsam, ob HTTP/2 oder nicht. Die Netzwerkbeschränkung hat sich geändert; Die Einschränkung des kritischen Rendering-Pfads bleibt bestehen.
Priorisierung, Blockierung an der Spitze und Grenzen
HTTP/2 litt unter der Head-of-Queue-Blockierung auf TCP-Ebene: Der Verlust eines Pakets blockierte alle Streams. HTTP/3 (QUIC) verbessert diesen Punkt gegenüber UDP. In der Praxis bleibt die Reduzierung der Anzahl synchroner Skripte im „<head>“ wirkungsvoller als die Optimierung der Stream-Prioritäten auf der Nginx-Seite.
Stream-Prioritäten zwischen Browser und Server haben im Vergleich zur Optimierung des LCP-Images oder dem Zurückstellen nicht unbedingt erforderlichen JavaScripts nur einen bescheidenen tatsächlichen Effekt. Messen Sie LCP, TBT und INP – nicht nur das Protokoll in Antwortheadern.
CDN, TLS-Terminierung und -Ursprung
Die HTTP/2-Terminierung am CDN (Cloudflare usw.) zu einem HTTP/1.1-Ursprung bleibt sehr verbreitet: Der Client profitiert vom Multiplexing, der Ursprung unterhält einen einfacheren Stack. Überprüfen Sie die ALPN-Aushandlung mit:
„Bash curl -I --http2 https://your-site.example
Bei Shared Hosting ohne natives HTTP/2 reicht oft ein kostenloses CDN vor dem Ursprung aus. Vergleichen Sie Angebote über unser [Verzeichnis](/de/verzeichnis/) – die Unterstützung von ALPN „h2“ hängt vom Webserver und dem Zertifikat ab, nicht nur von einem Kästchen im Panel.
Der HTTP/2-Server-Push ist weitgehend veraltet: Chrome hat ihn entfernt und das Vorladen über „<link rel="preload">“ bietet eine feinere Kontrolle, ohne Bandbreite für bereits zwischengespeicherte Ressourcen zu verschwenden.
## HTTP/3 und schrittweise Migration
HTTP/3 basiert auf QUIC (UDP) und verbessert die Leistung in Mobilfunknetzen mit Paketverlusten. Die Aktivierung erfolgt schrittweise auf der CDN-Seite – Cloudflare, Fastly und andere aktivieren sie ohne Neugestaltung der Anwendung. Ihr PHP- oder Node.js-Code muss nicht geändert werden. Es ist die Netzwerkschicht, die sich entwickelt.
Entfernen Sie zunächst schädlich gewordene HTTP/1-Praktiken: Domain-Sharding, monolithische Bundles, unnötige Sprites. Aktivieren Sie als Nächstes HTTP/3, wenn Ihr CDN dies anbietet – es ist ein Bonus, keine Voraussetzung.
## Checkliste nach der HTTP/2-Aktivierung
– Entfernen Sie das Domain-Sharding für statische Assets.
- Teilen Sie die Bundles logisch auf (nach Route oder Funktionalität).
- Laden Sie das LCP-Image vorab, verzögern oder asynchronisieren Sie das nicht kritische JavaScript.
- Behalten Sie die Brotli- oder gzip-Komprimierung bei – HTTP/2 komprimiert keine Antworttexte.
- Richten Sie die [Cache-Header](/de/blog/http-cache-headers/) so aus, dass der Netzwerkgewinn nicht durch übermäßige Neuvalidierungen zunichte gemacht wird.
## Der Gipfel: HTTP/2-Abzeichen, Website immer noch langsam
Folgendes garantiert das in den DevTools angezeigte Protokoll nicht.
:::Höhepunkt
**Die Aktivierung von HTTP/2 auf einem Remote-Ursprung mit zwei Megabyte synchronem JavaScript verändert das wahrnehmbare Erlebnis nicht.** Durch Multiplexing wurde eine HTTP/1-Einschränkung entfernt – keine schlechten Ladeprioritäten. Messen Sie LCP und TBT, nicht nur „h2“ in Antwortheadern.
:::
Multiplexing zu verstehen bedeutet, mit der Optimierung für HTTP/1 aufzuhören und gleichzeitig mit der Optimierung von Inhalten und kritischen Pfaden fortzufahren.
## Entscheide dich und gehe ohne blinden Fleck voran
Prüfen Sie einen halben Tag lang, ob HTTP/2 einen echten Gewinn bringt:
1. **Bestätigen**, dass HTTP/2 auf der Clientseite aktiv ist („curl --http2“ oder Registerkarte „Protokoll“ in DevTools).
2. Domain-Sharding auf Assets **entfernen** – LCP vorher und nachher messen.
3. **Ersetzen** Sie das monolithische Bundle durch sinnvolle Module mit Hash im Namen.
4. **Aktivieren** Sie HTTP/3 über das CDN, sofern verfügbar, ohne auf eine Neugestaltung der Anwendung zu warten.
5. **Vergleichen** Sie Hosts mit TLS und HTTP/2 über das [Verzeichnis](/de/verzeichnis/) und den [Vergleich](/de/vergleich/).
Wenn die Site nach HTTP/2 weiterhin langsam bleibt, liegt der Engpass woanders – Bilder, JavaScript, Datenbank. Der [technische Blog](/de/blog/) bietet zusätzliche Anleitungen zu Caching und Bildformaten.
## Häufig gestellte Fragen
### Macht HTTP/2 Domain-Sharding nutzlos?
Ja, grundsätzlich. Eine Multiplexverbindung bedient mehrere Dateien, ohne neue TCP/TLS-Verbindungen zu öffnen. Sharding führt zu teuren Handshakes und macht häufig die Vorteile des Multiplexings zunichte. Behalten Sie einen sauberen HTTP/2-Ursprung oder CDN bei.
### Müssen wir CSS/JS noch verketten?
Weniger als HTTP/1.1, aber ein riesiges Paket, das eine schlechte Cache-Granularität aufweist: Jede Änderung macht die gesamte Datei ungültig. Streben Sie nach vernünftigen Modulen, nicht nach vierzig nicht zwischengespeicherten Mikrodateien.
### Ist Server-Push HTTP/2 sinnvoll?
Größtenteils nein. Chrome hat die Unterstützung entfernt und das Vorladen über das Tag „<link>“ bietet eine feinere Kontrolle. Konfigurieren Sie Nginx Push nicht, ohne die Auswirkungen auf die Bandbreite zu messen.
### HTTP/2 erfordert überall was auf der Hostseite?
TLS mit ALPN „h2“, gültigem Zertifikat, aktuellem Webserver (Nginx, Apache, Caddy) oder CDN, das HTTP/2 beendet. Überprüfen Sie bei Shared die Unterstützung im Panel. Andernfalls platzieren Sie ein CDN vor einem HTTP/1.1-Ursprung.
---
HTTP/2 legt die Netzwerkwarteschlange fest – nicht die JavaScript-Warteschlange.