API Page Lifecycle

Philip Walton

Aujourd'hui, les navigateurs récents suspendent parfois des pages ou les suppriment entièrement lorsque les ressources système sont limitées. À l'avenir, les navigateurs voudront le faire. de manière proactive, et consomment donc moins d'énergie et de mémoire. L'API Page Lifecycle fournit des hooks de cycle de vie pour que vos pages puissent gérer ces navigateurs en toute sécurité sans affecter l'expérience utilisateur. Examinez l'API pour déterminez si vous devez mettre en œuvre ces fonctionnalités dans votre application.

Contexte

Le cycle de vie d'une application est un moyen essentiel pour les systèmes d'exploitation modernes de gérer ressources. Sur Android, iOS et les versions récentes de Windows, vous pouvez démarrer et à tout moment par le système d'exploitation. Cela permet à ces plateformes de rationaliser et réaffecter les ressources là où elles profitent le mieux à l'utilisateur.

Sur le Web, ce cycle de vie n'a jamais existé, et les applications peuvent être conservées vivant indéfiniment. Avec un grand nombre de pages Web en cours d'exécution, le système critique des ressources comme la mémoire, le CPU, la batterie et le réseau peuvent faire l'objet d'une sursouscription, conduisant à une mauvaise expérience pour l'utilisateur final.

La plate-forme Web a depuis longtemps des événements liés aux états du cycle de vie - comme load, unload visibilitychange — ces événements ne permettent qu'aux développeurs pour répondre aux changements d'état du cycle de vie déclenchés par l'utilisateur. Pour que le Web fonctionne de manière fiable sur les appareils à faible puissance (et, en général, être plus attentif aux ressources (toutes plates-formes) les navigateurs ont besoin d'un moyen de récupérer et de réaffecter de façon proactive le système ressources.

De fait, les navigateurs prennent déjà des mesures actives pour préserver les ressources pour les pages des onglets en arrière-plan, car de nombreux navigateurs (en particulier Chrome) souhaitent dans ce sens, afin de réduire leur empreinte globale des ressources.

Le problème est que les développeurs n'ont aucun moyen de se préparer à ce type des interventions déclenchées par le système. Cela signifie les navigateurs doivent être prudents afin de ne pas altérer les pages Web.

L'API Page Lifecycle tente de résoudre ce problème en:

• Présentation et standardisation du concept d'état du cycle de vie sur le Web
• Définir de nouveaux états déclenchés par le système qui permettent aux navigateurs de limiter des ressources pouvant être utilisées par des onglets masqués ou inactifs.
• Créer des API et des événements qui permettent aux développeurs Web de répondre les transitions vers et depuis ces nouveaux états initiés par le système.

Cette solution offre aux développeurs Web la prévisibilité dont ils ont besoin pour créer résilientes aux interventions du système et aux navigateurs optimiser de manière agressive les ressources système, au final profitant à tous les internautes.

La suite de cet article présente les nouvelles fonctionnalités du cycle de vie de la page et explorer leur lien avec tous les états des plates-formes Web existantes et événements. Vous y trouverez également des recommandations et bonnes pratiques du travail que les développeurs devraient (et ne devraient pas) faire dans chaque État.

Présentation des états et des événements du cycle de vie des pages

Tous les états du cycle de vie de la page sont distincts et s'excluent mutuellement, ne peuvent être que dans un état à la fois. Et la plupart des modifications de l'état du cycle de vie d'une page sont généralement observables via des événements DOM (consultez les recommandations pour les développeurs pour chaque état pour connaître les exceptions).

Le moyen le plus simple d'expliquer les états du cycle de vie de la page, ainsi que les événements qui signalent des transitions entre elles sont représentées par un diagramme:

États

Le tableau suivant décrit chaque état en détail. Elle répertorie également les les états qui peuvent survenir avant et après, ainsi que les événements que les développeurs peuvent utiliser pour observer les changements.

Événements

Les navigateurs envoient de nombreux événements, mais seule une petite partie d'entre eux signalent une changement possible de l'état du cycle de vie de la page. Le tableau suivant présente tous les événements qui se rapportent au cycle de vie et répertorie les états vers et depuis lesquels ils peuvent passer.

* Indique un nouvel événement défini par l'API Page Lifecycle

Nouvelles fonctionnalités ajoutées à Chrome 68

Le graphique précédent montre deux états qui sont déclenchés par le système lancée par l'utilisateur: gelée et supprimée. Comme indiqué précédemment, les navigateurs se figent et suppriment parfois onglets cachés (à leur seule discrétion), mais les développeurs n'ont aucun moyen de savoir ce qui est en train de se produire.

Dans Chrome 68, les développeurs peuvent désormais observer quand un onglet masqué est bloqué et libérée en écoutant l'freeze et resume événements le document.

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

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

À partir de Chrome 68, l'objet document inclut désormais un wasDiscarded sur la version pour ordinateur de Chrome (la compatibilité d'Android est en cours de suivi dans ce problème). Pour déterminer si une page a été supprimée alors qu'elle était masquée , vous pouvez inspecter la valeur de cette propriété au moment du chargement de la page (remarque: les pages supprimées doivent être actualisées pour pouvoir être utilisées à nouveau).

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

Pour obtenir des conseils sur ce qu'il faut faire dans les freeze et les resume et sur la gestion et la préparation des pages en cas de suppression, consultez recommandations aux développeurs pour chaque État.

Les sections suivantes offrent un aperçu de la façon dont ces nouvelles fonctionnalités s'intègrent à les états et les événements de la plate-forme Web existante.

Comment observer les états du cycle de vie de la page dans le code

En mode actif, passif et masqué il est possible d'exécuter du code JavaScript qui détermine le État du cycle de vie de la page à partir des API existantes de la plate-forme Web

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

États gelés et arrêtés, sur le d'autre part, ne peuvent être détectés que dans leur écouteur d'événements (freeze et pagehide), car l'état en constante évolution.

Comment observer les changements d'état

En vous appuyant sur la fonction getState() définie précédemment, vous pouvez observer toutes les pages L'état du cycle de vie change avec le code suivant.

// 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);

Ce code remplit trois fonctions:

• Définit l'état initial à l'aide de la fonction getState().
• Définit une fonction qui accepte un état suivant et, en cas de changement, enregistre les changements d'état dans la console.
• Ajoute capturer des écouteurs d'événements pour tous les événements de cycle de vie nécessaires, qui, à leur tour, appellent logStateChange(), en transmettant l'état suivant.

Notez que tous les écouteurs d'événements sont ajoutés à window, qui sont tous transmis {capture: true} Plusieurs raisons peuvent expliquer ce phénomène :

• Les événements du cycle de vie de la page ne sont pas tous associés à la même cible. pagehide et pageshow sont déclenchés le window ; visibilitychange, freeze et resume sont déclenchés le document, tandis que focus et blur sont déclenchés sur leur éléments DOM respectifs.
• La plupart de ces événements n'apparaissent pas dans des bulles, ce qui signifie qu'il est impossible d'ajouter d'écouteurs d'événements non capturés à un élément ancêtre commun et d'observer parmi d'autres.
• La phase de capture s’exécute avant les phases de cible ou de bulle. L’ajout permet de s'assurer qu'ils s'exécutent avant qu'un autre code ne puisse les annuler.

Recommandations de développeurs pour chaque État

En tant que développeurs, il est important de comprendre les états du cycle de vie de la page et comment les observer dans le code, car le type de travail que vous devez ne fait pas) dépend en grande partie de l'état de votre page.

Par exemple, l'affichage d'une notification temporaire n'a aucun sens pour l'utilisateur si la page est à l'état masqué. Bien que cet exemple soit assez il y a d'autres recommandations moins évidentes qui valent la peine énumération.

Là encore, la fiabilité et l'ordre des événements de cycle de vie systématiquement implémentée dans tous les navigateurs, le moyen le plus simple de suivre les conseils du tableau est d'utiliser PageLifecycle.js :

Anciennes API de cycle de vie à éviter

Dans la mesure du possible, les événements suivants doivent être évités.

Événement "unload"

De nombreux développeurs traitent l'événement unload comme un rappel garanti et l'utilisent comme un signal de fin de session pour enregistrer l'état et envoyer des données d'analyse. est extrêmement peu fiable, en particulier sur mobile. L'événement unload n'a pas se déclenche dans de nombreuses situations de déchargement courantes, y compris la fermeture d'un onglet depuis l'onglet sur mobile ou en fermant l'application de navigateur à partir du sélecteur d'applications.

C'est pourquoi il est toujours préférable de s'appuyer l'événement visibilitychange pour déterminer quand une session se termine, et considérez l'état caché du dernier moment fiable pour enregistrer les données des applications et des utilisateurs.

De plus, la simple présence d'un gestionnaire d'événements unload enregistré (via onunload ou addEventListener()) peuvent empêcher les navigateurs de pour placer les pages dans le cache amélioré afin d'accélérer les chargements vers l'avant et l'arrière.

Dans tous les navigateurs récents, il est recommandé de toujours utiliser la méthode pagehide pour détecter les éventuels déchargements de page (également appelés l'état terminated) plutôt que l'événement unload. Si vous Vous devez être compatible avec Internet Explorer 10 ou version antérieure, vous devez détecter l'événement pagehide et n'utiliser unload que si le navigateur n'est pas compatible pagehide:

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.
});

L'événement beforeunload

L'événement beforeunload présente un problème semblable à l'événement unload. historiquement, la présence d'un événement beforeunload pouvait empêcher les pages de d'être éligible au cache amélioré. Navigateurs récents ne soient pas soumis à cette restriction. Toutefois, certains navigateurs, par précaution, ne se déclenchent pas L'événement beforeunload lors d'une tentative de chargement d'une page ce qui signifie que l'événement n'est pas fiable en tant que signal de fin de session. En outre, certains navigateurs (y compris Chrome) exiger une interaction de l'utilisateur sur la page avant d'autoriser l'événement beforeunload ; et sa fiabilité n'en sera que plus fiable.

L'une des différences entre beforeunload et unload est qu'il existe des utilisations légitimes de beforeunload. Par exemple, lorsque vous souhaitez avertir l'utilisateur les modifications non enregistrées seront perdues s'ils continuent à décharger la page.

Comme il existe des raisons valables d'utiliser beforeunload, nous vous recommandons n'ajoute que des écouteurs beforeunload si un utilisateur a des modifications non enregistrées, puis et les supprimer immédiatement après leur enregistrement.

En d'autres termes, n'effectuez pas cette opération, car cela ajoute un écouteur beforeunload de manière inconditionnelle):

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);
  }
});

Faites plutôt ceci (car l'écouteur beforeunload n'est ajouté que lorsqu'il est et le supprime dans le cas contraire):

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);
});

Questions fréquentes

Pourquoi n'y a-t-il pas de "chargement" de l'état ?

L'API Page Lifecycle définit les états de manière distincte et mutuellement exclusive. Puisqu'une page peut être chargée à l'état actif, passif ou masqué, et puisqu'il peut changer d'état, voire être arrêté, avant la fin du chargement, un état de chargement distinct n'a aucun sens dans ce paradigme.

Ma page effectue des tâches importantes lorsqu'elle est masquée. Comment éviter qu'elle soit figée ou supprimée ?

Il existe de nombreuses raisons légitimes pour lesquelles les pages Web ne doivent pas être bloquées pendant l'exécution à l'état caché. L'exemple le plus évident est une application qui lit de la musique.

Dans certains cas, Chrome peut également supprimer une page, par exemple s'il contient un formulaire avec une entrée utilisateur non envoyée, ou s'il a un Gestionnaire beforeunload qui avertit lorsque la page est en cours de déchargement.

Pour le moment, Chrome est plus prudent lors de la suppression de pages ne le faites que lorsqu'il est sûr que cela n'affectera pas les utilisateurs. Par exemple, les pages qui l'une des actions suivantes alors qu'ils sont à l'état caché, être supprimés, sauf en cas de contraintes de ressources extrêmes:

• Lecture de l'audio...
• Utiliser WebRTC
• Mettre à jour le titre de la table ou le favicon
• Affichage des alertes
• Envoyer des notifications push

Pour la liste des fonctionnalités actuelles permettant de déterminer si un onglet peut être figés ou supprimés, voir: Heuristics for Freezing & Suppression dans Chrome.

Qu'est-ce que le cache amélioré ?

Le cache amélioré est un terme utilisé pour décrire optimisation de la navigation que certains navigateurs implémentent, ce qui facilite l’utilisation des boutons retour et avancer plus rapidement.

Lorsqu'un utilisateur quitte une page, le navigateur en fige une version. afin de la reprendre rapidement au cas où l'utilisateur y reviendrait les boutons Retour ou Suivant. N'oubliez pas que l'ajout d'un unload gestionnaire d'événements empêche cette optimisation d'être possible.

À toutes fins utiles, ce blocage est fonctionnellement identique à celui les navigateurs figés pour préserver l'utilisation du processeur et de la batterie ; c'est pourquoi il est considéré comme faisant partie de l'état du cycle de vie gelé.

Si je ne peux pas exécuter d'API asynchrones à l'état bloqué ou arrêté, comment puis-je enregistrer des données dans IndexedDB ?

À l'état "gelé" ou "arrêté", tâches figées dans les files d'attente de tâches d'une page ; sont suspendus, c'est-à-dire les API asynchrones et basées sur le rappel, comme IndexedDB. ne peuvent pas être utilisées de manière fiable.

À l'avenir, nous ajouterons une méthode commit() aux objets IDBTransaction, ce qui permettra permettent aux développeurs d'effectuer des transactions en écriture seule qui ne nécessitent pas de rappels. En d'autres termes, si le développeur écrit des données vers IndexedDB sans effectuer de transaction complexe composée de lectures et les écritures, la méthode commit() pourra s'achever avant que les files d'attente de tâches ne soient suspendues (en supposant que la base de données IndexedDB est déjà ouverte).

Toutefois, pour le code qui doit fonctionner aujourd'hui, les développeurs ont deux options:

• Utiliser le stockage de session:stockage de session est synchrone et est conservée lors des suppressions de pages.
• Utiliser IndexedDB à partir de votre service worker:un service worker peut stocker des données dans une base de données indexée après l'arrêt ou la suppression de la page. Dans le freeze ou Écouteur d'événements pagehide avec lequel vous pouvez envoyer des données à votre service worker via postMessage(), et le service worker peut s'occuper de l'enregistrement des données.

Tester votre application à l'état bloqué ou supprimé

Pour tester le comportement de votre application lorsqu'elle est figée ou supprimée, accédez à chrome://discards pour geler ou éliminer l'un de vos onglets ouverts.

Cela vous permet de vous assurer que votre page gère correctement les champs freeze et resume. et l'option document.wasDiscarded lorsque les pages sont actualisées après une suppression.

Résumé

Les développeurs qui souhaitent respecter les ressources système des appareils de leurs utilisateurs doivent créer leurs applications en tenant compte du cycle de vie de la page. Il est essentiel que les pages Web ne consomment pas des ressources système excessives lorsqu'elles que l'utilisateur ne s'attend pas à voir

Plus les développeurs commencent à implémenter les nouvelles API Page Lifecycle, plus elles sont sécurisées permet aux navigateurs de figer et de supprimer les pages qui ne sont pas utilisées. Ce signifie que les navigateurs consomment moins de mémoire, de processeur, de batterie et de ressources réseau. ce qui est une victoire pour les utilisateurs.