Zwei Menschen öffnen denselben Online-Shop im selben Moment: die eine im schnellen WLAN am Schreibtisch, der andere unterwegs im Zug mit schwankendem Mobilfunk. Beide bekommen heute meist exakt dasselbe ausgeliefert -- dieselben hochauflösenden Bilder, dieselben Skripte, dasselbe megabyteschwere Bundle. Für die eine ist das kein Problem, für den anderen wird es zur Geduldsprobe: Die Seite hängt, das Titelbild baut sich zäh auf, und noch bevor überhaupt etwas Nutzbares erscheint, ist die Person schon wieder weg. 53 Prozent (Google) der Mobilnutzer verlassen eine Seite, die länger als drei Sekunden lädt. Adaptives Laden dreht dieses Prinzip um: Statt jeden Besucher mit der vollen Ladung auszubremsen, erkennt der Shop die Netzqualität und liefert bei langsamer Verbindung eine bewusst leichtere Variante aus -- weniger Bilder, aufgeschobene Skripte, kein automatisch startendes Video. Die technische Grundlage sind zwei Signale, die der Browser bereits mitschickt: der Save-Data-Header und die Angabe effectiveType aus der Network Information API. Dieser Beitrag zeigt, wie beide funktionieren, wie sich daraus eine leichte und eine volle Auslieferung ableiten lassen und worauf es dabei ankommt. In unserer Frontend-Optimierung ist diese netzbewusste Auslieferung ein wiederkehrender Baustein.
Das Wichtigste in Kürze
- 53 Prozent (Google) der mobilen Nutzer verlassen eine Seite, die länger als drei Sekunden lädt. Adaptives Laden liefert deshalb je nach Netzqualität eine bewusst leichtere oder die volle Variante aus -- der kaufentscheidende Kern bleibt in beiden gleich.
- Die mittlere mobile Seite wiegt inzwischen 2.362 KB (Web Almanac 2025) gegenüber 845 KB (Web Almanac 2025) im Jahr 2015; den größten Anteil stellen Bilder mit im Median 1.058 KB (Web Almanac 2025).
- Zwei Signale stellen die Weiche: der Save-Data-Header als ausdrücklicher Nutzerwunsch und navigator.connection.effectiveType mit den Stufen slow-2g, 2g, 3g und 4g aus gemessener Rundlaufzeit und Bandbreite (MDN).
- Die Entscheidung kann im Browser oder auf dem Server fallen. Serverseitig ist sie robuster, weil die leichte Variante gar nicht erst über die schwache Leitung geht; der Client verfeinert sie mit der aktuellsten Netzinformation.
- Die Network Information API fehlt in einigen Browsern (MDN), deshalb muss adaptives Laden als progressive Verbesserung gebaut werden: fehlt das Signal, greift die volle Variante. Inhalte verstecken darf es nie -- das wäre Cloaking.
Warum ein Netz nicht wie das andere ist
Websites sind über die Jahre deutlich schwerer geworden. Die mittlere mobile Seite wiegt inzwischen 2.362 KB (Web Almanac 2025) -- 2015 waren es noch 845 KB (Web Almanac 2025), also ein Zuwachs von rund 203 Prozent (Web Almanac 2025) in nur zehn Jahren. Den größten Brocken machen Bilder mit im Median 1.058 KB (Web Almanac 2025) aus, gefolgt von JavaScript mit etwa 697 KB (Web Almanac 2025). Auf einer schnellen Leitung fällt dieses Gewicht kaum auf. Auf einer gedrosselten, überlasteten oder schlicht schwachen Mobilverbindung entscheidet aber genau dieses Gewicht darüber, ob die Seite in drei Sekunden nutzbar ist oder ob der Besucher vorher abspringt.
Das Tückische daran: Der Durchschnittswert täuscht. Ein Entwickler misst am schnellen Büroanschluss und sieht eine flotte Seite -- der Kunde im ländlichen Funkloch oder in der überfüllten U-Bahn erlebt etwas ganz anderes. Genau diese Nutzer sind für einen Shop teuer erkauft und leicht verloren: Wer wegen der Ladezeit abspringt, kauft nicht, und jede Sekunde Wartezeit drückt messbar auf die Abschlussquote, wie wir im Beitrag zu Ladezeit, Conversion-Rate und Umsatz ausführen. Adaptives Laden setzt an dieser Lücke an -- es behandelt nicht alle Verbindungen gleich, sondern liefert jedem das aus, was sein Netz gerade tragen kann. Die Grundlagen der mobilen Auslieferung fassen wir in der mobilen Performance-Optimierung zusammen.
Was 'langsames Netz' technisch bedeutet
Die zwei Signale: Save-Data und effectiveType
Das erste Signal ist der Save-Data-Header. Aktiviert ein Nutzer in seinem Browser einen Datensparmodus, sendet der Browser bei jeder Anfrage automatisch den Header 'Save-Data: on' mit -- ein Verhalten, das Chromium-basierte Browser seit Version 49 unterstützen (web.dev). Für die Website ist das ein ausdrücklicher Wunsch: 'Bitte sparsam mit meinem Datenvolumen umgehen.' Im Browser selbst lässt sich derselbe Zustand über die Eigenschaft navigator.connection.saveData abfragen, die schlicht true oder false liefert (MDN). Dieses Signal ist besonders wertvoll, weil es nicht geschätzt, sondern vom Nutzer selbst gesetzt ist.
Das zweite Signal ist die geschätzte Netzqualität über navigator.connection.effectiveType. Sie liefert einen der vier Werte slow-2g, 2g, 3g oder 4g und beruht auf einer laufenden Messung von Rundlaufzeit und Downlink-Geschwindigkeit (web.dev). Anders als der Save-Data-Header ist dies keine bewusste Nutzerentscheidung, sondern eine Momentaufnahme der Leitung -- die sich während einer Sitzung ändern kann, etwa wenn der Zug in einen Tunnel fährt. Aus beiden Signalen zusammen entsteht die Entscheidung: Ist die Verbindung schwach oder der Datensparmodus an, liefert der Shop die leichte Variante; sonst die volle.
Client oder Server: zwei Wege der Erkennung
Die Entscheidung, was ausgeliefert wird, lässt sich an zwei Stellen treffen: im Browser oder auf dem Server. Im Browser fragt JavaScript die Network Information API direkt ab und lädt Zusatzressourcen nur, wenn die Leitung sie trägt. Ein hochauflösendes Hintergrundbild, ein Karussell mit vielen Motiven oder ein nicht kritisches Analyse-Skript werden dann erst nachgeladen, wenn effectiveType '4g' meldet und der Datensparmodus aus ist. Der Vorteil: Die Logik liegt beim Client, wo die aktuellste Netzinformation vorliegt.
const c = navigator.connection || {};
const sparsam = c.saveData === true ||
['slow-2g', '2g', '3g'].includes(c.effectiveType);
if (sparsam) {
// leichte Variante: kleine Bilder, keine Autoplay-Videos
document.body.dataset.mode = 'light';
} else {
// volle Variante nachladen
import('./enhancements.js');
}Der zweite Weg führt über den Server. Weil der Save-Data-Header bei jeder Anfrage mitkommt, kann bereits die Serverlogik oder ein vorgelagertes CDN darauf reagieren und gleich eine andere Antwort ausliefern -- etwa ein schlankeres HTML, kleinere Bildvarianten oder ein reduziertes Skriptbündel. Das ist besonders robust, weil die leichte Version dann gar nicht erst über die schwache Leitung geschickt wird. In der Praxis kombinieren viele Projekte beides: Der Server trifft anhand des Headers die grobe Vorauswahl, der Client verfeinert sie. Wie sich solche Entscheidungen sauber ins Backend und an die Auslieferung anbinden lassen, gehört zur Server-Optimierung.
Was die leichte Variante weglässt
Adaptives Laden bedeutet nicht, dem Nutzer Inhalte vorzuenthalten. Die Kernaufgabe der Seite -- Produkte finden, ansehen, in den Warenkorb legen, bestellen -- bleibt in beiden Varianten vollständig erhalten. Reduziert wird nur das Beiwerk, das auf einer schwachen Leitung überproportional wehtut. Drei Hebel tragen dabei am meisten:
Bilder
Die leichte Variante liefert kleinere Auflösungen, stärkere Kompression und verzichtet auf dekorative Hintergründe. Da Bilder mit im Median 1.058 KB (Web Almanac 2025) den größten Anteil am Seitengewicht stellen, ist dies der wirksamste Hebel.
Skripte
Nicht kritische Skripte -- Karussells, aufwendige Animationen, sekundäre Widgets -- werden auf schwachen Leitungen aufgeschoben oder ganz weggelassen. Wie sich Bundles gezielt aufteilen lassen, zeigt der Beitrag zu Lazy Loading und Code Splitting.
Video und Fremdinhalte
Automatisch startende Videos, eingebettete Karten und schwere Drittanbieter-Widgets entfallen zugunsten eines Standbilds oder eines Platzhalters mit Klick zum Laden -- Fremdinhalte behandeln wir gesondert im Beitrag zum Entschlacken von Third-Party-Skripten.
| Element | Leichte Variante (langsames Netz) | Volle Variante (schnelles Netz) |
|---|---|---|
| Titelbild | Klein, stark komprimiert | Hohe Auflösung, mehrere Motive |
| Video | Standbild mit Klick zum Laden | Autoplay, vorab geladen |
| Skripte | Nur kritischer Kern | Alle Zusatzfunktionen aktiv |
| Schriften | Systemschrift bis Nachladen | Web-Schrift sofort |
| Typisches Gewicht | rund 0,6 MB | rund 2,4 MB |
Adaptives Laden serverseitig ausliefern
Für Online-Shops ist der serverseitige Weg oft der lohnendere, weil er die schwache Leitung von vornherein entlastet. Der Server oder das CDN prüft den Save-Data-Header und entscheidet, welche Bild- und Skriptvarianten überhaupt in die Antwort gelangen. Zusätzlich lässt sich per Client Hints steuern, dass der Browser Informationen über Netz und Gerät früh mitsendet, sodass die passende Variante ohne zusätzlichen Roundtrip ausgewählt werden kann. Für wiederkehrende Besucher greift ein weiterer Baustein: Liegt die leichte Variante bereits über einen Service Worker mit Precaching lokal vor, ist sie beim nächsten Besuch praktisch sofort da -- unabhängig von der aktuellen Netzqualität.
Der Kern in einem Satz
Grenzen, Fallstricke und Fairness
So nützlich die beiden Signale sind, sie haben Grenzen. Die Network Information API wird derzeit vor allem von Chromium-basierten Browsern und von Firefox auf Android unterstützt, während sie in einigen anderen Browsern fehlt (MDN). Adaptives Laden muss deshalb als progressive Verbesserung gedacht werden: Fehlt das Signal, wird die volle Variante ausgeliefert -- niemand bekommt eine kaputte Seite, nur weil sein Browser die API nicht kennt. Der effectiveType-Wert ist außerdem eine Schätzung und kann daneben liegen; er taugt für grobe Weichenstellungen, nicht für millimetergenaue Entscheidungen.
Nicht am Nutzer vorbei optimieren
Adaptives Laden im Shop umsetzen
In der Praxis lohnt sich adaptives Laden dort am meisten, wo viel Beiwerk auf viel mobilen Traffic trifft -- also bei bildlastigen Shops mit hohem Smartphone-Anteil. Der Einstieg gelingt schrittweise, ohne die bestehende Seite umzubauen:
- Den mobilen Anteil und die Netzverteilung der echten Besucher aus den Felddaten ablesen -- nicht aus dem Bauchgefühl
- Die schwersten, am wenigsten kaufentscheidenden Elemente identifizieren: Hero-Bilder, Karussells, Autoplay-Videos, sekundäre Skripte
- Für diese Elemente eine leichte Variante definieren und über Save-Data sowie effectiveType als Weiche schalten
- Als progressive Verbesserung aufbauen: fehlt das Signal, greift die volle Variante
- Vorher und nachher in den Felddaten messen -- verbessert sich das mobile Ladeerlebnis für die schwachen Netze wirklich?
Genau so gehen wir in einem Performance-Projekt vor: Wir prüfen, wie viel Ihres mobilen Traffics auf schwachen Leitungen unterwegs ist, benennen die schwersten verzichtbaren Elemente und bauen eine netzbewusste Auslieferung als saubere Erweiterung ein -- statt eines pauschalen Rundumschlags. Für Shopware-Shops verbinden wir das mit den übrigen Performance-Hebeln, und wer die drei Kennzahlen dahinter im Zusammenhang verstehen möchte, findet die Einordnung im Beitrag zu den Core Web Vitals 2026. Ergänzend lohnt der Blick auf verwandte Techniken, mit denen sich das mobile Erlebnis weiter glätten lässt: das Auslagern schwerer Arbeit vom Hauptthread über Web Worker und nahtlose Seitenwechsel per View Transitions.
Adaptives Laden macht aus einer starren Auslieferung eine faire: Wer eine schwache Leitung hat, wird nicht mit der vollen Ladung bestraft, sondern bekommt eine Version, die tatsächlich ankommt. Das ist kein Verzicht, sondern Rücksicht -- und die zahlt sich in weniger Abbrüchen aus.
Der Aufwand bleibt überschaubar, weil die Signale bereits im Browser vorliegen und die leichte Variante meist aus vorhandenen, nur kleineren Ressourcen besteht. Was zählt, ist die Reihenfolge: erst messen, wo die schwachen Netze zahlenmäßig ins Gewicht fallen, dann die richtigen Elemente reduzieren und die Wirkung wieder im Feld prüfen. Welche Leistungen dazugehören und wie ein solches Projekt abläuft, zeigt unsere Übersicht der Performance-Leistungen.