Performance des sélecteurs CSS, encore un mot

On reparle des performances CSS. Souvenez-vous, je vous avais parlé d’un document de Mozilla faisant état des sélecteurs plus ou moins performants. S’était ensuivi une discussion à propos de la pertinence de tels sujets vu la différence de performance mise en oeuvre.

Je vous invite à relire ce second billet, qui résume assez bien. Si on remet le couvert c’est que Jon Sykes a refait un troisième test tout récemment, avec un graphique assez sympa

Plutôt que les valeurs absolues des performances ce qui est intéressant c’est l’évolution suivant le type de sélecteur utilisé. Safari et Microsoft Internet Explorer sont très dépendant du sélecteur, Firefox un peu moins. Allez voir les graphiques, ça vaut milles lignes d’explication.

Bref, si vous deviez retenir quelque chose :

  • Faites attention aux sélecteurs enfant et descendant (mais pas au point de tenter de les éviter) ;
  • Tentez d’utiliser des sélecteurs très simples, par exemple juste un nom de classe (mais pas la peine de reprendre vos CSS pour ça) ;
  • N’ajoutez pas de hiérarchie de balises en préfixe de vos sélecteurs en pensant aider le navigateur (c’est le contraire qui se passe) ;
  • L’impact de tout cela sera  nul sur des pages simples ou même moyennes, cela peut commencer à avoir du sens sur des grosses applications HTML comme on commence à en voir (c’est Dave Hyatt qui le dit, faites lui confiance) ;
  • Les navigateurs ne réagissent pas tous pareil vis à vis de la complexité des sélecteur, Firefox semble optimiser ses recherches différemment.

Publié par edaspet

Plus d'informations sur mon profil en ligne

5 réponses sur « Performance des sélecteurs CSS, encore un mot »

  1. Sympathique billet. Notamment pour les hiérarchies de balises pour lesquelles je pensais pas du tout aux perfs.

    Pour les sélecteurs « plus simple » ne vaut-il mieux pas utiliser un id plutôt qu’une classe quand c’est un style pour un élément qui n’est pas amené à se répéter ? Ca réduit le parcours du document à un simple getElementById.

  2. Le truc c’est que justement, il n’y a aucun parcours de DOM pour gérer la partie droite du sélecteur (si elle n’est pas *). C’est justement géré par un index.
    Le DOM n’est parcouru (en remontant la hiérarchie, pas en la descendant) uniquement si on précise quelque chose à gauche.

  3. Dave Hyatt dit aussi que les résultats particuliers de Safari sont dus à un bug de parsing (bug corrigé depuis) et non pas à des baisses significatives de performance. Il se peut que les autres navigateurs aient des bugs similaires vu qu’il y a énormément de règles dans l’élément style. Faire le même test avec des feuilles externes pourrait donner des résultats différents.

    Les graphiques de Safari et IE sont en fait proportionnels à la longueur des styles. Du coup, je ne tire aucune conclusion de ce test.

  4. Aucune idée, et j’ai tendance à croire qu’il ne l’a volontairement pas donnée. L’important n’est pas tellement de troller sur le navigateur ou entre les navigateurs, mais plus de voir sa progression sur les différents sélecteurs. C’est plus l’aspect de la courbe qui est regardée et pas sa position en ordonnée.

Les commentaires sont fermés.