HTTP/2, HTTP/3 und warum Ihr TTFB langsam ist — Smart SEO Audit

01 Warum das Protokoll wichtig ist

Wenn Ihre Website langsam lädt, ist der erste Impuls meist: Bilder optimieren, JavaScript zurückstellen oder Hosting upgraden. Alles sinnvoll. Aber der größte einzelne Performance-Gewinn auf den meisten Websites ist der, über den kaum jemand spricht: das HTTP-Protokoll upgraden.

HTTP/1.1 — das Protokoll, auf dem das Web zwei Jahrzehnte lang lief — hat strukturelle Grenzen, die kein Maß an Frontend-Optimierung beheben kann. Ein Upgrade auf HTTP/2 verkürzt die Seitenladezeit um 20–40% auf typischen Websites. HTTP/3 kürzt sie auf verlustreichen Mobilverbindungen weiter.

Stand 2026 liefern noch rund 30% der Websites über HTTP/1.1 aus. Das ist viel kostenlose Performance, die auf dem Tisch liegt.

02 HTTP/2 — Multiplexing verändert alles

Das Kernproblem von HTTP/1.1 ist das Head-of-Line-Blocking. Jede Verbindung kann nur eine Anfrage gleichzeitig bearbeiten. Als Workaround öffnen Browser sechs parallele Verbindungen pro Host — aber das bedeutet, dass Ressource #7 warten muss, bis #1, #2, #3, #4, #5 oder #6 fertig ist.

HTTP/2 führt Multiplexing ein: Eine einzige Verbindung trägt beliebig viele Anfragen parallel. Kein Queueing mehr, keine „Domain-Sharding"-Hacks (die HTTP/2-Performance aktiv schaden). Der Browser stellt alle Anfragen auf einmal aus, und der Server streamt Antworten zurück, sobald sie verfügbar sind.

Weitere große HTTP/2-Vorteile:

• Header-Komprimierung (HPACK). HTTP-Header, die bei jeder Anfrage gesendet werden, sind hochredundant. HPACK komprimiert sie und spart bedeutsame Bytes pro Anfrage.
• Binäres Framing. Effizienteres Parsing als das textbasierte Protokoll von HTTP/1.1.
• Server Push (in der Praxis in Chrome als deprecated markiert — Preload-Links werden jetzt bevorzugt).

03 HTTP/3 — und QUIC unter der Haube

HTTP/3 treibt die Multiplexing-Idee weiter, indem es den zugrunde liegenden Transport von TCP auf QUIC (das über UDP läuft) umstellt.

Warum ist das wichtig? Weil TCP ebenfalls Head-of-Line-Blocking hat — aber auf der Transport-Schicht. Wenn ein einzelnes Paket bei einer HTTP/2-Verbindung verloren geht, stockt die gesamte Verbindung, bis das Paket erneut übertragen wurde — obwohl logischerweise nur einer der gemultiplexten Streams betroffen ist.

QUIC behebt dies, indem jeder gemultiplexte Stream als separater logischer Kanal läuft. Ein verlorenes Paket betrifft nur seinen eigenen Stream; die anderen laufen weiter.

Der praktische Impact: HTTP/3 ist bei verlustreichen Verbindungen dramatisch besser als HTTP/2 — Mobilnetze, überlastetes WLAN, transatlantische Verbindungen. Auf einer Hochqualitätsverbindung ist der Unterschied gering. Aber auf den Verbindungen, die die meisten Ihrer Nutzer tatsächlich nutzen, ist er erheblich.

Weitere HTTP/3-Vorteile:

• 0-RTT-Verbindungsaufbau für Wiederholungsbesuche — spart einen Round-Trip bei jedem Seitenaufruf nach dem ersten.
• Verbindungsmigration — Ihre Verbindung überlebt einen Netzwerkwechsel (WLAN zu LTE), statt zu sterben.

04 TTFB und was ihn beeinflusst

Time to First Byte (TTFB) ist die Zeit zwischen dem Senden der Anfrage durch den Browser und dem Empfang des ersten Bytes der Antwort. Es ist das Fundament unter allem anderen — wenn TTFB langsam ist, werden alle anderen Metriken um diesen Betrag verzögert.

Was TTFB kontrolliert:

• Netzwerkdistanz — die Round-Trip-Zeit zwischen Nutzer und Server. CDN verwenden.
• Server-Antwortzeit — wie lange Ihre Anwendung braucht, um die Antwort zu generieren. Aggressiv cachen.
• Protokoll — 0-RTT von HTTP/3 vs. 1-RTT von HTTP/2 vs. mehrere Round-Trips von HTTP/1.1.
• Verbindungswiederverwendung — etablierte TLS-Verbindungen überspringen den Handshake bei nachfolgenden Anfragen.

Ein „guter" TTFB liegt beim 75. Perzentil unter 200ms. Viele Websites liegen bei 800ms+, weil sie ungecachtes PHP ausführen oder bei jeder Anfrage rendern — beides behebbar.

05 Wie man erkennt, was man verwendet

Der schnellste Check: Chrome DevTools öffnen, zum Netzwerk-Tab wechseln, mit Rechtsklick auf einen Spaltenheader die Spalte „Protokoll" aktivieren. Seite neu laden. Die Protokollspalte zeigt h2 (HTTP/2), h3 (HTTP/3) oder http/1.1 für jede Anfrage.

Wenn Sie http/1.1 für Ihre Haupt-HTML-Ressource sehen, wartet ein kostenloser Performance-Gewinn von 20–40% auf Sie.

Für automatisierte Erkennung: Smart SEO Audit markiert den HTTP/2- und HTTP/3-Status bei jedem Audit, sodass Sie erkennen, wenn eine Server-seitige Änderung einen Rückschritt verursacht hat.

06 HTTP/2 und HTTP/3 aktivieren

Die gute Nachricht: Die Aktivierung ist meist eine Konfigurationsänderung, kein Entwicklungsprojekt. Wo die Änderung stattfindet, hängt von Ihrem Stack ab:

• Hinter einem CDN (Cloudflare, Fastly, CloudFront): HTTP/2 ist standardmäßig aktiviert, HTTP/3 ist ein Toggle im Dashboard. Oft eine Fünf-Minuten-Änderung.
• Nginx: HTTP/2 in der Server-Direktive aktivieren: listen 443 ssl http2;. HTTP/3 erfordert eine neuere Nginx-Version und die QUIC-fähige Build.
• Apache: das mod_http2-Modul aktivieren und Protocols h2 http/1.1 in der VirtualHost-Konfiguration setzen.
• LiteSpeed: HTTP/3/QUIC ist standardmäßig aktiviert — nur QUIC-Listener in Ihrem LSWS-Listener aktivieren.
• Managed Hosting (WP Engine, Kinsta, Cloudways): Über das Control-Panel aktivieren oder den Support kontaktieren. Die meisten haben es bereits standardmäßig aktiviert.

? Häufige Fragen

Wie viel schneller ist HTTP/2 als HTTP/1.1?

Der Umstieg auf HTTP/2 senkt die Ladezeit auf einer typischen Seite meist um 20–40%, vor allem durch Multiplexing — eine einzige Verbindung trägt beliebig viele parallele Anfragen und beseitigt das Head-of-Line-Blocking von HTTP/1.1. 2026 laufen noch rund 30% der Seiten auf HTTP/1.1, also ein großer, kostenloser Performance-Gewinn.

Wann lohnt sich HTTP/3 gegenüber HTTP/2?

HTTP/3 läuft über QUIC statt TCP, sodass ein verlorenes Paket nur seinen eigenen Stream stoppt statt der ganzen Verbindung. Auf einer guten Verbindung ist der Unterschied klein, aber auf verlustbehafteten Verbindungen — Mobilfunk, überlastetes WLAN, transatlantische Strecken — ist er erheblich. Hinzu kommen 0-RTT für wiederkehrende Besuche und das Überleben von Netzwechseln.

Wie prüfe ich, welches HTTP-Protokoll meine Seite nutzt?

Öffnen Sie die Chrome DevTools, gehen Sie zum Network-Tab, aktivieren Sie per Rechtsklick auf eine Spaltenüberschrift die Spalte "Protocol" und laden Sie neu. Pro Anfrage erscheint h2, h3 oder http/1.1. Zeigt Ihre Haupt-HTML-Ressource http/1.1, wartet ein 20–40%-Upgrade — meist eine Konfigänderung hinter einem CDN oder in nginx/Apache, kein Entwicklungsprojekt.

→ Verwandte Guides

Tiefer einsteigen — diese Guides behandeln verwandte Themen.