Publié le 20 janvier 2025
À partir de Chrome 133 (février 2025), les onglets en arrière-plan éligibles qui utilisent beaucoup de ressources processeur seront figés lorsque le mode Économiseur d'énergie est activé. Cela vise à réduire la consommation de la batterie pour les utilisateurs qui s'appuient sur l'Économiseur d'énergie et pour qui chaque point de pourcentage d'autonomie de la batterie compte. Pour limiter les perturbations, seuls les onglets en arrière-plan qui répondent à des critères spécifiques et qui présentent une utilisation élevée du processeur seront figés.
Qu'est-ce que le blocage ?
Le gel suspend l'exécution des tâches sur une page Web. Par exemple :
- Gestionnaires d'événements (par exemple, entrée, réseau et capteur)
- Minuteurs
- Résolveurs de promesse
Le blocage est différent de l'abandon, où un onglet est supprimé de la mémoire. Lorsqu'un onglet figé est de nouveau mis au premier plan, il est automatiquement dégelé et toutes les tâches en file d'attente sont exécutées sans perte d'état.
Les événements de blocage et de reprise sont distribués lorsqu'une page est bloquée ou reprise (voir la documentation de l'API Page Lifecycle). Ces événements permettent à la page de libérer des ressources inutilisées, d'informer un serveur que la page est mise en pause ou d'enregistrer des métriques.
Quelles pages peuvent être figées ?
Le gel s'applique aux groupes de contextes de navigation.
En règle générale, un groupe de contexte de navigation se compose d'un seul onglet. Toutefois, plusieurs onglets peuvent appartenir au même groupe lorsque vous utilisez des API telles que window.open().
Lorsque l'Économiseur d'énergie est activé, un groupe de contexte de navigation est gelé s'il remplit les conditions suivantes:
- Toutes les pages du groupe sont masquées et silencieuses depuis plus de cinq minutes.
- Tout sous-groupe de frames de même origine au sein du groupe est "consommateur de CPU".
- Le groupe ne permet pas :
- Fournir une fonctionnalité de visioconférence ou d'audioconférence (détectée à l'aide d'un micro, d'une caméra, d'une capture d'écran/de fenêtre/d'onglet ou d'une interface RTCPeerConnection avec un RTCDataChannel "ouvert" ou un MediaStreamTrack "en direct").
- Contrôler un appareil externe (détecté à l'aide de Web USB, Web Bluetooth, Web HID ou Web Serial)
- Maintenez un verrouillage Web ou une connexion IndexedDB qui bloque les opérations en dehors du groupe.
La définition de "CPU-intensive" peut évoluer, mais l'objectif est d'exclure les clients de messagerie ou de chat implémentés de manière efficace, ou les applications d'agenda qui génèrent des notifications.
Le blocage simultané de tous les onglets du même groupe de contexte de navigation réduit les perturbations pour les applications qui utilisent des pop-ups, comme celles pour rédiger des messages ou saisir des identifiants.
Comment préparer mon site ?
Si votre site ne comporte pas de fonctionnalités en arrière-plan (notifications, importations de fichiers ou actualisation de contenu, par exemple), il ne sera probablement pas affecté par le blocage.
Si votre site dispose de fonctionnalités en arrière-plan, réduisez son utilisation du processeur en arrière-plan pour éviter d'être considéré comme gourmand en ressources processeur et donc de geler. Voici quelques conseils:
- Évitez les minuteurs pour les vérifications périodiques des changements d'état.
- Utilisez IntersectionObserver pour détecter quand un élément entre dans le viewport.
- Utilisez ResizeObserver pour détecter les modifications de taille des éléments.
- Utilisez MutationObserver ou des appels de rappel du cycle de vie des éléments personnalisés pour les modifications du DOM.
- Envisagez d'utiliser des sockets Web, des événements envoyés par le serveur, des messages push ou des flux de récupération au lieu d'un serveur de sondage.
- Utilisez des événements tels que "timeupdate" et "ended" pour les modifications audio ou vidéo.
Nous vous recommandons également de migrer les fonctionnalités en arrière-plan vers un service worker afin qu'elles ne soient pas affectées par le blocage. En plus de ne pas être affecté par le blocage, un service worker nécessite moins de ressources de navigateur. Envisagez d'utiliser:
- API Push pour les notifications
- API de synchronisation en arrière-plan ou API de synchronisation périodique en arrière-plan Web pour récupérer les mises à jour.
Les sites peuvent désactiver le figement en participant à l'essai d'origine BackgroundPageFreezeOptOut. Cette version d'essai sera abandonnée une fois que de nouvelles API pour déclarer des tâches importantes en arrière-plan seront publiées (par exemple, l'API Notification de progression).
Vous pouvez vérifier si un onglet peut être gelé dans chrome://discards. Notez que même si un onglet peut être figé, Chrome 133 ne le fige que s'il utilise beaucoup de ressources processeur et que l'économiseur d'énergie est activé.
Étape suivante
Le figement des onglets en arrière-plan permet d'économiser de l'énergie, ce qui est crucial pour les utilisateurs dont l'Économiseur d'énergie est activé.
Il améliore également les performances des onglets de premier plan et permet d'éviter l'arrêt des onglets en arrière-plan, en particulier sur les appareils à ressources limitées, en réduisant l'utilisation du processeur et l'accès à la mémoire. Chrome étendra donc le figement des onglets à d'autres situations (les modifications seront annoncées sur blink-dev@chromium.org). Pour ce faire avec un minimum de perturbation des cas d'utilisation en arrière-plan, de nouvelles API telles que l'API ProgressNotification permettront aux pages de déclarer des tâches importantes en arrière-plan et d'éviter le blocage.