Network Information API and Battery API: Building Adaptive Web Apps

1. Why network and battery state matter for web apps

A web application that serves the same high resolution images, the same video and the same amount of prefetching to every user ignores a crucial part of reality: not every user browses over a stable fiber connection. The Network Information API closes this gap by providing client side information about current connection quality, so an application can behave adaptively instead of shipping the maximum amount of data to everyone by default.

Through navigator.connection, the Network Information API exposes properties such as effectiveType, downlink and the particularly important saveData flag. Applications with many images, videos or heavy JavaScript bundles can deliver deliberately reduced variants based on these values, for example smaller image resolutions on a detected 2G like connection, or disabling automatic video preload when data saver mode is active.

An important note: the Network Information API is deliberately coarse grained. For privacy reasons it does not provide exact bandwidth values or location information, only categories that are sufficient for adaptive decisions without making the user uniquely identifiable.

2. navigator.connection in detail

The central object of the Network Information API is navigator.connection, a NetworkInformation object with several read only properties. type returns the physical connection type such as "wifi", "cellular" or "ethernet", but is now restricted to "unknown" in most browsers for privacy reasons. Considerably more reliable and practically relevant is effectiveType, which sorts the actually measured connection quality into four categories.

In addition, downlink provides an estimated bandwidth in megabits per second and rtt the estimated round trip time in milliseconds. Both values of the Network Information API are deliberately rounded and updated with a delay to make fingerprinting harder, but they are entirely sufficient for coarse categorization such as "fast connection" versus "slow connection".

// Read the current connection quality
function getConnectionInfo() {
  const connection =
    navigator.connection ||
    navigator.mozConnection ||
    navigator.webkitConnection;

  if (!connection) {
    return { supported: false };
  }

  return {
    supported: true,
    effectiveType: connection.effectiveType, // "slow-2g" | "2g" | "3g" | "4g"
    downlinkMbps: connection.downlink,
    rttMs: connection.rtt,
    saveData: connection.saveData,
  };
}

console.log(getConnectionInfo());

3. Using effectiveType instead of the physical connection type

The four values of effectiveType in the Network Information API, "slow-2g", "2g", "3g" and "4g", do not describe the physical technology but a measured, effective quality. A WiFi connection with a poor signal can well be classified as "3g", while a good 4G mobile connection appears as "4g". This categorization is therefore more practically relevant than the physical connection type, because it reflects the actual user experience rather than a technical property that is less indicative of load time.

For image galleries, video streaming or infinite scroll feeds, effectiveType translates directly into decisions: at "slow-2g" or "2g", only low resolution images are loaded and video autoplay is disabled, at "4g" the application can be more generous with resources. The Network Information API makes this adaptation possible without relying on server side device detection via user agent.

// Choose image quality based on effective connection type
function pickImageQuality() {
  const connection = navigator.connection;
  if (!connection) return "high"; // Default when unsupported

  switch (connection.effectiveType) {
    case "slow-2g":
    case "2g":
      return "low";
    case "3g":
      return "medium";
    default:
      return "high";
  }
}

const quality = pickImageQuality();
imageElement.src = `/images/hero-${quality}.webp`;

4. Properly respecting the save-data preference

Besides effectiveType, the saveData flag of the Network Information API is the most important signal for data conscious behavior. When a user enables data saver mode in the system settings of their Android device or Chrome browser, the browser sets navigator.connection.saveData to true and additionally sends the HTTP header Save-Data: on with every request. This signal is an explicit user decision and should be respected regardless of the measured connection quality.

Unlike effectiveType, which is a snapshot of network quality, saveData expresses a deliberate preference to save data volume even on a fast connection, for example while abroad with expensive roaming. Applications that ignore this signal and still deliver high resolution images or autoplay videos undermine an explicit user decision and should absolutely avoid that.

// Respect an explicit user preference for reduced data usage
function shouldLoadHighResAssets() {
  const connection = navigator.connection;
  if (!connection) return true;

  // saveData is a deliberate user choice — always honor it,
  // regardless of the measured connection quality.
  if (connection.saveData) return false;

  return connection.effectiveType === "4g";
}

if (!shouldLoadHighResAssets()) {
  document.documentElement.classList.add("reduced-data-mode");
}

5. Reacting dynamically to connection changes

Connection quality is not a static value, a user switches from WiFi to mobile data, leaves an area with poor reception, or enables data saver mode on the go. The Network Information API fires a change event on navigator.connection for every detected change, which an application can react to in order to adjust ongoing downloads or throttle future prefetching.

In practice this means a streaming application can downgrade video quality live during playback as soon as effectiveType switches from "4g" to "3g", instead of only reacting once visible rebuffering occurs. This proactive adaptation through the Network Information API improves the perceived user experience considerably compared to purely reactive behavior.

// React to live connection changes
const connection = navigator.connection;

if (connection) {
  connection.addEventListener("change", () => {
    console.log(`Connection changed: ${connection.effectiveType}`);

    if (connection.effectiveType === "slow-2g" || connection.saveData) {
      videoPlayer.setQuality("360p");
    } else if (connection.effectiveType === "4g") {
      videoPlayer.setQuality("1080p");
    }
  });
}

6. The history of the Battery Status API

Unlike the Network Information API, the once standardized Battery Status API has undergone a remarkable retreat. Originally, navigator.getBattery() provided charging state, charge percentage and estimated charging and discharging time, intended for applications that should automatically work more resource consciously at low battery. Security researchers showed, however, that the combination of charge percentage, discharge rate and timestamp could be abused as a fingerprinting vector to recognize users across multiple websites.

As a result, Firefox, Safari and practically all mobile browsers removed the Battery Status API entirely. Chrome technically still supports navigator.getBattery() on desktop systems, but practically no production project should rely on it today, because the API simply does not exist in most environments, and even where it does exist, it could be removed at any time as well.

7. Practical alternatives to the Battery API

Because the Battery Status API is practically no longer available, applications that want to react to low battery must combine other signals. A pragmatic approach: the Network Information API combined with the Page Visibility API and a general "reduced motion" preference through prefers-reduced-motion covers most of the original use cases without opening a fingerprinting vector.

For applications that genuinely depend on real battery state, such as specialized progressive web apps for field service devices, often the only path left is a native wrapper app with Capacitor or an Electron application that queries battery state through native operating system APIs instead of through the browser. The blanket expectation that a pure web application in the browser has access to precise battery telemetry simply no longer matches the state of the art.

// Practical substitute: combine available signals instead of the Battery API
function shouldReduceActivity() {
  const connection = navigator.connection;
  const prefersReducedMotion = window.matchMedia(
    "(prefers-reduced-motion: reduce)"
  ).matches;

  const poorConnection =
    connection?.saveData ||
    connection?.effectiveType === "slow-2g" ||
    connection?.effectiveType === "2g";

  return poorConnection || prefersReducedMotion;
}

if (shouldReduceActivity()) {
  disableBackgroundAnimations();
  pauseAutoRefresh();
}

8. Server side evaluation through Client Hints

Besides the client side Network Information API, the same signals can also be evaluated server side through HTTP Client Hints, without JavaScript having to run at all. With the response header Accept-CH: Downlink, ECT, Save-Data, a server requests these hints, and the browser automatically sends them with subsequent requests. A server can then decide as early as the first HTML response whether to serve low resolution images, instead of only adjusting client side after loading.

This approach is especially valuable for server side rendering and image CDNs that deliver adaptive image sizes through URL parameters. The combination of the client side Network Information API for dynamic re adjustment and Client Hints for the initial response covers practically every optimization scenario, without a user noticing a visible delay from a later switch in image quality.

9. Network and battery signals compared

Choosing the right signal for adaptive behavior depends heavily on which user or device behavior is actually relevant.

In practice, the Network Information API together with prefers-reduced-motion and the Page Visibility API forms a robust trio that covers most use cases the Battery API used to be wrongly reached for. This combination works considerably more reliably across browsers and without a privacy risk.

10. Summary

The Network Information API is a practical, production ready tool for adapting web applications to a user's actual connection quality. With effectiveType, downlink and especially the saveData flag, image quality, video resolution and prefetching behavior can be controlled dynamically, without relying on inaccurate user agent heuristics.

The Battery Status API, on the other hand, now belongs among the withdrawn web APIs, removed for privacy reasons because it could be abused as a fingerprinting vector. Anyone who wants to react to battery state today instead combines the Network Information API with prefers-reduced-motion and the Page Visibility API, a combination that works reliably across browsers and opens no new privacy risks.

11. FAQ: Network Information API and Battery API