Ce lien on me l’a donné plus d’une douzaine de fois, et c’est vrai que c’est intéressant. Je regrette même de ne pas avoir eu une intervention similaire pour Paris Web 2008.
De quoi je parle ? de l’intervention de David Baron aux Tech Talks de Google le 18 novembre dernier. David Baron c’est un ingénieur de Mozilla, depuis les débuts en 98, impliqué dans les spcécifications et implémentations CSS. Quand il parle il sait ce qu’il dit.
Le lien c’est la vidéo de l’intervention Faster HTML and CSS: Layout Engine Internals for Web Developers. Il explique le dessous du capot, comment ça fonctionne et comment ça impacte les performances. À regarder absolument si vous ne l’avez pas encore fait.
Personnellement je retiens trois choses principales de cette intervention :
Sur les sélecteurs CSS
Tout d’abord on confirme ce qui avait déjà été écrit sur les sélecteurs CSS, c’est à dire qu’ils sont interprétés de droite à gauche. Il faut tenter d’être le plus précis possible à droite, dans l’idéal un identifiant, un nom de classe, ou au moins un nom de balise. Le reste du sélecteur a plus tendance à ralentir qu’autre chose.
Le second point concerne :hover
qui pose si j’ai bien compris des problèmes. Soyez le plus précis possible sur la partie qui contient le :hover
, même si elle n’est pas à droite du sélecteur.
Sur l’organisation de vos scripts
Enfin, et c’est probablement la remarque la plus importante à mon humble avis, il vaut mieux parfois en javascript faire une boucle pour lire des informations et une seconde pour modifier le DOM, plutôt que de tout faire en une passe. C’est cohérent avec ce que les bons intégrateurs connaissent déjà mais je crois que peu de gens le mettent en pratique.
Quand vous faites une lecture parfois cela force le rendu du navigateur. C’est par exemple le cas quand vous lisez la propriété width
d’un élément. Pour pouvoir répondre il faut non seulement que l’élément soit dans le DOM, mais aussi lancer le rendu de l’élément à l’écran pour calculer sa taille.
Inversement quand vous faites une écriture elle ne déclenche pas forcément immédiatement un rendu. Si vous changez cette taille, le navigateur peut se permettre de gérer un petit tampon pour recevoir ces modifications, puis ne lancer le rendu qu’après coup.
Si vous faites une seule boucle et que vous lisez et écrivez quelque chose de sensible pour chaque élément, vous allez déclencher un nouveau rendu à chaque fois. Si au contraire vous séparez les deux, vous risquez de ne déclencher que deux rendus (un pour lire et un après les écritures).
Et vous ?
La vidéo est longue, il y a beaucoup d’autres choses dedans, je suis intéressé par ce qui vous a paru nouveau, utile, ou intéressant. Les commentaires sont à vous.