Chrome 108 a introduit deux nouveaux modes, l'Économiseur de mémoire et l'Économiseur d'énergie, afin de permettre aux utilisateurs de mieux contrôler la façon dont Chrome utilise leurs ressources système.
Bien que ces nouveaux modes soient principalement destinés aux utilisateurs, ils ont des implications importantes que les développeurs Web doivent connaître, car ils peuvent avoir un impact sur l'expérience utilisateur de votre site.
Cet article présente les effets potentiels de ces nouveaux modes et les mesures que les développeurs Web peuvent prendre pour s'assurer de proposer la meilleure expérience possible.
Mode Économiseur de mémoire
Lorsque le mode Économiseur de mémoire est activé, Chrome supprime de manière proactive les onglets inutilisés en arrière-plan depuis un certain temps. Cela libère de la mémoire pour les onglets actifs et les autres applications en cours d'exécution. Les utilisateurs peuvent demander à Chrome de ne pas supprimer les onglets pour des sites spécifiques. Toutefois, il s'agit d'une préférence utilisateur que vous ne pouvez pas contrôler en tant que développeur.
Lorsqu'un onglet est supprimé, son titre et sa favicon apparaissent toujours dans la barre d'onglets, mais la page elle-même disparaît, exactement comme si l'onglet avait été fermé normalement. Si l'utilisateur revient sur cet onglet, la page est automatiquement actualisée.
Pour les pages de contenu pur, l'abandon et le rechargement d'un onglet n'auront probablement aucune incidence sur l'expérience utilisateur. En revanche, pour les sites riches et interactifs avec des parcours utilisateur complexes, un rechargement au milieu de ce parcours peut être extrêmement frustrant si le site ne parvient pas à restaurer la page exactement à l'endroit où l'utilisateur s'était arrêté.
Chrome jette des onglets pour économiser de la mémoire depuis des années, mais il ne le faisait que lorsque le système était soumis à une pression de mémoire. Étant donné que ce problème est relativement rare, les développeurs Web n'ont peut-être pas réalisé qu'il se produisait.
À partir de Chrome 108, l'abandon d'onglets deviendra plus courant. Il est donc essentiel que les sites puissent gérer ces occurrences de manière appropriée.
Bonnes pratiques pour gérer l'abandon des onglets
Les abandons d'onglets ne sont pas un défi nouveau pour les développeurs Web. Un utilisateur a toujours pu recharger une page (intentionnellement ou accidentellement) avant d'avoir terminé sa tâche. Il a donc toujours été important que les sites stockent l'état de l'utilisateur afin de pouvoir le restaurer s'il quitte le site et y revient.
La considération la plus importante n'est pas de décider de stocker l'état de l'utilisateur, mais de le faire quand. Cela est essentiel, car aucun événement ne se déclenche lorsqu'un onglet est supprimé. Les développeurs ne peuvent donc pas réagir à ce fait. Les développeurs doivent plutôt anticiper cette possibilité et s'y préparer à l'avance.
Les meilleurs moments pour stocker l'état de l'utilisateur sont les suivants:
- À intervalles réguliers lorsque l'état change.
- Chaque fois qu'un onglet est en arrière-plan (événement
visibilitychange).
Les pires moments pour stocker l'état sont les suivants:
- Dans un rappel d'événement
beforeunload. - Dans un rappel d'événement
unload.
Ce sont les pires moments pour stocker l'état, car ces événements sont totalement peu fiables et ne se déclenchent pas dans de nombreuses situations, y compris lorsqu'un onglet est supprimé.
Vous pouvez consulter le diagramme des événements du cycle de vie des pages pour voir quels événements doivent se déclencher lorsqu'une page est supprimée. Comme vous pouvez le voir sur ce diagramme, un onglet peut passer de l'état "masqué" à l'état "abandonné" sans qu'aucun événement ne soit déclenché.
En fait, chaque fois que la page est dans l'état "masquée", il n'est pas garanti qu'un autre événement se déclenche avant que la page ne soit supprimée par le navigateur ou fermée par l'utilisateur. C'est pourquoi il est important de toujours stocker tout état utilisateur non enregistré dans l'événement visibilitychange, car vous n'aurez peut-être pas d'autre occasion.
Le code suivant présente un exemple de logique permettant de mettre en file d'attente la persistance de l'état utilisateur actuel chaque fois qu'il change, ou immédiatement si l'utilisateur met l'onglet en arrière-plan ou quitte la page:
let state = {};
let hasUnstoredState = false;
function storeState() {
if (hasUnstoredState) {
// Store `state` to localStorage or IndexedDB...
}
hasUnstoredState = false;
}
export function updateState(newState) {
state = newState;
hasUnstoredState = true;
requestIdleCallback(storeState);
}
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
storeState();
}
});
Détecter qu'un onglet a été supprimé
Comme indiqué précédemment, il n'est pas possible de détecter qu'un onglet est sur le point d'être supprimé, mais il est possible de détecter qu'un onglet a été supprimé après qu'un utilisateur y est revenu et que la page a été actualisée. Dans ces situations, la propriété document.wasDiscarded est définie sur "true".
if (document.wasDiscarded) {
// The page was reloaded after a discard.
} else {
// The page was not reloaded after a discard.
}
Si vous souhaitez comprendre à quelle fréquence vos utilisateurs rencontrent ces types de situations, vous pouvez configurer votre outil d'analyse pour collecter ces informations.
Par exemple, dans Google Analytics, vous pouvez configurer un paramètre d'événement personnalisé qui vous permettra de déterminer le pourcentage de pages vues provenant d'abandons d'onglets:
gtag('config', 'G-XXXXXXXXXX', {
was_discarded: document.wasDiscarded,
});
Si vous êtes un fournisseur d'analyse, nous vous conseillons d'ajouter cette dimension à votre produit par défaut.
Tester votre site en mode Économiseur de mémoire
Vous pouvez tester la façon dont une page gère l'abandon en la chargeant, puis en accédant à chrome://discards dans un onglet ou une fenêtre distincts.
Dans l'interface utilisateur chrome://discards, vous pouvez rechercher l'onglet que vous souhaitez supprimer de la liste, puis cliquer sur Suppression urgente dans la colonne Actions.
L'onglet est alors supprimé. Vous pouvez le rouvrir pour vérifier que la page a été rechargée dans le même état que celui dans lequel vous l'aviez laissée.
Notez qu'il n'existe actuellement aucun moyen d'automatiser l'abandon d'onglets via des outils de test tels que webdriver ou puppeteer. Toutefois, comme l'abandon et la restauration d'onglets sont presque identiques aux rechargements de page, si vous testez que l'état de l'utilisateur est restauré après un rechargement au milieu d'un parcours utilisateur, cela fonctionnera probablement également pour un abandon/une restauration. La principale différence entre les deux est que les événements beforeunload, pagehide et unload ne se déclenchent pas lorsqu'un onglet est supprimé. Par conséquent, tant que vous ne vous appuyez pas sur ces événements pour conserver l'état de l'utilisateur, vous pouvez utiliser des rechargements pour tester le comportement de suppression/restauration.
Mode Économie d'énergie
Lorsque le mode Économiseur d'énergie est activé, Chrome préserve l'autonomie de la batterie en réduisant la fréquence d'actualisation de l'écran, ce qui affecte la fidélité du défilement et de l'animation, ainsi que la fréquence d'images vidéo.
En règle générale, les développeurs n'ont rien à faire pour prendre en charge le mode économie d'énergie. Les API CSS et JavaScript pour les animations, les transitions et requestAnimationFrame() s'ajustent automatiquement à toute modification du taux de rafraîchissement de l'écran lorsque ce mode est activé.
Le principal scénario dans lequel ce mode peut poser problème est si votre site utilise des animations basées sur JavaScript qui supposent un taux de rafraîchissement particulier pour tous les utilisateurs.
Par exemple, si votre site utilise des boucles requestAnimationFrame() et suppose qu'il s'écoule exactement 16,67 millisecondes entre les rappels, vos animations seront deux fois plus lentes lorsque le mode Économiseur d'énergie est activé.
Notez qu'il a toujours été problématique pour les développeurs de supposer un taux de rafraîchissement par défaut de 60 Hz pour tous les utilisateurs, car ce n'est pas le cas pour de nombreux appareils actuels.
Mesurer la fréquence d'actualisation de l'écran
Il n'existe aucune API Web dédiée pour mesurer la fréquence d'actualisation de l'écran. En général, nous ne recommandons pas d'essayer de le faire avec les API actuelles.
Le meilleur que les développeurs puissent faire avec les API existantes est de comparer les codes temporels entre les rappels requestAnimationFrame() successifs. Dans la plupart des cas, cette méthode permet d'obtenir une approximation du taux de rafraîchissement à un moment donné, mais elle ne vous indique pas quand il change. Pour ce faire, vous devez exécuter en permanence une enquête requestAnimationFrame(), ce qui va à l'encontre de l'objectif de préserver l'énergie ou l'autonomie de la batterie de vos utilisateurs.
Tester votre site en mode Économie d'énergie
Pour tester votre site en mode Économiseur d'énergie, vous pouvez activer ce mode dans les paramètres de Chrome et le configurer pour qu'il s'exécute lorsque votre appareil est débranché.
Si vous ne disposez pas d'appareil pouvant être débranché, vous pouvez également activer le mode manuellement en procédant comme suit:
- Activez l'option
chrome://flags/#battery-saver-mode-available. - Accédez à
chrome://discards, puis cliquez sur le lien Activer/Désactiver le mode économiseur de batterie (important:l'indicateur#battery-saver-mode-availabledoit être activé pour que le lien fonctionne).
Une fois l'option activée, vous pouvez interagir avec votre site et vérifier que tout est comme il se doit: par exemple, que les animations et les transitions s'exécutent à la vitesse souhaitée.
Résumé
Bien que les modes Économiseur de mémoire et Économiseur d'énergie de Chrome soient principalement destinés aux utilisateurs, ils ont des conséquences pour les développeurs, car ils peuvent avoir un impact négatif sur l'expérience de navigation sur votre site s'ils ne sont pas gérés correctement.
En général, ces nouveaux modes ont été conçus en tenant compte des bonnes pratiques existantes pour les développeurs. Si les développeurs respectent les bonnes pratiques Web de longue date, leurs sites devraient continuer à fonctionner correctement avec ces nouveaux modes.
Toutefois, si votre site comporte l'une des pratiques décrites dans cet article, il est probable que vos utilisateurs rencontrent des problèmes qui ne feront qu'empirer si ces deux modes sont activés.
Comme toujours, le meilleur moyen de vérifier que vous proposez une expérience de qualité est de tester votre site dans des conditions correspondant à celles de vos utilisateurs.