Chrome : une bêta 51 moins gourmande, ES6/ES7 pour la version 52

Chrome : une bêta 51 moins gourmande, ES6/ES7 pour la version 52

Premier sur les 100 % ?

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

02/05/2016
9

Chrome : une bêta 51 moins gourmande, ES6/ES7 pour la version 52

Google propose depuis peu la bêta de Chrome 51 au téléchargement. Elle comporte deux améliorations importantes, l’une centrée sur la gestion des identifiants et mots de passe, l’autre sur les performances de rendu. Parallèlement, l’éditeur annonce lui aussi une prise en charge complète d’ES6 pour Chrome 52.

Presque dans la foulée de Firefox et sa mouture 47 bêta, Chrome propose sa préversion 51. Comme toujours, on retrouve une bonne liste d’améliorations diverses, mais deux nouveautés se détachent du lot. La première se présente sous la forme d’une API. Baptisée Credential Management, elle permet à l’ensemble des sites web d’interagir avec Chrome pour gérer plus efficacement les identifiants et mots de passe.

Une nouvelle API pour gérer les identifiants

Tous les navigateurs proposent ce type de fonctionnalité, désormais considérée comme basique et enrichie par la synchronisation. Cependant, de nombreux sites utilisent un système particulier qui casse la compatibilité de l’enregistrement.

Le gros avantage est que n’importe quel site pourra s’y référer pour stocker les identifiants de l’utilisateur dans la base de données interne du navigateur (avec l’accord de ce dernier bien entendu). Malheureusement, et comme on pouvait s’en douter dans le cas d’une API, il faudra que les développeurs web codent spécifiquement un système de login prenant en charge cette nouveauté. Dans ce cas, ils pourront interagir directement avec le gestionnaire de mots de passe de Chrome (Smart Lock). De son côté, l’utilisateur pourra se connecter en un clic.

Plus de calculs inutiles pour les frames non affichées

L’autre apport est un changement important dans le moteur de rendu de Chrome, Blink. La version 51 ne fait en effet plus aucun calcul pour rendre les frames qui ne sont pas directement affichés à l’écran. C’est le cas notamment pour de nombreux éléments sociaux, vidéos intégrées ou publicités. On ne parle pas de coupure de l’affichage mais bien d’un « court-circuit » dans le flux du rendu. Plus spécifiquement, ce sont les rappels de la méthode requestAnimationFrame() qui ne seront plus calculés s’ils concernent des éléments qui ne sont pas présents dans la page.

Google indique sur son blog que ce changement ne bouleversera pas la navigation, mais qu’il aura un impact sur les performances. Le flux de rendu ne sera plus encombré par ces éléments, permettant alors de fluidifier l’affichage de la page. Avec une conséquence directe pour les appareils mobiles : jusqu’à 30 % d’économies sur la batterie pour certains sites populaires, Google ne donnant aucun exemple. À voir donc en pratique.

ES6/ES7 : ce sera pour Chrome 52

L’autre grande annonce de Google concerne le support du standard ECMAScript. Alors que Webkit indiquait atteindre les 99 % sur la version 6 (2015), Chrome se prépare au 100 % pour sa mouture 52, actuellement dans le canal de développement Canary.

Mais puisqu’il n’était pas question de se prononcer sur l’ES6 seul (tous les navigateurs en supportent au moins 90 %), Google indique également que la future norme ES7 sera supportée dans Chrome 52. L’éditeur a publié vendredi un billet sur le blog dédié à la machine virtuelle JavaScript V8 pour en présenter les avantages et nouveautés, notamment l’opérateur exponentiation, la méthode Array.prototype.includes() ou encore l’évènement unhandledrejection.

9

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une nouvelle API pour gérer les identifiants

Plus de calculs inutiles pour les frames non affichées

ES6/ES7 : ce sera pour Chrome 52

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (9)


Ho comme je suis… il est écrit “moins gourmande” et moi je crois comprendre “moins gourmande … en mémoire”. Ouffff me voilà rassuré je ne vais pas devoir me prendre la tête pour revendre la moitié de mes barrettes ram sur eBay…

 


Sha Abonné
Le 02/05/2016 à 11h 26

La diminution du rendering des iframe était déjà faite dans Firefox et Safari. Opera aussi mais bon normal vu que c’est le même code que chrome.



Il ne reste plus que Edge à la traîne là dessus.


Le 02/05/2016 à 11h 35

Il serait bien que Chrome optimise sa lecture de vidéo sur Youtube… Un comble… 

Impossible pour moi de lire une vidéo en 4K/60 FPS sous Chrome. Sur Edge ça passe impeccable…


Le 02/05/2016 à 13h 36

Pas de prob pour moi pour lire du 4k sur YT avec Chrome, mais j’ai la fibre, peut être que ça joue ?


Le 02/05/2016 à 14h 27

4k 60 fps?



J’ai la (vraie) fibre 1gbps @ 870mbps en ethernet. Cela ne vient pas de là. Surtout que j’ai bien dis que ça fonctionnait pour moi sur Edge.


Le 02/05/2016 à 14h 28

Si ça marche sur Edge j’imagine que c’est pas le soucis.


Le 02/05/2016 à 14h 39







Sqlutsqvq a écrit :



4k 60 fps?



J’ai la (vraie) fibre 1gbps @ 870mbps en ethernet. Cela ne vient pas de là. Surtout que j’ai bien dis que ça fonctionnait pour moi sur Edge.





alors je ne sais pas





Blood_Man a écrit :



Si ça marche sur Edge j’imagine que c’est pas le soucis.





ouep. ;)



Le 02/05/2016 à 14h 44







boogieplayer a écrit :



alors je ne sais pas



ouep. ;)





Au passage je suis sur un i5 4200h, 16Go de ram, 850 EVO et GTX860m sous windows 10, c’est pas la puissance qui pose problème non plus.



Le 02/05/2016 à 15h 08







Sqlutsqvq a écrit :



Au passage je suis sur un i5 4200h, 16Go de ram, 850 EVO et GTX860m sous windows 10, c’est pas la puissance qui pose problème non plus.







Tu n’aurais pas désactiver l’accélération graphique par hasard ?