Two people open the same online shop at the very same moment: one on fast office Wi-Fi at a desk, the other on a train with patchy mobile coverage. Today both usually receive exactly the same delivery -- the same high-resolution images, the same scripts, the same megabyte-heavy bundle. For one that is no problem; for the other it becomes a test of patience: the page stalls, the hero image builds up sluggishly, and before anything useful even appears, the person is already gone. 53 percent (Google) of mobile users abandon a page that takes longer than three seconds to load. Adaptive loading turns this principle around: instead of slowing every visitor with the full payload, the shop detects the network quality and, on a slow connection, serves a deliberately lighter variant -- fewer images, deferred scripts, no auto-playing video. The technical basis is two signals the browser already sends: the Save-Data header and the effectiveType value from the Network Information API. This article shows how both work, how to derive a light and a full delivery from them, and what matters along the way. In our frontend optimization this network-aware delivery is a recurring building block.
Key takeaways
- 53 percent (Google) of mobile users abandon a page that takes longer than three seconds to load. Adaptive loading therefore serves a deliberately lighter or the full variant depending on network quality -- the purchase-critical core stays the same in both.
- The median mobile page now weighs 2,362 KB (Web Almanac 2025) compared with 845 KB (Web Almanac 2025) in 2015; the largest share comes from images at a median of 1,058 KB (Web Almanac 2025).
- Two signals set the switch: the Save-Data header as an explicit user wish, and navigator.connection.effectiveType with the levels slow-2g, 2g, 3g and 4g derived from measured round-trip time and bandwidth (MDN).
- The decision can be made in the browser or on the server. Server-side is more robust, because the light variant is never sent over the weak line in the first place; the client refines it with the most current network information.
- The Network Information API is missing in some browsers (MDN), so adaptive loading must be built as a progressive enhancement: if the signal is absent, the full variant applies. It must never hide content -- that would be cloaking.
Why One Network Is Not Like the Other
Websites have grown considerably heavier over the years. The median mobile page now weighs 2,362 KB (Web Almanac 2025) -- in 2015 it was still 845 KB (Web Almanac 2025), an increase of about 203 percent (Web Almanac 2025) in just ten years. The largest chunk comes from images at a median of 1,058 KB (Web Almanac 2025), followed by JavaScript at roughly 697 KB (Web Almanac 2025). On a fast line this weight barely registers. On a throttled, congested or simply weak mobile connection, however, that exact weight decides whether the page is usable within three seconds or whether the visitor leaves before it is.
The tricky part: the average value deceives. A developer measures on a fast office line and sees a snappy page -- the customer in a rural dead zone or a crowded subway experiences something entirely different. Those very users are expensive to acquire and easy to lose: whoever bounces because of load time does not buy, and every extra second measurably depresses the conversion rate, as we explain in the article on page speed, conversion rate and revenue. Adaptive loading addresses this gap -- it does not treat all connections alike but serves each one what its network can currently carry. The fundamentals of mobile delivery we summarize in mobile performance optimization.
What 'slow network' means technically
The Two Signals: Save-Data and effectiveType
The first signal is the Save-Data header. When a user enables a data-saving mode in their browser, the browser automatically sends the header 'Save-Data: on' with every request -- a behavior that Chromium-based browsers have supported since version 49 (web.dev). For the website this is an explicit wish: 'Please be economical with my data allowance.' In the browser itself the same state can be queried through the property navigator.connection.saveData, which simply returns true or false (MDN). This signal is especially valuable because it is not estimated but set by the user.
The second signal is the estimated network quality via navigator.connection.effectiveType. It returns one of the four values slow-2g, 2g, 3g or 4g and is based on an ongoing measurement of round-trip time and downlink speed (web.dev). Unlike the Save-Data header this is not a conscious user choice but a snapshot of the line -- which can change during a session, for instance when a train enters a tunnel. From both signals together the decision emerges: if the connection is weak or the data-saving mode is on, the shop serves the light variant; otherwise the full one.
Client or Server: Two Paths of Detection
The decision about what to deliver can be made in two places: in the browser or on the server. In the browser, JavaScript queries the Network Information API directly and loads extra resources only when the line can carry them. A high-resolution background image, a carousel with many motifs or a non-critical analytics script is then only loaded once effectiveType reports '4g' and the data-saving mode is off. The advantage: the logic sits with the client, where the most current network information is available.
const c = navigator.connection || {};
const frugal = c.saveData === true ||
['slow-2g', '2g', '3g'].includes(c.effectiveType);
if (frugal) {
// light variant: small images, no autoplay video
document.body.dataset.mode = 'light';
} else {
// load the full variant
import('./enhancements.js');
}The second path runs via the server. Because the Save-Data header comes with every request, the server logic or an upstream CDN can react to it and deliver a different response right away -- for example leaner HTML, smaller image variants or a reduced script bundle. This is especially robust, because the light version is then not even sent over the weak line in the first place. In practice many projects combine both: the server makes the rough preselection based on the header, and the client refines it. How to wire such decisions cleanly into the backend and the delivery belongs to server optimization.
What the Light Variant Leaves Out
Adaptive loading does not mean withholding content from the user. The core task of the page -- find products, view them, add to cart, order -- remains fully intact in both variants. Only the trimmings that hurt disproportionately on a weak line are reduced. Three levers carry the most weight here:
Images
The light variant serves smaller resolutions, stronger compression and drops decorative backgrounds. Since images, at a median of 1,058 KB (Web Almanac 2025), make up the largest share of page weight, this is the most effective lever.
Scripts
Non-critical scripts -- carousels, elaborate animations, secondary widgets -- are deferred or dropped entirely on weak lines. How to split bundles deliberately is shown in the article on lazy loading and code splitting.
Video and third-party content
Auto-playing videos, embedded maps and heavy third-party widgets give way to a still image or a click-to-load placeholder -- third-party content we cover separately in the article on trimming third-party scripts.
| Element | Light variant (slow network) | Full variant (fast network) |
|---|---|---|
| Hero image | Small, strongly compressed | High resolution, several motifs |
| Video | Still image with click to load | Autoplay, preloaded |
| Scripts | Critical core only | All extra features active |
| Fonts | System font until loaded | Web font immediately |
| Typical weight | about 0.6 MB | about 2.4 MB |
Delivering Adaptive Loading Server-Side
For online shops the server-side path is often the more rewarding one, because it relieves the weak line from the outset. The server or the CDN checks the Save-Data header and decides which image and script variants make it into the response at all. In addition, client hints can be used so the browser sends information about network and device early, allowing the right variant to be selected without an extra round trip. For returning visitors another building block helps: if the light variant is already available locally through a service worker with precaching, it is practically instant on the next visit -- regardless of the current network quality.
The Core in One Sentence
Limits, Pitfalls and Fairness
As useful as the two signals are, they have limits. The Network Information API is currently supported mainly by Chromium-based browsers and by Firefox on Android, while it is missing in some other browsers (MDN). Adaptive loading must therefore be thought of as a progressive enhancement: if the signal is absent, the full variant is delivered -- no one gets a broken page just because their browser does not know the API. The effectiveType value is also an estimate and can be off; it is good for coarse routing, not for millimeter-precise decisions.
Do not optimize past the user
Rolling Out Adaptive Loading in the Shop
In practice adaptive loading pays off most where a lot of trimming meets a lot of mobile traffic -- that is, image-heavy shops with a high smartphone share. You can start step by step, without rebuilding the existing site:
- Read the mobile share and network distribution of real visitors from field data -- not from gut feeling
- Identify the heaviest, least purchase-critical elements: hero images, carousels, autoplay videos, secondary scripts
- Define a light variant for these elements and switch it via Save-Data and effectiveType
- Build it as a progressive enhancement: if the signal is missing, the full variant applies
- Measure before and after in the field data -- does the mobile loading experience on weak networks really improve?
This is exactly how we proceed in a performance project: we examine how much of your mobile traffic travels on weak lines, name the heaviest dispensable elements and build a network-aware delivery as a clean extension -- instead of a blanket sweep. For Shopware shops we combine this with the other performance levers, and anyone who wants to understand the three metrics behind it in context will find the classification in the article on Core Web Vitals 2026. It is also worth looking at related techniques that smooth the mobile experience further: offloading heavy work from the main thread with web workers and seamless page navigation via view transitions.
Adaptive loading turns a rigid delivery into a fair one: whoever has a weak line is not punished with the full payload but gets a version that actually arrives. That is not a sacrifice but consideration -- and it pays off in fewer bounces.
The effort stays manageable, because the signals are already available in the browser and the light variant usually consists of existing, merely smaller resources. What matters is the order: first measure where weak networks carry weight in the numbers, then reduce the right elements and check the effect again in the field. Which services this includes and how such a project runs is shown in our overview of performance services.