Chrome 108 a introduit deux nouveaux modes, l'Économiseur de mémoire et l'Économiseur d'énergie, pour 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 dont les développeurs Web doivent être conscients, 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, ainsi que pour d'autres applications susceptibles d'être 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 sous pression de mémoire. Les développeurs Web n'ont peut-être pas réalisé que cette situation se produisait assez rarement.
À 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.
Le plus important n'est pas de stocker l'état de l'utilisateur, mais de quand le stocker. 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).
Voici les pires moments pour stocker l'état:
- 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 pour mettre en file d'attente l'état actuel de l'utilisateur chaque fois qu'il change, ou immédiatement si l'utilisateur passe en arrière-plan de l'onglet ou le quitte:
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 retourne et que la page est rechargé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 savoir à quelle fréquence vos utilisateurs sont confrontés à ces types de situations, vous pouvez configurer votre outil d'analyse de façon à recueillir 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'onglets supprimés:
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
Pour tester la gestion des suppressions sur une page, chargez-la, puis accédez à chrome://discards dans un onglet ou une fenêtre distincts.
Dans l'interface utilisateur de chrome://discards, localisez l'onglet que vous souhaitez supprimer de la liste, puis cliquez sur Suppression urgente dans la colonne Actions.
L'onglet est alors supprimé. Vous pouvez le rouvrir et 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 actualisations de page, si vous testez que l'état de l'utilisateur est restauré après une actualisation 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 basez pas sur ces événements pour conserver l'état de l'utilisateur, vous pouvez tester le comportement de suppression/restauration à l'aide d'actualisations.
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'exactement 16,67 millisecondes se sont écoulées entre les rappels, vos animations s'exécuteront deux fois plus lentement lorsque le mode Économiseur d'énergie est activé.
Notez qu'il a toujours été problématique pour les développeurs de supposer une fréquence d'actualisation 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 pas d'API Web dédiée pour mesurer la fréquence d'actualisation de l'affichage. En général, il est déconseillé d'essayer de le faire avec les API actuelles.
La meilleure chose que les développeurs puissent faire avec les API existantes est de comparer les codes temporels entre les rappels requestAnimationFrame() successifs. Bien que cette méthode fonctionne dans la plupart des cas pour estimer la fréquence d'actualisation à un moment donné, elle ne vous indique pas quand elle 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 Économiseur 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 cette fonctionnalité activée, vous pouvez interagir avec votre site et vérifier que tout se présente comme prévu, par exemple pour 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.