Dans les actuelles branches Dev et Canary (105 ou ultérieure), on trouve une nouvelle option permettant de raboter plus agressivement la consommation des pages web ouvertes en fond, c’est-à-dire dans les onglets inactifs.
Disponible dans chrome://flags, elle se nomme « Quick intensive throttling after loading ». Son effet est radical : au lieu d’attendre 5 minutes pour déclencher la « veille » des onglets inactifs, le navigateur active le mécanisme au bout de 10 secondes seulement.
Ce mode limite drastiquement nombre d'événements. Tous les évènements pouvant être considérés comme des réveils des pages, comme les tâches setTimeout et setInterval ou les tâches différées scheduler.postTask, sont limités à un par minute.
Google n’aurait constaté aucune régression significative durant ses tests. En revanche, la fonction aurait un effet positif sur la consommation du processeur. Comme le signale Chrome Unboxed, qui s’est fait l’écho de ce changement, Google estime que le gain en autonomie pourrait atteindre 10 % sur les ordinateurs portables.
Le résultat dépendra bien sûr du nombre d’onglets ouverts en moyenne. Le réglage pourrait avoir une influence significative chez les personnes ayant toujours de nombreuses pages ouvertes.
Commentaires (17)
#1
Faudrait que ce soit aussi plus agressif au démarrage, plus agressif dans la fluidité générale, plus agressif en tout en fait
#1.1
-> Firefox ?
#1.2
De moins en moins de sites fonctionnent correctement sous firefox… Remarques ça permet d’avoir un navigateur de niche qui passe les cookie wall sans que le “désagrément” soit pris trop au sérieux par ceux qui les mettent en place.
#1.3
Pour le moment je n’ai que https://business.apple.com qui ne passe pas (avec un gros troll qui me dit de mettre Firefox à jour …)
#2
J’ai l’impression de lire un newsgroup des années 90 sur les systèmes d’exploitation.
Vous me direz, à force de transformer le browser en OS, c’est normal.
Donc on va gérer la priorité foreground/background sur les
processtabs ? bien, bien.Bientôt la détection des spin-wait, le scaling de fréquence et le mode tickless.
#3
N’utilisant que Firefox, si c’est le cas je ne m’en rends pas compte. Pour moi les sites fonctionnent, du moins ceux que je visite régulièrement.
#3.1
Salesforce avec firefox c’est très caca.
#4
C’est pas nouveau que les navigateur soient des OS. Ils ont quand même des BDD, une infra de gestion d’appli, de la 3D, ils gèrent leur RAM, on a géré l’isolement entre utilisant du multiprocessus… On a aussi fait des OS à partir de navigateurs…
Ce sont des ogres, pour le peu de données utiles affichées, c’est une catastrophe en termes de ressources.
#5
Mais non, n’exagérons rien.
C’est juste que l’utilisateur moyen du Web est désormais un cycliste installé dans une voiture placée à l’intérieur de la remorque d’un camion posé sur un wagon de fret pour faire 2km.
#6
#7
Quand on disait que c’était un repère de vieux ici …
(Je laisse aux piliers le soin de remonter le niveau des commentaires, manquerez plus que je lise et participe à un truc que je ne souhaite pas voir disparaître)
#8
Si vraiment on peut économiser 10% en mettant en veille des onglets, on peut se demander ce que font ces onglets dans notre dos…
#9
Sans chercher à aller dans le procès d’intention, la plupart des sites web étant des applications avec gestion d’événements et rafraîchissement automatique, forcément ça tûte de la ressource en arrière plan. Et comme tout ça c’est optimisé avec le cul, ça bouffe du CPU pour rien.
#10
Même chose pour moi, je n’ai aucun problème visible de compatibilité avec Firefox, et je me demande toujours quel type de site visitent ceux qui se plaignent de ça.
#10.1
Incompatibilité totale, je n’ai pas vu mais différence de performance oui.
J’en avais déjà parlé il me semble dans les commentaires mais il y a une différence assez nette de fluidité pour Collabora Online en faveur de Blink lorsqu’il s’agit d’utiliser le tableur.
J’avais déjà fait ce constat auparavant avec d’autres applications “lourdes”.
Après à savoir si c’est une forme d’optimisation favorisant blink ou bien des lacunes de Firefox sur la prise en charge de certaines fonctionnalités, je ne saurais le dire.
#10.2
Sites interactifs avec remplissage de formulaires complexes par exemple. De moins en moins de compatibilité. C’est sûr que si c’est pour aller sur nextinpact, il y a pas de problème.
#11
L’architecture est déjà mauvaise. Un site,un processus, ça empêche l’os de regrouper l’exécution des traitements d’arrière plan.
Entre la sécurité, l’architecture déconnectée, le javascript parfois mal compris/mal maîtrisé, les besoins de base (utiliser le gpu pour rendre quelques fonctionnalités css), les navigateurs sont un peu alourdis.