HTTP/2

HTTP/2 ist die zweite Hauptversion des Hypertext Transfer Protocol, des Protokolls, über das Browser und Server im Web Daten austauschen. Es wurde 2015 als RFC 7540 offiziell standardisiert und basiert auf dem zuvor von Google entwickelten SPDY-Protokoll. HTTP/2 löst den langjährigen Standard HTTP/1.1 ab und verbessert vor allem Geschwindigkeit und Effizienz der Datenübertragung. Der wichtigste Unterschied ist das Multiplexing, bei dem mehrere Anfragen und Antworten gleichzeitig über eine einzige Verbindung laufen. In der Praxis benötigt HTTP/2 eine verschlüsselte HTTPS-Verbindung, da alle gängigen Browser es nur über TLS unterstützen.

Der zentrale Unterschied ist das Multiplexing. HTTP/2 kann mehrere Anfragen und Antworten gleichzeitig über eine einzige Verbindung senden, während HTTP/1.1 Anfragen im Kern nacheinander oder über mehrere separate Verbindungen abarbeiten muss. Zudem nutzt HTTP/2 ein binäres statt eines textbasierten Protokolls, komprimiert die HTTP-Header mit dem HPACK-Algorithmus und erlaubt es, Datenströmen Prioritäten zuzuweisen. Dadurch entfällt das Head-of-Line-Blocking auf der HTTP-Ebene, und Webseiten mit vielen Ressourcen laden deutlich schneller, besonders auf Verbindungen mit höherer Latenz.

Ja, in der Praxis ist HTTPS für HTTP/2 zwingend erforderlich. Die HTTP/2-Spezifikation erlaubt zwar theoretisch auch einen unverschlüsselten Modus namens h2c, doch alle gängigen Browser unterstützen HTTP/2 ausschließlich über verschlüsselte HTTPS-Verbindungen. Sie benötigen daher ein gültiges SSL- beziehungsweise TLS-Zertifikat für Ihre Website. Kostenlose Zertifikate von Let’s Encrypt sind dafür völlig ausreichend und werden von allen Browsern akzeptiert. Ohne gültiges Zertifikat lässt sich keine HTTP/2-Verbindung aushandeln, und der Server fällt auf HTTP/1.1 zurück.

Multiplexing ist die Kernfunktion von HTTP/2. Es erlaubt, viele Anfragen und Antworten gleichzeitig als sogenannte Streams über eine einzige TCP-Verbindung zu übertragen. Bei HTTP/1.1 musste jede Ressource nacheinander geladen werden oder es waren mehrere parallele Verbindungen nötig, wobei eine langsame Anfrage die folgenden blockieren konnte, das sogenannte Head-of-Line-Blocking. Mit Multiplexing entfällt diese Blockade auf der HTTP-Ebene, alle Ressourcen einer Seite werden parallel geladen. Das reduziert die Ladezeit erheblich, vor allem bei Seiten mit vielen Dateien wie CSS, JavaScript und Bildern.

Nein, Server Push gilt heute als gescheitert. Die Funktion sollte es dem Server erlauben, Ressourcen proaktiv an den Browser zu senden, bevor dieser sie anfordert. Das Problem war, dass der Server nicht weiß, ob der Browser eine Ressource bereits im Cache hat, wodurch Server Push häufig Bandbreite verschwendete und kaum messbare Vorteile brachte. Die Nutzung blieb verschwindend gering. Google deaktivierte Server Push ab Chrome 106 im Jahr 2022, Mozilla entfernte ihn 2024 mit Firefox 132, und auch aus nginx wurde er entfernt. Als Ersatz dienen heute der Statuscode 103 Early Hints und das rel-preload-Attribut.

HTTP/2 selbst ist kein direkter Rankingfaktor, aber es verbessert die Ladegeschwindigkeit, und die ist seit Langem ein Faktor. Google machte die Seitengeschwindigkeit 2010 zum Faktor für die Desktop-Suche und 2018 mit dem Speed Update auch für die mobile Suche. Seit 2021 fließen zusätzlich die Core Web Vitals in die Bewertung ein. Schnellere Ladezeiten durch HTTP/2 wirken sich positiv auf diese Werte aus. Außerdem können Suchmaschinen-Bots Websites mit HTTP/2 effizienter crawlen, da weniger Verbindungen nötig sind. Der Nutzen von HTTP/2 für SEO ist also real, aber indirekt.

Die Core Web Vitals sind eine Gruppe von Messwerten, mit denen Google die Nutzererfahrung einer Seite bewertet, und die seit 2021 ins Ranking einfließen. Dazu zählen heute Largest Contentful Paint für die Ladewahrnehmung, Cumulative Layout Shift für die visuelle Stabilität und seit März 2024 Interaction to Next Paint für die Reaktionsschnelligkeit, das den früheren Wert First Input Delay abgelöst hat. HTTP/2 beschleunigt das Laden von Ressourcen und wirkt sich dadurch positiv vor allem auf den Largest Contentful Paint aus. Es ist damit ein Baustein, um gute Core-Web-Vitals-Werte zu erreichen.

Am einfachsten geht das über die Entwicklertools des Browsers. Öffnen Sie diese mit F12, wechseln Sie zum Netzwerk-Tab und laden Sie die Seite neu. In der Spalte Protocol erscheint dann der Wert h2 für HTTP/2. Alternativ zeigen Online-Werkzeuge sowie Crawler wie Screaming Frog und Performance-Tools wie Lighthouse oder GTmetrix das verwendete Protokoll an. Die meisten modernen Hosting-Anbieter aktivieren HTTP/2 automatisch, sobald HTTPS eingerichtet ist. Erscheint weiterhin nur HTTP/1.1, fehlt häufig ein gültiges Zertifikat oder der Webserver ist zu alt.

Meist sind keine direkten Anpassungen am Content-Management-System nötig, denn HTTP/2 ist hauptsächlich eine serverseitige Technologie. Allerdings sollten Sie veraltete Optimierungen aus der HTTP/1.1-Zeit entfernen, da diese mit HTTP/2 kontraproduktiv sind. Dazu zählen Domain Sharding, also das Verteilen von Ressourcen auf mehrere Domains, das übermäßige Zusammenfassen vieler CSS- und JavaScript-Dateien sowie Image Sprites. Solche Techniken untergraben die Vorteile des Multiplexing oder entwerten bei kleinen Änderungen den gesamten Cache. Prüfen Sie außerdem Ihre Caching- und CDN-Einstellungen auf HTTP/2-Unterstützung.

HTTP/3 ist der Nachfolger von HTTP/2 und wurde 2022 als RFC 9114 standardisiert. Der größte Unterschied liegt im Transportprotokoll: Während HTTP/2 auf TCP aufsetzt, basiert HTTP/3 auf dem QUIC-Protokoll, das UDP verwendet. Dadurch beschleunigt HTTP/3 den Verbindungsaufbau, übersteht den Wechsel des Netzwerks ohne Abbruch und beseitigt vor allem das TCP-bedingte Head-of-Line-Blocking, das HTTP/2 auf der Transportebene noch hatte. Gerade in instabilen Mobilfunknetzen ist HTTP/3 dadurch im Vorteil. Große Anbieter wie Google, Cloudflare und Meta setzen HTTP/3 bereits breit ein.