Gains de performance des sélecteurs CSS

Je parlais il y a quelques jours de performance des sélecteurs CSS. Il y a eu quelques réactions et j’ai échoué dans mes explications : les différences de performance dont on parle ici sont probablement négligeables la plupart du temps. Hors commentaires, certains m’ont rappelé que la documentation de Mozilla concerne d’ailleurs au départ les interfaces XUL avec de gros documents XML complexes agrémentés de très grosses feuilles de style.

Quelle importance ?

Il n’y a pas lieu de refaire vos CSS ou de commencer à mettre en place des solutions qui handicapent la maintenance du site (par exemple ne plus utiliser aucun sélecteur descendant). Il y a toutefois parfois utilité. Sur de grosses pages spéciales ou simplement sur les gros sites, ça peut avoir une influence. Je pense en particulier à la philosophie du « on ajoute les nouvelles règles, on modifie parfois, mais on ne supprime pas » qui prévaut sur certains gros sites, par peur de casser quelque chose ou parce que le site est trop gros pour garantir qu’on ne casse rien. Là il est peut être possible de gagner une centaine de millisecondes ou deux. On ne changera pas la feuille de style mais connaître les motifs qui posent problème permet éventuellement d’anticiper et d’écrire autant que possible quelque chose de performant. Ca ne fera de toutes façons pas de mal.

Où on précise ce qui doit l’être

Tout ceci est confirmé par quelques unes de mes lectures récentes. J’aurai préféré les intégrer dans les billet précédent mais les liens de départ viennent seulement de sauter dans mon aggrégateur RSS. Dans l’ordre chronologique c’est Dave Hyatt qui répond à une proposition d’évolution de CSS (commentaire 37). Il explique le fonctionnement interne des navigateurs pour tracker les règles applicables et les continuer à appliquer vos CSS malgré les changements dans le DOM. Le tout rejoint ce que j’avais retenu du document de Mozilla. En même temps c’est logique car c’est le même auteur, et lui l’explique bien mieux que moi.

Et ce qu’il faut en conclure

C’est Jim Barraud qui en sort la conclusion que j’aurai bien aimé écrire. Pas de chance pour moi, j’ai toujours voulu en écrire des tartines en cherchant tous les détails quand seule la conclusion est primordiale. Tel qu’il faut le lire : intuitivement on peut penser que spécifier l’ascendance des balises ou préciser des détails comme le nom de la balise peut aider le navigateur, en réalité c’est le contraire. Relisez cette phrase, c’est l’unique d’importance. Tout le billet précédent est composé de détails de moindre importance pour ceux qui sont aussi curieux que moi.

Pour ceux qui veulent des chiffres

JP Sykes a lui tenté de mesurer le gain de performance concret. Je n’ai pas eu le courage de le faire, prévoyant des résultats peu concluants. Avec son premier essai il a été dans l’impossibilité de distinguer une quelconque différence. Il lui a fallu faire un second essai avec tableau de 20.000 cellules bourré d’identifiants et de classes, avec autant de déclarations de style (donc une par cellule) pour trouver des différences significatives. Avec ces tests peu représentatifs on arrive enfin à des différences jusqu’à 60% (pour Safari 3) qui représentent plus d’une seconde. Si on considère les performances comme linéaires par rapport au nombre de sélecteur et par rapport au nombre de cellules, un document HTML plus raisonnable (environ l’équivalent de 50×20 cellules) la différence de performance dépasse à peine les 10ms. Bref, intéressant à connaître mais certainement pas le point le plus important.