Screen Wake Lock API: Bildschirm gezielt wach halten

1. Warum Bildschirme überhaupt einschlafen

Betriebssysteme dimmen und sperren Bildschirme nach einer gewissen Inaktivität, um Akku zu sparen. Das ist in den allermeisten Fällen richtig, wird aber zum Problem, sobald eine Webseite den Nutzer aktiv begleiten soll, ohne dass dieser ständig den Touchscreen berührt. Ein Rezept-Widget, ein Trainings-Timer oder eine Präsentation im Vollbildmodus sind typische Kandidaten.

Vor der Wake Lock API griffen Entwickler zu Workarounds: ein unsichtbares, endlos loopendes Video abspielen oder alle paar Sekunden per JavaScript minimal scrollen. Beides funktionierte unzuverlässig, kostete unnötig Akku und wirkte wie ein Hack, weil es genau das war. Die native API ersetzt diese Tricks durch eine explizite, vom Browser kontrollierte Anfrage.

2. Das Grundprinzip: navigator.wakeLock.request()

Der Einstieg erfolgt über navigator.wakeLock.request('screen'). Der Aufruf gibt ein Promise zurück, das mit einem WakeLockSentinel-Objekt aufgelöst wird, sobald der Browser dem Wunsch zustimmt. Aktuell kennt die Spezifikation nur den Typ 'screen', künftige Erweiterungen für andere Wach-Zustände sind aber im Gespräch.

Wichtig ist: Die Anfrage muss aus einem sicheren Kontext (HTTPS) und in der Regel als Reaktion auf eine Nutzerinteraktion erfolgen, ähnlich wie bei der Fullscreen- oder Notifications-API. Ein Lock, der beim bloßen Laden der Seite ohne jede Interaktion gesetzt wird, kann vom Browser abgelehnt oder gar nicht erst angeboten werden.

let wakeLockSentinel = null;

async function requestWakeLock() {
  try {
    wakeLockSentinel = await navigator.wakeLock.request('screen');
    console.log('Wake Lock aktiv');

    wakeLockSentinel.addEventListener('release', () => {
      console.log('Wake Lock wurde freigegeben');
    });
  } catch (err) {
    console.error(`Wake Lock fehlgeschlagen: ${err.name}, ${err.message}`);
  }
}

document.querySelector('#start-cooking').addEventListener('click', requestWakeLock);

3. Locks korrekt wieder freigeben

Ein aktiver Wake Lock ist eine Ressource, die man nicht vergessen darf freizugeben. Sobald die Aktion beendet ist, etwa das Rezept fertig gekocht oder der Ladevorgang abgeschlossen, ruft man sentinel.release() auf. Das Sentinel-Objekt wird danach ungültig und muss bei erneutem Bedarf neu angefordert werden. Ein zweiter, erneuter Aufruf von release() auf demselben Objekt führt in den meisten Implementierungen zu keinem Fehler, es empfiehlt sich trotzdem, den eigenen Zustand sauber zu verwalten, statt sich auf dieses tolerante Verhalten zu verlassen.

Ein häufig übersehener Sonderfall: Der Browser gibt den Lock automatisch frei, sobald der Tab in den Hintergrund wechselt, minimiert wird oder der Bildschirm gesperrt wird. Kehrt der Nutzer zur Seite zurück, ist der alte Sentinel bereits invalide, selbst wenn kein release() aufgerufen wurde. Die eigene Logik muss diesen Zustand erkennen und den Lock bei Bedarf neu anfordern.

async function releaseWakeLock() {
  if (wakeLockSentinel) {
    await wakeLockSentinel.release();
    wakeLockSentinel = null;
  }
}

document.querySelector('#stop-cooking').addEventListener('click', releaseWakeLock);

4. Reaktion auf Sichtbarkeitswechsel

Da der Lock beim Wechsel in den Hintergrund automatisch verfällt, lohnt es sich, auf das visibilitychange-Ereignis des Dokuments zu hören. Wird der Tab wieder sichtbar und war zuvor ein Lock gewünscht, kann die Anwendung den Wake Lock ohne erneute Nutzerinteraktion neu anfordern, denn die ursprüngliche Zustimmung gilt als weiterhin gegeben.

Diese Kombination aus Sichtbarkeits-Listener und Re-Request macht die Wake-Lock-Logik robust gegenüber App-Wechseln auf Mobilgeräten, bei denen Nutzer kurz eine andere App öffnen und danach zurückkehren. Ohne diesen Mechanismus würde der Bildschirm nach der Rückkehr erneut einschlafen können, obwohl die Aktivität eigentlich noch läuft.

document.addEventListener('visibilitychange', async () => {
  if (wakeLockWanted && document.visibilityState === 'visible') {
    wakeLockSentinel = await navigator.wakeLock.request('screen');
  }
});

5. Feature-Detection und Fallback

Die API ist noch nicht überall verfügbar, insbesondere ältere mobile Browser und einige Desktop-Browser unterstützen sie nicht vollständig. Ein einfacher Check auf 'wakeLock' in navigator genügt, um festzustellen, ob die Funktion angeboten wird, bevor man sie aufruft.

Fehlt die Unterstützung, sollte die Anwendung nicht einfach schweigen, sondern dem Nutzer eine dezente Information geben, etwa einen Hinweis, den Bildschirm manuell wach zu halten oder die Displayzeit in den Systemeinstellungen zu erhöhen. Wichtig ist, dass die Kernfunktion der Seite auch ohne Wake Lock vollständig nutzbar bleibt, die API ist reine Komfortfunktion.

6. Typische Anwendungsfälle

Neben Rezept-Apps und Video-Konferenz-Tools profitieren Präsentations-Werkzeuge, Kiosk-Systeme, Fitness-Timer und Dashboards in Leitständen von der API. Überall dort, wo Inhalte über längere Zeit ohne Touch-Interaktion betrachtet werden sollen, ist der Wake Lock die passende Lösung.

Auch Ladebildschirme bei langwierigen Uploads oder Datei-Konvertierungen sind ein gutes Beispiel: Der Nutzer wartet aktiv auf ein Ergebnis, will aber nicht ständig den Bildschirm antippen, nur um ihn wach zu halten. Ein Wake Lock während des Ladevorgangs, der sofort nach Abschluss wieder freigegeben wird, verbessert hier spürbar die Erfahrung.

Im Bildungsbereich profitieren interaktive Lern-Apps, in denen ein Nutzer einem längeren Erklärvideo oder einer geführten Übung folgt, ebenfalls von einem stabilen Wake Lock, denn ein dazwischen einschlafender Bildschirm unterbricht den Lernfluss und zwingt zum erneuten Entsperren mitten im Gedankengang. Ähnliches gilt für Meditations- und Atem-Apps, die über mehrere Minuten eine visuelle Führung anzeigen, ohne dass der Nutzer die Hände frei hat, um den Bildschirm zu berühren. Auch Self-Checkout-Terminals oder digitale Aushänge in Wartebereichen, die über eine Webseite betrieben werden, setzen häufig auf die Wake Lock API, um ohne separate Kiosk-Software auszukommen und trotzdem dauerhaft sichtbar zu bleiben.

7. Akkuverbrauch und verantwortungsvoller Einsatz

Ein dauerhaft heller Bildschirm ist einer der größten Akkuverbraucher mobiler Geräte. Die Wake Lock API ist deshalb kein Freifahrtschein, sie überall dort einzusetzen, wo es bequem erscheint, sondern ein gezieltes Werkzeug für klar abgegrenzte Zeiträume mit echtem Bedarf.

Guter Stil bedeutet, dem Nutzer die Kontrolle zu geben: ein sichtbarer Schalter, der anzeigt, ob der Bildschirm aktuell wach gehalten wird, und der sich jederzeit deaktivieren lässt. So bleibt nachvollziehbar, warum der Akku schneller sinkt, und der Nutzer behält die Entscheidungshoheit über sein Gerät. Eine automatische Deaktivierung nach einer sinnvollen Höchstdauer, etwa nach zwei Stunden ununterbrochener Aktivität, ist ebenfalls ein guter Schutzmechanismus gegen versehentlich dauerhaft aktive Locks, wenn eine Anwendung im Hintergrund vergessen wurde.

8. Sicherheits- und Berechtigungsmodell

Anders als bei Kamera oder Standort fragt der Browser bei der Wake Lock API keinen sichtbaren Berechtigungsdialog ab, die Kontrolle erfolgt implizit über den sicheren Kontext und die Nutzerinteraktions-Anforderung. Einige Browser erlauben zusätzlich, das Verhalten über eine Permissions-Policy im Header Permissions-Policy: screen-wake-lock=() für eingebettete iframes einzuschränken.

Das ist besonders für Seiten mit Drittanbieter-Inhalten relevant: Ein eingebettetes Werbe-Widget soll normalerweise nicht den Bildschirm der gesamten Seite wach halten können. Über die Permissions-Policy lässt sich diese Fähigkeit gezielt nur den eigenen, vertrauenswürdigen Frames zuweisen. Ein regelmäßiger Audit der eigenen Permissions-Policy-Konfiguration, insbesondere nach dem Hinzufügen neuer Drittanbieter-Skripte, gehört deshalb zu einer soliden Sicherheitsroutine dazu.

9. Ein vollständiges Praxisbeispiel

In der Praxis kapselt man Anforderung, Freigabe und Sichtbarkeits-Handling am besten in einer kleinen wiederverwendbaren Klasse oder Utility-Funktion, die von jeder Komponente unabhängig genutzt werden kann. So bleibt die eigentliche Anwendungslogik frei von API-Details und der Wake-Lock-Zustand wird zentral verwaltet.

Der folgende Ausschnitt zeigt ein Muster, das Anforderung, automatische Wiederherstellung nach Tab-Wechsel und sauberes Aufräumen beim Verlassen der Seite kombiniert. Die Tabelle danach vergleicht die früher gängigen Workarounds mit der nativen API. Für den produktiven Einsatz lohnt es sich zusätzlich, ein zentrales Logging einzubauen, das fehlgeschlagene Requests protokolliert, damit sich Muster über verschiedene Gerätetypen und Browser-Versionen hinweg erkennen lassen, statt jeden Einzelfall isoliert zu debuggen.

class WakeLockManager {
  #sentinel = null;
  #wanted = false;

  async enable() {
    this.#wanted = true;
    if (!('wakeLock' in navigator)) return false;
    try {
      this.#sentinel = await navigator.wakeLock.request('screen');
      return true;
    } catch {
      return false;
    }
  }

  async disable() {
    this.#wanted = false;
    if (this.#sentinel) {
      await this.#sentinel.release();
      this.#sentinel = null;
    }
  }

  init() {
    document.addEventListener('visibilitychange', async () => {
      if (this.#wanted && document.visibilityState === 'visible' && !this.#sentinel) {
        await this.enable();
      }
    });
  }
}

const wakeLock = new WakeLockManager();
wakeLock.init();

10. Zusammenfassung

11. FAQ: Screen Wake Lock API: Das Wichtigste auf einen Blick