Page Lifecycle API

Philip Walton

Moderne Browser pausieren oder verwerfen manchmal Seiten, wenn die Systemressourcen knapp sind. In Zukunft sollen Browser dies proaktiv tun, um weniger Strom und Arbeitsspeicher zu verbrauchen. Die Page Lifecycle API bietet Lebenszyklus-Hooks, mit denen Ihre Seiten diese Browsereingriffe sicher verarbeiten können, ohne die Nutzerfreundlichkeit zu beeinträchtigen. Sehen Sie sich die API an, um zu entscheiden, ob Sie diese Funktionen in Ihrer Anwendung implementieren sollten.

Hintergrund

Der Anwendungslebenszyklus ist eine wichtige Methode, mit der moderne Betriebssysteme Ressourcen verwalten. Unter Android, iOS und aktuellen Windows-Versionen können Apps jederzeit vom Betriebssystem gestartet und angehalten werden. So können diese Plattformen Ressourcen optimieren und dorthin umverteilen, wo sie den Nutzern am meisten nutzen.

Im Web gab es bisher keinen solchen Lebenszyklus und Apps konnten unbegrenzt weiterlaufen. Wenn viele Webseiten gleichzeitig ausgeführt werden, können wichtige Systemressourcen wie Arbeitsspeicher, CPU, Akku und Netzwerk überlastet werden, was zu einer schlechten Nutzererfahrung führt.

Die Webplattform hat zwar schon lange Ereignisse im Zusammenhang mit Lebenszyklusstatus, z. B. load, unload und visibilitychange, mit diesen Ereignissen können Entwickler jedoch nur auf von Nutzern initiierte Änderungen des Lebenszyklusstatus reagieren. Damit das Web auf Geräten mit geringer Leistung zuverlässig funktioniert und generell auf allen Plattformen ressourcenschonender ist, benötigen Browser eine Möglichkeit, Systemressourcen proaktiv zurückzufordern und neu zuzuweisen.

Tatsächlich ergreifen Browser heute bereits aktive Maßnahmen zur Ressourceneinsparung für Seiten in Hintergrund-Tabs. Viele Browser (insbesondere Chrome) würden dies gerne noch viel stärker tun, um ihren Ressourcenverbrauch insgesamt zu senken.

Das Problem ist, dass Entwickler sich nicht auf diese Art von systeminitiierten Eingriffen vorbereiten können und nicht einmal wissen, dass sie stattfinden. Das bedeutet, dass Browser konservativ sein müssen, da sonst Webseiten beschädigt werden können.

Die Page Lifecycle API versucht, dieses Problem auf folgende Weise zu lösen:

• Einführung und Standardisierung des Konzepts der Lebenszyklusstatus im Web.
• Definition neuer, systeminitiierter Status, mit denen Browser die Ressourcen begrenzen können, die von ausgeblendeten oder inaktiven Tabs verbraucht werden.
• Erstellen neuer APIs und Ereignisse, mit denen Webentwickler auf Übergänge zu und von diesen neuen systeminitiierten Status reagieren können.

Diese Lösung bietet die Vorhersagbarkeit, die Webentwickler benötigen, um widerstandsfähige Anwendungen zu entwickeln. Außerdem können Browser die Systemressourcen aggressiver optimieren, was letztendlich allen Webnutzern zugutekommt.

Im Rest dieses Beitrags werden die neuen Funktionen für den Seitenlebenszyklus vorgestellt und ihre Beziehung zu den vorhandenen Status und Ereignissen der Webplattform erläutert. Außerdem enthält es Empfehlungen und Best Practices für die Arten von Arbeit, die Entwickler in den einzelnen Bundesstaaten ausführen sollten (und nicht ausführen sollten).

Übersicht über die Status und Ereignisse des Seitenlebenszyklus

Alle Status des Seitenlebenszyklus sind diskret und schließen sich gegenseitig aus. Das bedeutet, dass eine Seite immer nur einen Status haben kann. Die meisten Änderungen am Lebenszyklusstatus einer Seite können in der Regel über DOM-Ereignisse beobachtet werden. Ausnahmen finden Sie in den Entwicklerempfehlungen für jeden Status.

Am besten lassen sich die Status des Seitenlebenszyklus und die Ereignisse, die Übergänge zwischen ihnen signalisieren, anhand eines Diagramms erklären:

Bundesstaaten

In der folgenden Tabelle werden die einzelnen Status ausführlich erläutert. Außerdem werden die möglichen Status aufgeführt, die vor und nach dem Ereignis auftreten können, sowie die Ereignisse, mit denen Entwickler Änderungen beobachten können.

Ereignisse

Browser senden viele Ereignisse, aber nur ein kleiner Teil davon signalisiert eine mögliche Änderung des Status des Seitenlebenszyklus. In der folgenden Tabelle sind alle Ereignisse aufgeführt, die sich auf den Lebenszyklus beziehen, und es wird aufgelistet, in welche Status sie übergehen können und von welchen Status aus.

* Hinweist auf ein neues Ereignis, das von der Page Lifecycle API definiert wurde

In Chrome 68 hinzugefügte neue Funktionen

Das vorherige Diagramm zeigt zwei Status, die vom System und nicht vom Nutzer initiiert werden: gefroren und verworfen. Wie bereits erwähnt, frieren und schließen moderne Browser ausgeblendete Tabs gelegentlich (nach eigenem Ermessen), aber Entwickler können nicht wissen, wann dies geschieht.

In Chrome 68 können Entwickler jetzt beobachten, wann ein ausgeblendeter Tab eingefroren und wieder entfrostet wird. Dazu müssen sie nur auf die Ereignisse freeze und resume auf document achten.

document.addEventListener('freeze', (event) => {
  // The page is now frozen.
});

document.addEventListener('resume', (event) => {
  // The page has been unfrozen.
});

Ab Chrome 68 enthält das document-Objekt in der Desktopversion von Chrome die Eigenschaft wasDiscarded. Die Unterstützung für Android wird in diesem Problem erfasst. Wenn Sie wissen möchten, ob eine Seite auf einem ausgeblendeten Tab verworfen wurde, können Sie den Wert dieser Property beim Laden der Seite prüfen. Hinweis: Verworfene Seiten müssen neu geladen werden, damit sie wieder verwendet werden können.

if (document.wasDiscarded) {
  // Page was previously discarded by the browser while in a hidden tab.
}

Informationen dazu, was Sie bei den Ereignissen vom Typ freeze und resume beachten sollten und wie Sie mit dem Zurücksetzen von Seiten umgehen und sich darauf vorbereiten können, finden Sie in den Entwicklerempfehlungen für die einzelnen Status.

In den folgenden Abschnitten erhalten Sie einen Überblick darüber, wie diese neuen Funktionen in die vorhandenen Status und Ereignisse der Webplattform passen.

Status des Seitenlebenszyklus im Code beobachten

In den Status aktiv, passiv und ausgeblendet kann JavaScript-Code ausgeführt werden, der den aktuellen Status des Seitenlebenszyklus anhand vorhandener Webplattform-APIs ermittelt.

const getState = () => {
  if (document.visibilityState === 'hidden') {
    return 'hidden';
  }
  if (document.hasFocus()) {
    return 'active';
  }
  return 'passive';
};

Die Status frozen (eingefroren) und terminated (beendet) können dagegen nur in den jeweiligen Ereignis-Listenern (freeze und pagehide) erkannt werden, da sich der Status ändert.

Statusänderungen beobachten

Aufbauend auf der zuvor definierten Funktion getState() können Sie mit dem folgenden Code alle Änderungen des Seitenlebenszyklusstatus beobachten.

// Stores the initial state using the `getState()` function (defined above).
let state = getState();

// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
  const prevState = state;
  if (nextState !== prevState) {
    console.log(`State change: ${prevState} >>> ${nextState}`);
    state = nextState;
  }
};

// Options used for all event listeners.
const opts = {capture: true};

// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
  window.addEventListener(type, () => logStateChange(getState()), opts);
});

// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
  // In the freeze event, the next state is always frozen.
  logStateChange('frozen');
}, opts);

window.addEventListener('pagehide', (event) => {
  // If the event's persisted property is `true` the page is about
  // to enter the back/forward cache, which is also in the frozen state.
  // If the event's persisted property is not `true` the page is
  // about to be unloaded.
  logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);

Dieser Code führt drei Dinge aus:

• Legt den Anfangszustand mit der Funktion getState() fest.
• Hiermit wird eine Funktion definiert, die einen nächsten Status akzeptiert und bei einer Änderung die Statusänderungen in der Konsole protokolliert.
• Es werden Capture-Ereignis-Listener für alle erforderlichen Lebenszyklusereignisse hinzugefügt, die wiederum logStateChange() aufrufen und den nächsten Status übergeben.

Beachten Sie, dass alle Ereignis-Listener window hinzugefügt werden und alle {capture: true} übergeben. Das kann verschiedene Gründe haben:

• Nicht alle Ereignisse des Seitenlebenszyklus haben dasselbe Ziel. pagehide und pageshow werden bei window ausgelöst, visibilitychange, freeze und resume bei document und focus und blur bei ihren jeweiligen DOM-Elementen.
• Die meisten dieser Ereignisse werden nicht weitergereicht. Das bedeutet, dass es nicht möglich ist, einem gemeinsamen übergeordneten Element nicht aufzeichnende Ereignis-Listener hinzuzufügen und alle zu beobachten.
• Die Erfassungsphase wird vor der Ziel- oder Blasenphase ausgeführt. Wenn Sie dort Listener hinzufügen, werden sie ausgeführt, bevor sie von anderen Code-Elementen abgebrochen werden können.

Entwicklerempfehlungen für jeden Status

Als Entwickler müssen Sie die Status des Seitenlebenszyklus verstehen und wissen, wie Sie sie im Code berücksichtigen. Denn die Art der Arbeit, die Sie ausführen sollten (und nicht ausführen sollten), hängt weitgehend davon ab, in welchem Status sich Ihre Seite befindet.

Es macht beispielsweise keinen Sinn, dem Nutzer eine vorübergehende Benachrichtigung anzuzeigen, wenn die Seite ausgeblendet ist. Dieses Beispiel ist ziemlich offensichtlich, aber es gibt auch andere Empfehlungen, die nicht so offensichtlich sind, die aber dennoch erwähnt werden sollten.

Da Zuverlässigkeit und Reihenfolge von Lebenszyklusereignissen nicht in allen Browsern einheitlich implementiert sind, ist die Verwendung von PageLifecycle.js die einfachste Möglichkeit, der Empfehlung in der Tabelle zu folgen.

Zu vermeidende APIs mit altem Lebenszyklus

Die folgenden Ereignisse sollten nach Möglichkeit vermieden werden.

Das Unload-Ereignis

Viele Entwickler behandeln das Ereignis unload als garantierten Rückruf und verwenden es als Signal zum Ende der Sitzung, um den Status zu speichern und Analysedaten zu senden. Das ist jedoch äußerst unzuverlässig, insbesondere auf Mobilgeräten. Das Ereignis unload wird in vielen gängigen Situationen nicht ausgelöst, z. B. wenn ein Tab über den Tab-Schnellzugriff auf einem Mobilgerät geschlossen oder die Browser-App über den App-Schnellzugriff geschlossen wird.

Aus diesem Grund sollten Sie immer das Ereignis visibilitychange verwenden, um zu bestimmen, wann eine Sitzung endet. Der ausgeblendete Status ist der letzte zuverlässige Zeitpunkt, um App- und Nutzerdaten zu speichern.

Außerdem kann das Vorhandensein eines registrierten unload-Ereignis-Handlers (über onunload oder addEventListener()) verhindern, dass Browser Seiten für ein schnelleres Zurück- und Vorwärtsladen in den Back-Forward-Cache legen.

In allen modernen Browsern wird empfohlen, zum Erkennen möglicher Seitenentladungen (terminated-Status) immer das Ereignis pagehide anstelle des Ereignisses unload zu verwenden. Wenn Sie Internet Explorer 10 und niedriger unterstützen müssen, sollten Sie das Ereignis pagehide erkennen und unload nur verwenden, wenn der Browser pagehide nicht unterstützt:

const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';

window.addEventListener(terminationEvent, (event) => {
  // Note: if the browser is able to cache the page, `event.persisted`
  // is `true`, and the state is frozen rather than terminated.
});

Das „beforeunload“-Ereignis

Das beforeunload-Ereignis weist ein ähnliches Problem wie das unload-Ereignis auf: Bisher konnte das Vorhandensein eines beforeunload-Ereignisses verhindern, dass Seiten für den Back-Forward-Cache infrage kommen. Für moderne Browser gilt diese Einschränkung nicht. Einige Browser lösen das Ereignis beforeunload jedoch nicht aus, wenn versucht wird, eine Seite in den Rück-/Vorwärts-Cache zu setzen. Das Ereignis ist also nicht zuverlässig als Signal für das Ende der Sitzung. Außerdem erfordern einige Browser (einschließlich Chrome) eine Nutzerinteraktion auf der Seite, bevor das beforeunload-Ereignis ausgelöst wird. Das wirkt sich weiter auf die Zuverlässigkeit aus.

Ein Unterschied zwischen beforeunload und unload besteht darin, dass es legitime Verwendungen von beforeunload gibt. Beispiel: Sie möchten den Nutzer warnen, dass nicht gespeicherte Änderungen verloren gehen, wenn er die Seite weiterhin entlädt.

Da es gute Gründe für die Verwendung von beforeunload gibt, sollten Sie beforeunload-Listener nur hinzufügen, wenn ein Nutzer nicht gespeicherte Änderungen hat, und sie dann sofort nach dem Speichern entfernen.

Das ist also nicht zulässig, da ein beforeunload-Listener hier bedingungslos hinzugefügt wird:

addEventListener('beforeunload', (event) => {
  // A function that returns `true` if the page has unsaved changes.
  if (pageHasUnsavedChanges()) {
    event.preventDefault();

    // Legacy support for older browsers.
    return (event.returnValue = true);
  }
});

Führen Sie stattdessen Folgendes aus, da der beforeunload-Listener nur hinzugefügt und entfernt wird, wenn er benötigt wird:

const beforeUnloadListener = (event) => {
  event.preventDefault();
  
  // Legacy support for older browsers.
  return (event.returnValue = true);
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  removeEventListener('beforeunload', beforeUnloadListener);
});

Häufig gestellte Fragen

Warum gibt es keinen Status „Laden“?

Die Page Lifecycle API definiert Status als diskret und sich gegenseitig ausschließend. Da eine Seite entweder im aktiven, passiven oder ausgeblendeten Status geladen werden kann und der Status sich ändern oder die Seite sogar beendet werden kann, bevor das Laden abgeschlossen ist, macht ein separater Ladestatus in diesem Paradigma keinen Sinn.

Meine Seite erfüllt wichtige Aufgaben, wenn sie ausgeblendet ist. Wie kann ich verhindern, dass sie eingefroren oder verworfen wird?

Es gibt viele legitime Gründe, warum Webseiten nicht eingefroren werden sollten, während sie im ausgeblendeten Zustand ausgeführt werden. Das offensichtlichste Beispiel ist eine App, mit der Musik abgespielt wird.

Es gibt auch Situationen, in denen es riskant wäre, wenn Chrome eine Seite verwirft, z. B. wenn sie ein Formular mit nicht gesendeter Nutzereingabe enthält oder einen beforeunload-Handler hat, der warnt, wenn die Seite entladen wird.

Vorerst wird Chrome Seiten nur dann verwerfen, wenn sicher ist, dass dies keine Auswirkungen auf die Nutzer hat. Seiten, bei denen im ausgeblendeten Zustand eines der folgenden Ereignisse festgestellt wurde, werden nur bei extremen Ressourcenknappheit verworfen:

• Audiowiedergabe
• WebRTC verwenden
• Tabellentitel oder Favicon aktualisieren
• Benachrichtigungen anzeigen
• Push-Benachrichtigungen senden

Informationen zu den aktuellen Listenfunktionen, mit denen ermittelt wird, ob ein Tab sicher eingefroren oder verworfen werden kann, finden Sie unter Heuristiken zum Einfrieren und Verwerfen in Chrome.

Was ist der Back-Forward-Cache?

Der Back-Forward-Cache ist ein Begriff, der eine Navigationsoptimierung beschreibt, die einige Browser implementieren, um die Verwendung der Schaltflächen „Zurück“ und „Weiter“ zu beschleunigen.

Wenn ein Nutzer eine Seite verlässt, frieren diese Browser eine Version dieser Seite ein, damit sie schnell fortgesetzt werden kann, falls der Nutzer mit den Schaltflächen „Zurück“ oder „Weiter“ zurückwechselt. Hinweis: Wenn Sie einen unload-Ereignishandler hinzufügen, ist diese Optimierung nicht möglich.

Dieser Vorgang entspricht funktional dem Einfrieren von Browsern zur Schonung der CPU/des Akkus. Aus diesem Grund wird er als Teil des Lebenszyklusstatus gefroren betrachtet.

Wenn ich keine asynchronen APIs im gefrorenem oder beendeten Zustand ausführen kann, wie kann ich dann Daten in IndexedDB speichern?

In den Status „Gefroren“ und „Beendet“ werden einfrierbare Aufgaben in den Aufgabenwarteschlangen einer Seite angehalten. Das bedeutet, dass asynchrone und callbackbasierte APIs wie IndexedDB nicht zuverlässig verwendet werden können.

Künftig werden wir IDBTransaction-Objekten die Methode commit() hinzufügen. Damit können Entwickler Transaktionen ausführen, die nur zum Schreiben gedacht sind und keine Callbacks erfordern. Wenn der Entwickler also nur Daten in IndexedDB schreibt und keine komplexe Transaktion ausführt, die aus Lese- und Schreibvorgängen besteht, kann die commit()-Methode abgeschlossen werden, bevor Task-Queues angehalten werden (vorausgesetzt, die IndexedDB-Datenbank ist bereits geöffnet).

• Sitzungsspeicher verwenden:Der Sitzungsspeicher ist synchron und bleibt nach dem Leeren der Seite erhalten.
• IndexedDB über Ihren Service Worker verwenden:Ein Service Worker kann Daten in IndexedDB speichern, nachdem die Seite beendet oder verworfen wurde. Im freeze- oder pagehide-Ereignislistener können Sie Daten über postMessage() an Ihren Service Worker senden. Der Service Worker kann dann das Speichern der Daten übernehmen.

App im eingefrorenen und verworfenen Zustand testen

Wenn Sie testen möchten, wie sich Ihre App im eingefrorenen und im verworfenen Zustand verhält, können Sie chrome://discards aufrufen, um einen Ihrer geöffneten Tabs einzufrieren oder zu verwerfen.

So können Sie dafür sorgen, dass Ihre Seite die Ereignisse freeze und resume sowie das Flag document.wasDiscarded richtig verarbeitet, wenn Seiten nach dem Zurücksetzen neu geladen werden.

Zusammenfassung

Entwickler, die die Systemressourcen der Geräte ihrer Nutzer respektieren möchten, sollten ihre Apps mit Blick auf die Status des Seitenlebenszyklus entwickeln. Es ist wichtig, dass Webseiten in Situationen, in denen der Nutzer dies nicht erwartet, nicht zu viele Systemressourcen verbrauchen.

Je mehr Entwickler die neuen APIs für den Seitenlebenszyklus implementieren, desto sicherer können Browser Seiten einfrieren und verwerfen, die nicht verwendet werden. Das bedeutet, dass Browser weniger Arbeitsspeicher, CPU, Akku und Netzwerkressourcen verbrauchen, was für Nutzer von Vorteil ist.