Delivering Fast and Light Applications with Save-Data

Your server can check incoming request headers for Save-Data and return an alternate response—smaller markup, reduced media, fewer resources. For service-worker driven applications, the worker can inspect the same header on intercepted requests and rewrite them to fetch fewer bytes or serve from cache.

Detecting the setting in JavaScript

Client-side code can also react to the data-saving preference. Detection goes through the Network Information API, exposed on navigator.connection. That object is currently implemented in Chrome, Chrome for Android, and Samsung Internet, so a feature check is required before reading the saveData property:

if ('connection' in navigator) {
  if (navigator.connection.saveData === true) {
    // Implement data saving operations here.
  }
}

With the connection object confirmed, testing navigator.connection.saveData === true tells you whether to apply any client-side reductions.

Building a usable, honest lightweight experience

A lighter page shouldn't feel like a stripped one. The goal is to remove weight without removing substance. Keep important functions and data intact; make delivery more efficient when it matters. Good examples:

• Photo galleries can show lower-resolution previews and fall back to full images on demand.
• Search results can limit the number of entries, or reduce media-heavy results and dependencies per page.
• News sites can prioritize popular categories, reduce visible stories, and provide smaller media previews.

The server-side version selection needs care in caches. If your response varies on the Save-Data header, emit the Vary: Save-Data response header so upstream caches know to store the two representations separately.

UI affordances and complementary signals

Users who opt into data savings shouldn't feel boxed in. Where options exist, give them a visible way to see which mode is active and switch back: banners explaining that Save-Data is supported, clear toggles, and a straightforward mechanism to exit the lightweight mode.

Save-Data can be paired with other client signals for smarter choices. The NetInfo API describes connection type and technology; you might want the lightweight experience for any user on 2G even if they haven't opted in. Conversely, a user on a nominally fast connection may still prefer to save data when roaming or on a capped plan. TheDevice-Memory client hint and its script exposure via navigator.deviceMemory allow the response to be further adapted for devices with tighter memory budgets.

Practical patterns for Save-Data

The Save-Data header opens up a range of server-side and client-side strategies for trimming payloads. While the exact implementation depends on your stack, the patterns below illustrate how a little conditional logic can meaningfully reduce what you send to data-conscious users.

Detecting Save-Data on the server

Client-side detection via navigator.connection.saveData is straightforward, but it has limits: JavaScript may not execute, and you cannot alter markup before it reaches the browser. For those cases, checking the Save-Data header in your back end is the right call.

The syntax varies by language, but the principle is consistent. In PHP, request headers appear in the $_SERVER superglobal with an HTTP_ prefix. You can therefore test for the header like this:

// false by default.
$saveData = false;

// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
  // `Save-Data` detected!
  $saveData = true;
}

Place this check before any output is sent. The resulting $saveData boolean is then available anywhere in your page logic, letting you tailor responses before a single byte of markup goes over the wire.

Scaling images down for high-density displays

Many sites serve two variants of each image: a standard 1x version and a 2x version for Retina-class displays. High-density screens are no longer rare, but for users who want to conserve data, sending the larger 2x assets is wasteful. When the Save-Data header is present, you can simply swap the srcset markup you send:

if ($saveData === true) {
  // Send a low-resolution version of the image for clients specifying `Save-Data`.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
  // Send the usual assets for everyone else.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}

This is a low-effort win. If you would rather not touch back-end markup, a URL rewrite module such as Apache's mod_rewrite can achieve the same result with minimal configuration.

The same idea extends to CSS background-image resources. Add a marker class to the <html> element:

<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">

With the save-data class in place, your stylesheets can target it to serve lower-resolution backgrounds or drop certain assets entirely.

Removing non-essential imagery

Not every image on a page is critical. Decorative or supplementary pictures may be nice to have, but they are prime candidates for omission when data is scarce. Using the PHP detection snippet above, you can conditionally skip that markup altogether:

<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
  // Only send this image if `Save-Data` hasn't been detected.
  ?><img src="meme.jpg" alt="One does not simply consume data."><?php
}

The effect can be substantial, as the figure below demonstrates:

Images are not the only resource you can drop. The same conditional logic works for other non-critical files, such as webfonts.

Dropping non-essential webfonts

Webfonts typically account for a smaller share of page weight than images, but they are still a measurable cost. They also introduce rendering complexities — FOIT, FOUT, and browser heuristics all play a role in how and when fonts appear.

When a font is not essential, Save-Data gives you an easy way to skip it. Suppose you load Fira Sans from Google Fonts for body copy. If a user has data saving enabled, you can prefer a system font instead. By adding the save-data class to the <html> element, you can write CSS that initially invokes Fira Sans but overrides it under the data-saving condition:

/* Opt into web fonts by default. */
p,
li {
  font-family: 'Fira Sans', 'Arial', sans-serif;
}

/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
  font-family: 'Arial', sans-serif;
}

This works because browsers speculatively fetch stylesheet resources only after applying styles to the DOM. If the save-data class is present and the CSS no longer references Fira Sans for any element, the font file is never requested. The user gets Arial instead — a slightly different look, but a worthwhile tradeoff for someone on a metered connection.

The takeaway

Save-Data is a binary signal: it is either on or off. The header does not tell you why a user enabled it, only that they did. Some users switch it on during poor connectivity but expect the full experience otherwise; others keep it on permanently to minimize page size. The safe assumption is to deliver the complete experience until the header explicitly tells you otherwise.

Builders own the responsibility of acting on that signal. With relatively small changes — conditional image markup, a CSS class, or a server-side check — you can offer a materially lighter page to those who ask for it.