Navigateurs pris en charge
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
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 arrêté à 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:
<ph type="x-smartling-placeholder">É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.
État | Description |
---|---|
Actif |
Une page est à l'état actif si elle est visible et comporte le focus d'entrée.
États précédents possibles: |
Passif |
Une page est à l'état passif si elle est visible et si ne pas avoir le ciblage d'entrée.
États précédents possibles:
États suivants possibles: |
Hidden |
Une page est à l'état masqué si elle n'est pas visible (et qu'elle n'a pas a été figée, supprimée ou arrêtée).
États précédents possibles:
États suivants possibles: |
Figé |
Lorsqu'il est gelé, le navigateur suspend l'exécution de
<ph type="x-smartling-placeholder"></ph>
pouvant être congelées
<ph type="x-smartling-placeholder"></ph>
des tâches de l'onglet
files d'attente de tâches jusqu'à ce que la page soit libérée. Cela signifie des choses comme
Les minuteurs JavaScript et les rappels de récupération ne s'exécutent pas. Déjà en cours d'exécution
tâches effectuées (et surtout, les
Les navigateurs figent les pages afin de préserver l'utilisation du processeur, de la batterie et des données. cette mais aussi pour accélérer <ph type="x-smartling-placeholder"></ph> et ainsi de suite, ce qui évite de devoir parcourir une page complète. actualiser la page.
États précédents possibles:
États suivants possibles: |
Arrêtée |
Une page est à l'état Arrêtée dès qu'elle a commencé à être déchargés et effacés de la mémoire par le navigateur. Non <ph type="x-smartling-placeholder"></ph> de nouvelles tâches peuvent démarrer dans cet état, et les tâches en cours peuvent être supprimées s'ils durent trop longtemps.
États précédents possibles:
États suivants possibles: |
Supprimé |
Une page est à l'état discarded lorsqu'elle est déchargée par le navigateur afin d'économiser les ressources. Pas de tâches, de rappels d'événement ni Le code JavaScript de n'importe quel type peut s'exécuter dans cet état, car les suppressions se produire en cas de contraintes de ressources, où le démarrage de nouveaux processus est impossible. À l'état discarded (discard), l'onglet lui-même (y compris le titre de l'onglet et le favicon) sont généralement visibles par l'utilisateur. même si la page a disparu.
États précédents possibles:
États suivants possibles: |
É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.
Nom | Détails |
---|---|
focus
|
Un élément DOM a été sélectionné.
Remarque:Un événement
États précédents possibles:
États actuels possibles: |
blur
|
Un élément DOM n'est plus actif.
Remarque:Un événement
États précédents possibles:
États actuels possibles: |
visibilitychange
|
La fonction
<ph type="x-smartling-placeholder"></ph>
La valeur de |
<ph type="x-smartling-placeholder"></ph>
freeze
*.
|
La page vient d'être figée. N'importe quelle valeur <ph type="x-smartling-placeholder"></ph> gelée dans les files d'attente de tâches de la page ne démarre pas.
États précédents possibles:
États actuels possibles: |
<ph type="x-smartling-placeholder"></ph>
resume
*.
|
Le navigateur a réactivé une page figée.
États précédents possibles:
États actuels possibles: |
pageshow
|
Une entrée de l'historique de session est en cours de balayage. Il peut s'agir du chargement d'une nouvelle page ou d'une page issue de
cache amélioré. Si la page
a été récupérée du cache amélioré,
La propriété
États précédents possibles: |
pagehide
|
Une entrée de l'historique de session est en cours de balayage. Si l'utilisateur accède à une autre page et que le navigateur est en mesure d'ajouter
la page actuelle vers le calendrier
cache pour être réutilisé ultérieurement, la propriété
États précédents possibles:
États actuels possibles: |
beforeunload
|
La fenêtre, le document et ses ressources vont être déchargés. Le document est toujours visible et l'événement peut être annulé point d'accès.
Important:L'événement
États précédents possibles:
États actuels possibles: |
unload
|
Le chargement de la page est en cours.
Avertissement:
l'utilisation de l'événement
États précédents possibles:
États actuels possibles: |
* 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
etpageshow
sont déclenchés lewindow
;visibilitychange
,freeze
etresume
sont déclenchés ledocument
, tandis quefocus
etblur
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.
État | Recommandations pour les développeurs |
---|---|
Active |
L'état actif correspond au moment le plus critique pour l'utilisateur. le moment le plus important pour que votre page <ph type="x-smartling-placeholder"></ph> en fonction de l'entrée utilisateur. Toutes les tâches autres que celles liées à l'UI qui pourraient bloquer le thread principal doivent être définies sur une priorité inférieure à les périodes d'inactivité ou déchargé sur un nœud de calcul Web. |
Passive |
À l'état passif, l'utilisateur n'interagit pas avec la page. mais ils peuvent toujours le voir. Cela signifie que les mises à jour de l'UI et les animations doivent toujours être fluide, mais le moment où ces mises à jour se produisent est moins important. Lorsque la page passe d'active à passive, il s'agit d'une au bon moment pour conserver l'état non enregistré de l'application. |
Lorsque la page passe d'une page passive à une page masquée, elle est l'utilisateur n'interagira plus avec elle tant qu'elle n'aura pas été rechargée. La transition vers masqué est souvent le dernier changement d'état.
qui soit observable de manière fiable par les développeurs (en particulier,
mobile, car les utilisateurs peuvent fermer des onglets ou le navigateur lui-même.
Cela signifie que vous devez considérer l'état masqué comme la fin probable de la session utilisateur. En d'autres termes, conservez tout état de l'application non enregistré et envoyer les données d'analyse non envoyées. Vous devez également arrêter les mises à jour de l'interface utilisateur (elles ne seront plus visibles par l'utilisateur), et vous devez arrêter toutes les tâches qu'un utilisateur ne voudrait pas qui s'exécute en arrière-plan. |
|
Frozen |
À l'état gelé, <ph type="x-smartling-placeholder"></ph> des tâches gelées <ph type="x-smartling-placeholder"></ph> les files d'attente de tâches sont suspendues jusqu'à ce que la page soit libérée, ce qui peut ne se produisent jamais (par exemple, si la page est supprimée). Cela signifie que la page passe de masquée à figée. il est essentiel d'arrêter les minuteurs ou de supprimer toute connexion qui, s'ils sont figés, cela peut affecter d'autres onglets ouverts avec la même origine ou affecter le la capacité du navigateur à placer la page dans le cache amélioré. En particulier, il est important que vous:
Vous devez également conserver tous les états d'affichage dynamique (par exemple, la position de défilement
dans une liste infinie) pour
<ph type="x-smartling-placeholder"></ph>
Si la page est passée de gelée à masquée, vous pouvez rouvrir les connexions fermées ou relancer les interrogations s'est arrêtée lorsque la page a été initialement figée. |
Terminated |
Aucune action n'est généralement requise lors de la transition d'une page. à l'état terminated (arrêté). Les pages qui sont déchargées suite à une action de l'utilisateur l'état masqué avant de passer à l'état terminated (arrêté). , l'état masqué correspond à l'endroit où la logique de fin de session (par exemple, un état de l'application persistant et des rapports à Analytics) doivent être d'exécution. De plus, comme indiqué dans les recommandations
l'état caché), il est très important que les développeurs comprennent
que la transition vers l'état arrêté ne peut pas être fiable
détectées dans de nombreux cas (en particulier sur les mobiles). Les développeurs qui dépendent
en cas de résiliation (par exemple, |
Discarded |
L'état discarded n'est pas observable par les développeurs au au moment où une page est supprimée. En effet, les pages sont généralement supprimées en cas de contraintes de ressources, et en libérant une page uniquement pour permettre d'exécuter un script en réponse à un événement de suppression n'est tout simplement pas possible dans dans la plupart des cas. Par conséquent, vous devez vous préparer
à l'éventualité d'une suppression
passer de masqué à gelé, vous pouvez alors
réagissez à la restauration d'une page supprimée au moment de son chargement
en vérifiant |
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énementspagehide
avec lequel vous pouvez envoyer des données à votre service worker viapostMessage()
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.
![Chrome supprime l'interface utilisateur](https://developer.chrome.com/static/docs/web-platform/page-lifecycle-api/image/chrome-discards-ui-4c0620d6f8619.png?authuser=19&hl=fr)
Cela vous permet de vous assurer que votre page gère correctement les champs freeze
et resume
.
et l'indicateur 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.