Viele Unternehmenswebsites tragen Tempo-Kniffe mit sich, die aus der Zeit von HTTP/1.1 stammen: Bilder auf mehrere Subdomains verteilt, ein großes Skriptpaket für alle Seiten, Symbole in einer Sprite-Grafik, kleine Bilder als Data-URI direkt im Stylesheet. Damals holte jede dieser Maßnahmen messbar Zeit heraus. Heute spricht der Server in aller Regel HTTP/2, und dieselben Kniffe kosten zusätzliche DNS-Abfragen und Verbindungsaufbauten, sie hebeln die Priorisierung aus und schwächen den Cache. Dieser Beitrag ist eine Rückbau-Liste: welche Maßnahmen von damals heute bremsen, woran Sie sie im Wasserfall erkennen, in welcher Reihenfolge Sie sie ohne Risiko abbauen – und wann eine Seite doch noch über HTTP/1.1 ausgeliefert wird, etwa hinter einem alten Proxy.
Das Wichtigste in Kürze
- Unter HTTP/1.1 öffnen Browser heute in der Regel 6 parallele Verbindungen (MDN Web Docs) je Domain. Domain-Sharding vervielfachte diese Zahl – unter HTTP/2 bringt es nur noch zusätzliche Verbindungsaufbauten.
- HTTP/2 bündelt alle Anfragen einer Seite in einer Verbindung je Host und Port (IETF RFC 9113). Nur innerhalb dieser Verbindung kann der Browser Dateien sinnvoll gegeneinander priorisieren.
- Große Sammeldateien und Sprites verlieren bei jeder Änderung den ganzen Cache. Unter HTTP/2 sind mehrere kleinere Dateien, die sich unabhängig voneinander ändern, in der Regel die bessere Wahl.
- Die Base64-Kodierung macht Data-URIs rund ein Drittel (MDN Web Docs) größer, und die eingebetteten Bytes lassen sich weder getrennt cachen noch vom Browser abbestellen.
- Server Push ist seit Chrome 106 (Chrome for Developers) abgeschaltet. Noch gesetzte Push-Anweisungen laufen ins Leere; den Zweck übernehmen preload und 103 Early Hints.
- Vor jedem Rückbau steht die Gegenprobe: Ohne CDN liefen 2024 noch bis zu 29 Prozent (HTTP Archive Web Almanac 2024) der Anfragen über HTTP/1.1, etwa hinter alten Proxys.
Warum die Kniffe von damals einmal richtig waren
Unter HTTP/1.1 kann eine Verbindung zur selben Zeit nur eine Anfrage bearbeiten. Die nächste Datei wartet, bis die vorige vollständig übertragen ist. Browser behelfen sich damit, mehrere Verbindungen parallel zu öffnen: Früher waren es 2 bis 3 (MDN Web Docs), heute sind 6 parallele Verbindungen (MDN Web Docs) je Domain üblich. Für Seiten mit vielen Dateien war das ein Engpass – und genau dort setzte Domain-Sharding an. Wer seine Dateien auf drei Subdomains verteilte, kam im Beispiel von MDN auf 18 Verbindungen (MDN Web Docs) statt 6, weil der Browser jede Subdomain als eigene Domain behandelt.
Aus derselben Not entstand der übrige Werkzeugkasten jener Jahre. Sammeldateien fassten alle Skripte und Stylesheets zu je einer Datei zusammen, weil jede Anfrage einen Platz in der knappen Warteschlange kostete. Sprites legten Dutzende Symbole in eine einzige Grafik, die per CSS-Ausschnitt angezeigt wurden. Data-URIs betteten kleine Bilder direkt ins Stylesheet ein, damit sie gar keine eigene Anfrage brauchten. Und cookiefreie Subdomains sparten den Cookie-Kopf, der unter HTTP/1.1 mit jeder Anfrage unkomprimiert mitreiste. Alle vier Maßnahmen lösten dasselbe Problem: zu viele Anfragen für zu wenige Verbindungen.
Mit HTTP/2 fällt dieses Problem weg, und die Umgehungen werden zur Last. Das HTTP/2-Kapitel von High Performance Browser Networking zählt Sammeldateien, Sprites und Domain-Sharding ausdrücklich zu den HTTP/1.x-Umgehungen, die sich entfernen lassen (High Performance Browser Networking). Der Rückbau ist deshalb kein Selbstzweck. Er räumt Hindernisse aus dem Weg, die sich über Jahre im Frontend angesammelt haben – oft ohne dass im Team noch jemand weiß, warum es sie gibt.
Wie verbreitet HTTP/1.1 noch ist
Was HTTP/2 grundlegend anders macht
HTTP/2 zerlegt jede Anfrage und jede Antwort in kleine Rahmen und verschränkt sie auf einer einzigen Verbindung. Das nennt sich Multiplexing: Stylesheet, Skript und Bilder laufen gleichzeitig, ohne aufeinander zu warten. Laut High Performance Browser Networking sind HTTP/2-Verbindungen deshalb dauerhaft, und es wird nur eine Verbindung je Origin (High Performance Browser Networking) benötigt. Die Spezifikation formuliert es als Regel für Browser: Sie sollen zu einem Host und Port nicht mehr als eine HTTP/2-Verbindung (IETF RFC 9113) öffnen. Die Felddaten spiegeln das wider: Im Median nutzte eine Desktop-Seite über HTTP/1.1 13 Verbindungen, über HTTP/2 und neuer 10 (HTTP Archive Web Almanac 2024). Weil jede Verbindung Handschläge, Speicher am Server und eine eigene Staukontrolle kostet, ist die kleinere Zahl laut Web Almanac schlicht effizienter.
Der zweite Unterschied ist die Priorisierung. Ein Protokoll, das viele Dateien über eine Leitung schickt, muss entscheiden können, was zuerst kommt – RFC 9218 nennt diese Fähigkeit ein wichtiges Merkmal jeder Umsetzung eines Protokolls mit Multiplexing (IETF RFC 9218). Das ursprüngliche Priorisierungsschema von HTTP/2 hat sich dabei nicht bewährt: Die überarbeitete Spezifikation RFC 9113 erklärt die Prioritätssignale aus RFC 7540 für veraltet (IETF RFC 9113, Abschnitt 5.3.2), RFC 9218 setzt ein einfacheres Schema an ihre Stelle. Für den Rückbau zählt vor allem eines: Priorisierung wirkt nur innerhalb einer Verbindung. Liegt das LCP-Bild auf img.example.com und das Stylesheet auf static1.example.com, konkurrieren zwei Verbindungen um dieselbe Bandbreite, und keine weiß von der anderen. Hinweise wie fetchpriority für das LCP-Bild greifen dann nur halb.
| Maßnahme aus der HTTP/1.1-Zeit | Wozu sie diente | Was sie unter HTTP/2 kostet | Was stattdessen |
|---|---|---|---|
| Domain-Sharding (static1, static2, img) | mehr parallele Verbindungen | zusätzliche DNS-Abfragen und Verbindungsaufbauten, getrennte Priorisierung | alle Dateien auf einem Host oder auf Hosts mit gemeinsamem Zertifikat |
| Sammeldatei für alle Seiten | weniger Anfragen | jede Änderung leert den Cache der ganzen Datei, ungenutzter Code lädt mit | mehrere Dateien nach Änderungshäufigkeit und Seitentyp |
| CSS-Sprite | weniger Bildanfragen | alle Symbole laden, auch ungenutzte; eine Änderung erneuert die ganze Grafik | einzelne SVG-Dateien oder SVG im HTML für wenige Symbole |
| Data-URI im Stylesheet | keine eigene Anfrage | rund ein Drittel mehr Bytes, verlängert das blockierende Stylesheet, kein eigener Cache | eigene kleine Datei mit langer Cache-Dauer |
| Cookiefreie Subdomain | Cookie-Kopf sparen | eigene Verbindung; HPACK komprimiert wiederholte Kopfzeilen ohnehin | Cookies schlank halten, statische Dateien auf demselben Host |
| Server Push | Dateien vor der Anfrage senden | in Chrome abgeschaltet, Push-Anweisungen wirkungslos | preload und 103 Early Hints |
Domain-Sharding: mehr Aufbau, weniger Ordnung
Unter HTTP/2 kehrt sich der Nutzen des Shardings um. Jeder zusätzliche Host kostet laut MDN eine eigene DNS-Abfrage und einen eigenen Verbindungsaufbau (MDN Web Docs), unter HTTPS dazu einen TLS-Handschlag. MDN rät deshalb ausdrücklich ab: Unter HTTP/2 bringe Domain-Sharding nichts mehr und schade der Leistung sogar (MDN Web Docs). Hinzu kommt, was die Verbindungen untereinander nicht teilen. Jede baut ihr Staufenster von vorn auf, jede führt eine eigene Kopfkompression, und der Browser kann Prioritäten nur innerhalb einer Verbindung setzen.
Browser versuchen, den Schaden zu begrenzen. Das Verfahren heißt Connection Coalescing: Zeigen zwei Hostnamen auf dieselbe Serveradresse und deckt das Zertifikat beide ab, verwendet der Browser die bestehende Verbindung weiter. Laut MDN nutzen die meisten HTTP/2-Umsetzungen dieses Verfahren, um Domain-Sharding rückgängig zu machen (MDN Web Docs), und der Web Almanac beschreibt, dass Browser bei gemeinsamem TLS-Zertifikat oft eine Verbindung für beide Domains verwenden (HTTP Archive Web Almanac 2024). Verlassen sollten Sie sich darauf trotzdem nicht. Die Spezifikation knüpft die Wiederverwendung bei HTTPS an ein Zertifikat, das für den Host in der Adresse gültig ist (IETF RFC 9113, Abschnitt 9.1.1). Hat static1 ein eigenes Zertifikat oder zeigt es auf eine andere IP-Adresse, entsteht die zweite Verbindung trotzdem – und die DNS-Abfrage fällt ohnehin an.
<!-- Vorher: Dateien auf drei Hosts verteilt -->
<link rel="stylesheet" href="https://static1.example.com/css/app.css">
<script src="https://static2.example.com/js/app.bundle.js" defer></script>
<img src="https://img.example.com/produkte/regal.jpg" alt="Regal aus Eiche" width="800" height="600">
<!-- Nachher: alles vom Host der Seite -->
<link rel="stylesheet" href="/css/app.css">
<script src="/js/app.bundle.js" defer></script>
<img src="/bilder/produkte/regal.jpg" alt="Regal aus Eiche" width="800" height="600">Die alten Adressen der Subdomains dürfen dabei nicht einfach verschwinden. Bilder vom Sharding-Host stecken in Bildindizes von Suchmaschinen, in Newslettern und auf fremden Seiten. Eine dauerhafte Weiterleitung je Datei auf den neuen Pfad hält sie erreichbar; wie Sie dabei Ketten vermeiden, beschreibt der Beitrag zu Weiterleitungsketten als Ladebremse.
Cookiefreie Domain und preconnect
preconnect an und beschränken sich auf die wenigen Hosts, die im sichtbaren Bereich gebraucht werden. Wie Sie Hinweise dieser Art dosieren, zeigt der Beitrag zu Resource Hints mit preload und prefetch.Sammeldateien: wenn eine Zeile den Cache leert
Die große Sammeldatei war unter HTTP/1.1 vernünftig: Eine Anfrage für alle Skripte war billiger als viele einzelne. Unter HTTP/2 kosten zusätzliche Anfragen auf derselben Verbindung wenig, und die Nachteile des Bündelns treten in den Vordergrund. Der wichtigste ist der Cache. Eine Datei wird als Ganzes zwischengespeichert und als Ganzes ungültig. Ändert sich in einem großen Skriptpaket eine Zeile im Code des Kontaktformulars, lädt jeder wiederkehrende Besucher das komplette Paket neu – auch die unveränderte Bibliothek, das Menü und den Slider.
Der zweite Nachteil ist ungenutzter Code. Eine Sammeldatei für die ganze Website bringt auf jede Seite alles mit: das Skript des Konfigurators auf die Startseite, die Suchvorschläge ins Impressum, die Karussell-Logik auf die Kontaktseite. Das kostet Übertragung, vor allem aber Rechenzeit, weil der Browser jeden geladenen Code zumindest einlesen und übersetzen muss. Wie sich JavaScript nach Seite und Bedarf aufteilen lässt, beschreibt der Beitrag zu Lazy Loading und Code-Splitting. Zwei Bauteile, die in vielen Sammeldateien stecken, haben wir eigens untersucht: den Slider im Kopfbereich und die Suchvorschläge der Shopsuche.
Die Lösung ist nicht, jede Datei einzeln auszuliefern. Hunderte Kleinstdateien haben eigene Kosten: Jede Anfrage trägt Kopfzeilen, jede Datei eine eigene Kompression, die bei sehr kleinen Dateien schlechter greift. Bewährt hat sich ein Mittelweg nach Änderungshäufigkeit. Bibliotheken, die sich selten ändern, kommen in eine eigene Datei mit langer Cache-Dauer. Eigener Code wird nach Seitentyp oder Bauteil getrennt. Und alles bekommt einen Inhalts-Hash im Dateinamen, damit eine Änderung nur die betroffene Datei erneuert. Welche Cache-Köpfe dazu passen, beschreibt die Seite zu Caching-Strategien.
Vorher: eine Sammeldatei für alle Seiten
app.bundle.js Bibliotheken, Menü, Slider, Suche, Formulare, Konfigurator
-> jede Änderung erneuert die ganze Datei
Nachher: nach Änderungshäufigkeit und Seitentyp getrennt
vendor.3f9a1c.js Bibliotheken, ändern sich selten, lange Cache-Dauer
basis.8b21e0.js Menü, Einwilligung, gemeinsame Funktionen
startseite.c47d12.js nur auf der Startseite
suche.19be77.js erst bei Fokus auf dem Suchfeld
formular.a02f5d.js nur auf Seiten mit Formular
-> eine Änderung am Formular erneuert nur formular.*.jsSprites und Data-URIs: Bytes ohne eigenen Cache
Sprites folgen derselben Logik wie Sammeldateien und teilen ihre Schwächen. Die Grafik lädt alle Symbole, auch die, die auf der aktuellen Seite nicht vorkommen, und ein neues Symbol erneuert die ganze Datei. Dazu kommt ein Problem, das in Rastergrafiken steckt: Ein Sprite als PNG muss für hochauflösende Bildschirme in doppelter Größe vorliegen und wird dann auf jedem Gerät geladen. Einzelne SVG-Dateien lassen sich unter HTTP/2 ohne nennenswerten Aufpreis parallel laden, einzeln cachen und nach Bedarf einbinden. Für Produktfotos und Inhaltsbilder gilt ohnehin ein anderer Weg, den der Beitrag zu WebP und AVIF beschreibt.
Data-URIs sind die radikalste Form des Bündelns: Das Bild steckt als Base64-Text im Stylesheet oder im HTML. Die Kodierung macht eine Datei laut MDN typischerweise rund ein Drittel (MDN Web Docs) größer als das Original. Schwerer wiegt, was die Einbettung mit dem Laden macht. Ein Bild im Stylesheet verlängert das Stylesheet, und das Stylesheet blockiert das Rendern. Die Bytes lassen sich nicht getrennt cachen: Ändert sich ein Symbol, ändert sich das ganze Stylesheet. Und der Browser kann sie nicht abbestellen. High Performance Browser Networking bringt es auf den Punkt: Einbetten sei gleichbedeutend mit einem erzwungenen Push, den der Client weder ablehnen noch abbrechen noch getrennt verarbeiten kann (High Performance Browser Networking).
Wo Einbetten noch passt
Server Push: abgeschaltet, nicht nur veraltet
Server Push war die HTTP/2-Antwort auf das Einbetten: Der Server schickt Dateien mit, bevor der Browser sie anfordert, und der Browser kann sie ablehnen, wenn er sie schon im Cache hat. In der Praxis ließ sich der Vorteil selten einlösen. Laut Chrome for Developers nutzten nur 1,25 Prozent (Chrome for Developers) der HTTP/2-Websites die Funktion, eine spätere Auswertung fand noch 0,7 Prozent (Chrome for Developers). Seit Chrome 106 (Chrome for Developers) ist Server Push in Chrome und weiteren Chromium-Browsern standardmäßig abgeschaltet.
Für den Rückbau heißt das: Push-Anweisungen im Webserver und die Umwandlung von Link-Köpfen in Push an einem vorgeschalteten Server bewirken heute nichts mehr. Sie gehören entfernt. Die Link-Köpfe selbst können bleiben, sie wirken weiter als preload-Hinweis. Den früheren Zweck übernehmen zwei Bausteine. <link rel="preload"> meldet dem Browser eine Datei an, die er sonst spät entdecken würde. 103 Early Hints schicken diese Hinweise schon, während der Server die eigentliche Seite noch berechnet; wie das geht, beschreibt der Beitrag zu 103 Early Hints und der Denkzeit des Servers. Verbreitet ist das noch wenig: Von 1,6 Prozent der Desktop-Seiten im Jahr 2022 stieg der Anteil nur auf 2,9 Prozent im Jahr 2024 (HTTP Archive Web Almanac 2024).
Der Unterschied in einem Satz
Woran man die Altlasten im Wasserfall erkennt
Die Altlasten lassen sich mit Bordmitteln des Browsers sichtbar machen. Öffnen Sie die Entwicklerwerkzeuge, wechseln Sie in den Netzwerk-Reiter und blenden Sie per Rechtsklick auf die Spaltenköpfe die Spalten „Protocol“ und „Connection ID“ ein. Laden Sie die Seite mit geleertem Cache neu. Jetzt zeigt jede Zeile, über welches Protokoll und über welche Verbindung die Datei kam. Eine gesunde HTTP/2-Seite hat für den eigenen Host eine einzige Verbindungsnummer; jede weitere Nummer steht für einen Host, der eine eigene Verbindung aufgebaut hat.
- Mehrere Verbindungsnummern für Hosts wie static1, static2 oder img, die alle zum eigenen Betrieb gehören.
- In der Zeitleiste einer Zeile tauchen DNS-Abfrage, Verbindungsaufbau und TLS-Handschlag auf, obwohl der Host der Seite längst verbunden ist.
- Eine einzelne JavaScript- oder CSS-Datei, die ein Vielfaches größer ist als alle übrigen und nach jedem Release neu geladen wird.
- Eine Grafik mit dem Namen sprite oder icons, die auf jeder Seite lädt, obwohl dort nur wenige Symbole zu sehen sind.
- Einträge mit dem Protokoll data: oder ein Stylesheet, dessen Größe vor allem aus Base64-Text besteht.
- Die Spalte Protocol zeigt http/1.1 statt h2 oder h3 – dann gilt der Abschnitt zur Gegenprobe zuerst.
Für eine schnelle Übersicht aus der Kommandozeile genügt curl. Die Schleife unten fragt jeden Host ab, der im Wasserfall auftaucht, und gibt die ausgehandelte Protokollversion aus. Stellen Sie die Anfrage über HTTPS, denn Browser handeln HTTP/2 nur über TLS aus.
# Protokollversion je Host ausgeben: 2 = HTTP/2, 1.1 = kein HTTP/2
for host in www.example.com static1.example.com img.example.com; do
printf '%-24s ' "$host"
curl -s -o /dev/null --http2 -w '%{http_version}\n' "https://$host/"
doneLaborwerte sind nur ein Teil des Bildes. Ob sich der Rückbau auf die Kennzahlen Ihrer Besucher auswirkt, zeigen erst Felddaten; wie Sie beides zusammenbringen, erklärt die Übersichtsseite zu den Core Web Vitals.
Gegenprobe: wo HTTP/1.1 noch läuft
Vor jedem Rückbau steht eine Frage: Kommt Ihre Seite beim Besucher wirklich über HTTP/2 an? Meist lautet die Antwort ja, im Einzelfall nicht unbedingt. Über ein CDN liefen 2024 weniger als 4 Prozent der Anfragen über HTTP/1.1, ohne CDN dagegen bis zu 29 Prozent (HTTP Archive Web Almanac 2024). Typische Ursachen sind ein älterer Load Balancer oder Reverse Proxy vor dem Webserver, der HTTP/2 nicht anbietet, eine Web Application Firewall, die TLS selbst beendet, oder eine Serverkonfiguration, in der HTTP/2 schlicht nicht eingeschaltet ist.
Tückisch ist, dass der Rückfall still passiert. Browser und Server handeln das Protokoll beim TLS-Aufbau aus; bietet der Server kein HTTP/2 an, geht es laut Web Almanac ohne Umweg über dieselbe Verbindung mit HTTP/1.1 weiter (HTTP Archive Web Almanac 2024). Keine Fehlermeldung, kein Warnhinweis – nur ein anderer Eintrag in der Spalte Protocol. Für die Rückbau-Liste ist das entscheidend: Auf einer HTTP/1.1-Strecke ist Domain-Sharding wieder das kleinere Übel, und wer dort die Subdomains zusammenlegt, beschränkt den Browser auf 6 Verbindungen (MDN Web Docs) für alle Dateien. Erst das Protokoll, dann der Rückbau. Wie Sie Webserver und vorgeschaltete Komponenten auf HTTP/2 bringen, gehört zur Server-Optimierung.
// In der Konsole der Entwicklerwerkzeuge ausführen:
// listet je Datei Host und ausgehandeltes Protokoll (h2, h3, http/1.1)
// Bei fremden Hosts kann das Feld leer bleiben
const zeilen = performance.getEntriesByType('resource').map((e) => ({
host: new URL(e.name).host,
protokoll: e.nextHopProtocol || '(leer)',
datei: new URL(e.name).pathname.split('/').pop()
}));
console.table(zeilen);Derselbe Ausschnitt taugt als Baustein für eine eigene Felderfassung: Wer den Wert von nextHopProtocol für das Dokument mitschreibt, sieht, welcher Anteil der Besucher tatsächlich über HTTP/2 oder HTTP/3 ankommt – auch hinter Firmen-Proxys, die im Labor nicht auftauchen.
Erst Protokoll, dann Rückbau
Rückbau in sicherer Reihenfolge
Aus der Projektarbeit hat sich eine Reihenfolge bewährt, in der jeder Schritt für sich messbar bleibt und sich bei Bedarf zurücknehmen lässt. Wichtig ist, nicht alles in einem Release zu ändern: Wer Hosts, Bündel und Sprites gleichzeitig umbaut, kann eine Verschlechterung keinem Schritt mehr zuordnen.
- Protokoll sichern: Für jeden Host, der im Wasserfall vorkommt, HTTP/2 nachweisen – im Labor mit curl, im Feld mit
nextHopProtocol. Erst wenn das steht, beginnt der Rückbau. - Server Push entfernen: Push-Anweisungen im Webserver und die Umwandlung von Link-Köpfen in Push abschalten. Das ist risikoarm, weil Chrome und Chromium-Browser Push ohnehin nicht mehr annehmen.
- Eigene Hosts zusammenführen: Statische Dateien von static1, static2 und img auf den Host der Seite legen, die alten Adressen je Datei dauerhaft weiterleiten und die Weiterleitungen ohne Ketten halten.
- Fremde Hosts prüfen: Jeden verbleibenden fremden Host hinterfragen. Was im sichtbaren Bereich gebraucht wird und nicht umziehen kann, bekommt ein
preconnect; der Rest lädt später oder gar nicht. - Sammeldateien teilen: Bibliotheken und eigenen Code trennen, eigenen Code nach Seitentyp aufteilen, Dateinamen mit Inhalts-Hash versehen und eine lange Cache-Dauer setzen.
- Sprites und Data-URIs auflösen: Symbole als einzelne SVG-Dateien ausliefern, Base64-Bilder aus dem Stylesheet holen und nur winzige, sofort sichtbare Symbole eingebettet lassen.
- Nachmessen: Wasserfall, Zahl der Verbindungen und Übertragungsgröße vor und nach jedem Schritt vergleichen und die Wirkung in den Felddaten über mehrere Wochen beobachten.
Weniger Verbindungen
Ein Host für die eigenen Dateien heißt eine DNS-Abfrage, ein TLS-Handschlag und eine Verbindung, auf der der Browser alle Dateien gemeinsam priorisiert.
Gezielte Cache-Erneuerung
Kleinere Dateien mit Inhalts-Hash erneuern nach einem Release nur das, was sich geändert hat. Wiederkehrende Besucher laden weniger nach.
Risikoarm umkehrbar
Jeder Schritt steht für sich. Zeigt eine Messung eine Verschlechterung, lässt sich genau dieser Schritt zurücknehmen, ohne die übrigen anzufassen.
In vielen gewachsenen Frontends stecken Maßnahmen, die einmal ein echtes Problem gelöst haben. Sie zurückzubauen ist keine Kritik an der früheren Arbeit, sondern die Anpassung an ein Protokoll, das die damalige Not nicht mehr kennt.
Was bleibt: Maßnahmen, die weiter tragen
Nicht alles aus der HTTP/1.1-Zeit ist überholt. Kompression, lange Cache-Dauer für versionierte Dateien, passend skalierte Bilder und das Weglassen von ungenutztem Code wirken unter jedem Protokoll. Auch HTTP/3 ändert daran nichts: Es übernimmt das Multiplexing von HTTP/2 und verlagert den Transport auf QUIC, wie der Beitrag zu HTTP/3 und QUIC zeigt; die Protokollunterschiede fasst die FAQ zum Unterschied zwischen HTTP/2 und HTTP/3 zusammen. Die Rückbau-Liste gilt dort genauso, denn auch HTTP/3 bündelt die Dateien eines Hosts in einer Verbindung.
Wer wissen will, welche Altlasten die eigene Website trägt, beginnt mit einer technischen Analyse der Ladewege: Wasserfall, Protokoll je Host, Größe und Änderungsrhythmus der Bündel. Den Umbau selbst übernimmt die Frontend-Optimierung, und für gewachsene Auftritte mit vielen Seitentypen gibt es eine eigene Seite zu Pagespeed für Unternehmenswebsites. Fragen zum eigenen Fall beantworten wir über das Kontaktformular.
Quellen und Studien
curl -s -o /dev/null --http2 -w '%{http_version}' https://www.example.com/ die ausgehandelte Version aus. Für echte Besucher liefert nextHopProtocol aus der Resource Timing API den Wert je Datei, auch hinter Proxys, die im Labor nicht auftauchen.<link rel="preload"> meldet dem Browser früh eine Datei an, die er sonst spät entdecken würde. 103 Early Hints senden solche Hinweise schon, während der Server die Seite noch berechnet. In beiden Fällen entscheidet der Browser selbst, ob er die Datei lädt oder aus dem Cache nimmt – genau das fehlte beim Push.Verwandte Artikel
Suchvorschläge ohne Wartezeit: die Shopsuche beschleunigen
Die Shopsuche als Echtzeitstrecke: Eingaben entprellen, überholte Anfragen abbrechen, häufige Präfixe cachen und die Vorschlagsliste schlank rendern.
Slider im Kopfbereich: warum das Karussell den LCP kostet
Warum das Karussell im Kopfbereich oft das LCP-Element ist, wie Autoplay den CLS treibt und wie ein Slider schnell lädt, stabil bleibt und sich anhalten lässt.
Vorlage statt Startseite: wo die Ladezeit wirklich entsteht
Optimiert wird die Startseite, angesteuert werden Kategorie-, Produkt- und Artikelseiten. Wie Sie nach Vorlagen messen und die Reihenfolge belegen.