Chrome 108 a introduit deux nouveaux modes, Économiseur de mémoire et É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 explique comment les développeurs Web peuvent s'assurer qu'ils offrent 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 d'onglets pour des sites spécifiques. Cependant, il s'agit d'une préférence de l'utilisateur et d'un élément que vous ne pouvez pas contrôler en tant que développeur.
Lorsqu'un onglet est supprimé, son titre et son favicon apparaissent toujours dans la barre d'onglets, mais la page elle-même a disparu, 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 purement du contenu, la suppression et le rechargement d'un onglet n'affecteront probablement pas l'expérience utilisateur. Toutefois, pour les sites riches et interactifs avec des parcours utilisateur complexes, un rechargement en milieu de ce flux peut être extrêmement frustrant si le site ne parvient pas à restaurer la page exactement là où l'utilisateur s'était arrêté.
Chrome supprime des onglets pour économiser de la mémoire depuis des années, mais cela n'était possible que lorsque la mémoire du système était insuffisante. Les développeurs Web n'ont peut-être pas réalisé que cette situation se produisait assez rarement.
À partir de Chrome 108, la suppression d'onglets sera plus courante. Il est donc essentiel que les sites puissent gérer ces occurrences de manière optimale.
Bonnes pratiques pour gérer les suppressions d'onglets
La suppression d'onglets n'est pas un nouveau défi pour les développeurs Web. Il a toujours été possible pour un utilisateur d'actualiser une page, intentionnellement ou accidentellement, avant d'effectuer une tâche. Il a donc toujours été important pour les sites de stocker l'état de l'utilisateur afin de pouvoir le restaurer si l'utilisateur quitte le site et y retourne.
Le plus important n'est pas de stocker l'état de l'utilisateur, mais de quand le stocker. C'est essentiel, car aucun événement ne se déclenche lorsqu'un onglet est supprimé. Les développeurs n'ont donc aucun moyen de réagir à cette situation. Les développeurs doivent anticiper cette éventualité et se préparer à l'avance.
Les meilleurs moments pour stocker l'état des utilisateurs sont les suivants:
- À intervalles réguliers, lorsque l'état change.
- Chaque fois qu'un onglet est mis 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 périodes pour stocker l'état, car ces événements ne sont pas fiables et ne se déclenchent pas dans de nombreuses situations, y compris lorsqu'un onglet est supprimé.
Consultez le diagramme des événements du cycle de vie de la page pour savoir quels événements doivent être déclenchés lorsqu'une page est supprimée. Comme vous pouvez le voir sur ce diagramme, un onglet peut être consulté à l'état "discarded" sans qu'aucun événement ne se déclenche.
En fait, chaque fois que la page se trouve dans la zone "masquée", , rien ne garantit que tout autre événement se déclenchera avant que la page ne soit supprimée par le navigateur ou arrêté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'en aurez peut-être plus la possibilité.
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 a la valeur "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 de solutions d'analyse, vous pouvez envisager 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 sera alors supprimé. Vous pourrez ainsi le consulter de nouveau et vérifier que la page a bien été actualisée dans l'état dans lequel vous l'avez quittée.
Notez qu'il n'existe actuellement aucun moyen d'automatiser la suppression des onglets via des outils de test tels que Webdriver ou Puppeteer. Toutefois, étant donné que les suppressions et restaurations d'onglets sont presque identiques à celles des actualisations de pages, si vous testez que l'état de l'utilisateur est restauré après une actualisation au milieu d'un flux utilisateur, il sera probablement également utilisé pour la suppression/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 Économiseur d'énergie
Lorsque le mode Économiseur d'énergie est activé, Chrome économise la batterie en réduisant la fréquence d'actualisation de l'affichage, ce qui affecte la fidélité du défilement et de l'animation, ainsi que la fréquence d'images des vidéos.
En général, les développeurs n'ont rien à faire pour prendre en charge le mode Économiseur d'énergie. Les API CSS et JavaScript pour les animations, les transitions et requestAnimationFrame() s'ajustent automatiquement à toute modification de la fréquence d'actualisation de l'affichage lorsque ce mode est activé.
Ce mode pourrait poser problème si votre site utilise des animations JavaScript qui supposent une fréquence d'actualisation particulière pour tous les internautes.
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 sur 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 solution pour les développeurs avec les API existantes consiste à comparer les horodatages entre les rappels requestAnimationFrame() successifs. Bien que cela fonctionne dans la plupart des cas pour estimer la fréquence d'actualisation à un moment donné, cela ne vous permet pas de savoir quand la fréquence d'actualisation change. Pour ce faire, vous devriez lancer un sondage requestAnimationFrame() en permanence, ce qui va à l'encontre de votre objectif d'économie d'énergie ou d'autonomie de la batterie pour les 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 aucun appareil ne peut être débranché, vous pouvez également activer ce 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 la 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é
Même si les modes Économiseur de mémoire et Économiseur d'énergie de Chrome sont principalement des fonctionnalités destinées aux utilisateurs, ils ont des conséquences pour les développeurs, car ils peuvent nuire à 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 des développeurs. Si les développeurs appliquent depuis longtemps les bonnes pratiques du Web, leurs sites devraient continuer à fonctionner correctement avec ces nouveaux modes.
Toutefois, si votre site intègre l'une des pratiques décrites dans cet article, il est probable que vos utilisateurs rencontrent des problèmes qui ne feront plus qu'augmenter si ces deux modes sont activés.
Comme toujours, le meilleur moyen de confirmer la qualité de votre site est de tester votre site dans des conditions qui correspondent à celles de vos visiteurs.