Network Information API und Battery API: adaptive Web-Apps bauen

1. Warum Netzwerk- und Akkuzustand für Web-Apps zählen

Eine Webanwendung, die für alle Nutzer dieselben hochauflösenden Bilder, dasselbe Video und dieselbe Menge an Prefetching ausliefert, ignoriert einen entscheidenden Teil der Realität: Nicht jeder Nutzer surft über eine stabile Glasfaserverbindung. Die Network Information API schließt diese Lücke, indem sie clientseitig Informationen über die aktuelle Verbindungsqualität bereitstellt, sodass eine Anwendung sich adaptiv verhalten kann, statt pauschal die maximale Datenmenge auszuliefern.

Über navigator.connection liefert die Network Information API Eigenschaften wie effectiveType, downlink und das besonders wichtige saveData-Flag. Anwendungen mit vielen Bildern, Videos oder aufwendigen JavaScript-Bundles können auf Basis dieser Werte gezielt reduzierte Varianten ausliefern, etwa kleinere Bildauflösungen bei einer erkannten 2G-ähnlichen Verbindung oder das Deaktivieren von automatischem Video-Preload bei aktiviertem Datensparmodus.

Wichtig für die Einordnung: Die Network Information API ist bewusst grob granular gehalten. Aus Datenschutzgründen liefert sie keine exakten Bandbreitenwerte oder Standortinformationen, sondern lediglich Kategorien, die für adaptive Entscheidungen ausreichen, ohne den Nutzer eindeutig identifizierbar zu machen.

2. navigator.connection im Detail

Das zentrale Objekt der Network Information API ist navigator.connection, ein NetworkInformation-Objekt mit mehreren schreibgeschützten Eigenschaften. type liefert die physische Verbindungsart wie "wifi", "cellular" oder "ethernet", ist aber in den meisten Browsern aus Datenschutzgründen mittlerweile auf "unknown" beschränkt. Deutlich zuverlässiger und praxisrelevanter ist effectiveType, das die tatsächlich gemessene Verbindungsqualität in vier Kategorien einteilt.

Zusätzlich liefert downlink eine geschätzte Bandbreite in Megabit pro Sekunde und rtt die geschätzte Round-Trip-Time in Millisekunden. Beide Werte der Network Information API sind bewusst gerundet und verzögert aktualisiert, um Fingerprinting zu erschweren, für grobe Kategorisierungen wie "schnelle Verbindung" versus "langsame Verbindung" reichen sie aber vollkommen aus.

// 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. effectiveType statt physischer Verbindungsart nutzen

Die vier Werte von effectiveType in der Network Information API, "slow-2g", "2g", "3g" und "4g", beschreiben nicht die physische Technologie, sondern eine gemessene, effektive Qualität. Ein WLAN mit schlechtem Signal kann durchaus als "3g" eingestuft werden, während eine gute 4G-Mobilfunkverbindung als "4g" erscheint. Diese Kategorisierung ist deshalb praktisch relevanter als der physische Verbindungstyp, weil sie das tatsächliche Nutzererlebnis widerspiegelt statt einer technischen Eigenschaft, die für die Ladezeit weniger aussagekräftig ist.

Für Bildergalerien, Video-Streaming oder Infinite-Scroll-Feeds lässt sich effectiveType direkt in Entscheidungen übersetzen: Bei "slow-2g" oder "2g" werden nur niedrig aufgelöste Bilder geladen und Video-Autoplay deaktiviert, bei "4g" darf die Anwendung großzügiger mit Ressourcen umgehen. Die Network Information API macht diese Anpassung möglich, ohne auf serverseitige Geräteerkennung per User-Agent angewiesen zu sein.

// 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. Der Datensparmodus save-data richtig respektieren

Neben effectiveType ist das saveData-Flag der Network Information API das wichtigste Signal für datensparsames Verhalten. Aktiviert ein Nutzer in den Systemeinstellungen seines Android-Geräts oder Chrome-Browsers den Datensparmodus, setzt der Browser navigator.connection.saveData auf true und sendet zusätzlich den HTTP-Header Save-Data: on bei jeder Anfrage. Dieses Signal ist eine explizite Nutzerentscheidung und sollte unabhängig von der gemessenen Verbindungsqualität respektiert werden.

Anders als effectiveType, das eine Momentaufnahme der Netzwerkqualität ist, drückt saveData eine bewusste Präferenz aus, auch bei schneller Verbindung Datenvolumen zu sparen, etwa im Ausland mit teurem Roaming. Anwendungen, die dieses Signal ignorieren und trotzdem hochauflösende Bilder oder Autoplay-Videos ausliefern, unterlaufen eine explizite Nutzerentscheidung und sollten das unbedingt vermeiden.

// 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. Dynamisch auf Verbindungswechsel reagieren

Verbindungsqualität ist kein statischer Wert, ein Nutzer wechselt von WLAN zu Mobilfunk, verlässt eine Zone mit schlechtem Empfang oder aktiviert unterwegs den Datensparmodus. Die Network Information API feuert bei jeder erkannten Änderung ein change-Event auf navigator.connection, auf das eine Anwendung reagieren kann, um laufende Downloads anzupassen oder zukünftiges Prefetching zu drosseln.

Praktisch bedeutet das: Eine Streaming-Anwendung kann die Video-Qualität während der Wiedergabe live herunterschalten, sobald effectiveType von "4g" auf "3g" wechselt, statt erst bei einem sichtbaren Rebuffering zu reagieren. Diese proaktive Anpassung über die Network Information API verbessert das wahrgenommene Nutzererlebnis deutlich gegenüber rein reaktivem Verhalten.

// 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. Die Geschichte der Battery Status API

Anders als die Network Information API hat die einst standardisierte Battery Status API einen bemerkenswerten Rückzug hinter sich. Ursprünglich stellte navigator.getBattery() Ladezustand, Ladeprozentsatz sowie geschätzte Lade- und Entladezeit bereit, gedacht für Anwendungen, die bei niedrigem Akkustand automatisch ressourcenschonender arbeiten sollten. Sicherheitsforscher zeigten jedoch, dass die Kombination aus Ladeprozentsatz, Entladerate und Zeitstempel als Fingerprinting-Vektor missbraucht werden konnte, um Nutzer über mehrere Websites hinweg wiederzuerkennen.

In der Folge entfernten Firefox, Safari und praktisch alle mobilen Browser die Battery Status API vollständig. Chrome unterstützt navigator.getBattery() zwar technisch weiterhin auf Desktop-Systemen, aber praktisch kein produktives Projekt sollte sich heute noch darauf verlassen, weil die API in den meisten Umgebungen schlicht nicht existiert und selbst dort, wo sie existiert, jederzeit ebenfalls entfernt werden könnte.

7. Alternativen zur Battery API in der Praxis

Weil die Battery Status API praktisch nicht mehr verfügbar ist, müssen Anwendungen, die auf niedrigen Akkustand reagieren wollen, andere Signale kombinieren. Ein pragmatischer Ansatz: Die Network Information API in Kombination mit der Page Visibility API und einer generellen "Reduced Motion"-Präferenz über prefers-reduced-motion deckt einen Großteil der ursprünglichen Anwendungsfälle ab, ohne einen Fingerprinting-Vektor zu öffnen.

Für Anwendungen, die tatsächlich auf echten Akkustand angewiesen sind, etwa spezialisierte Progressive Web Apps für Außendienst-Geräte, bleibt oft nur der Weg über eine native Wrapper-App mit Capacitor oder eine Electron-Anwendung, die den Akkustand über native Betriebssystem-APIs statt über den Browser abfragt. Die pauschale Erwartung, dass eine reine Web-Anwendung im Browser Zugriff auf präzise Akku-Telemetrie hat, entspricht schlicht nicht mehr dem Stand der Technik.

// 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-seitige Auswertung über Client Hints

Neben der clientseitigen Network Information API lassen sich dieselben Signale über HTTP Client Hints auch serverseitig auswerten, ohne dass JavaScript überhaupt ausgeführt werden muss. Mit dem Response-Header Accept-CH: Downlink, ECT, Save-Data fordert ein Server diese Hints an, der Browser sendet sie anschließend bei Folgeanfragen automatisch mit. Ein Server kann so schon bei der ersten HTML-Antwort entscheiden, ob niedrig aufgelöste Bilder ausgeliefert werden, statt erst nach dem Laden client-seitig nachzusteuern.

Dieser Ansatz ist besonders wertvoll für Server-Side-Rendering und Bild-CDNs, die adaptive Bildgrößen über URL-Parameter ausliefern. Die Kombination aus client-seitiger Network Information API für dynamische Nachjustierung und Client Hints für die initiale Antwort deckt praktisch alle Optimierungsszenarien ab, ohne dass ein Nutzer eine sichtbare Verzögerung durch nachträgliches Umschalten der Bildqualität bemerkt.

9. Netzwerk- und Akku-Signale im Vergleich

Die Wahl des richtigen Signals zur adaptiven Anpassung hängt stark davon ab, welches Verhalten des Nutzers oder Geräts tatsächlich relevant ist.

In der Praxis bildet die Network Information API zusammen mit prefers-reduced-motion und der Page Visibility API ein robustes Trio, das die meisten Anwendungsfälle abdeckt, für die früher fälschlicherweise die Battery API herangezogen wurde. Diese Kombination funktioniert browserübergreifend deutlich zuverlässiger und ohne Datenschutzrisiko.

10. Zusammenfassung

Die Network Information API ist ein praktisches, produktiv einsetzbares Werkzeug, um Webanwendungen an die tatsächliche Verbindungsqualität eines Nutzers anzupassen. Mit effectiveType, downlink und vor allem dem saveData-Flag lassen sich Bildqualität, Video-Auflösung und Prefetching-Verhalten dynamisch steuern, ohne auf ungenaue User-Agent-Heuristiken angewiesen zu sein.

Die Battery Status API dagegen gehört inzwischen zu den zurückgezogenen Web-APIs, entfernt aus Datenschutzgründen, weil sie sich als Fingerprinting-Vektor missbrauchen ließ. Wer heute auf Akkustand reagieren möchte, kombiniert stattdessen die Network Information API mit prefers-reduced-motion und der Page Visibility API, eine Kombination, die browserübergreifend zuverlässig funktioniert und keine neuen Datenschutzrisiken eröffnet.

11. FAQ: Network Information API und Battery API