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.

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.

Dans ce billet j’appellerai critère une partie de sélecteur qui contient un identifiant, une classe, un nom de balise ou * (par exemple : #back, *:link, .selected, input[type="text"], ou ul.menu). Les directives de l’article de Mozilla peuvent être regroupées en quatre groupes :

• n’utilisez pas de critère universel ;
• dans un critère utilisez un identifiant, une classe ou un nom de balise mais pas une combinaison de deux ou trois ;
• limitez le nombre de critères dans vos sélecteurs ;
• profitez de la cascade en appliquant les règles le plus haut possible.

Comment ça marche

L’article de Mozilla donne une bonne idée des optimisations du moteur Gecko : le navigateur construit certainement un index pour les noms de balise, les identifiants et les noms de class. Si on utilise un nom de classe, un nom de balise ou un identifiant comme critère le plus à droite, Gecko peut aller rechercher ça dans son index puis après vérifier le reste du sélecteur, de droite à gauche. L’objectif est de savoir si un sélecteur s’applique, uniquement à partir d’une rapide recherche dans les index, sans avoir à analyser le noeud DOM pour récupérer ses autres informations.

Mozilla nous donne même la priorité : Gecko vérifie en priorité les identifiants, puis s’il n’y en a pas il vérifie les noms de classe, sinon il vérifie le nom de la balise, et enfin, si on ne se raccroche à rien, on doit vérifier le sélecteur pour chaque noeud du document.

N’utilisez pas de critère universel

De là vient la première règle : un critère à droite qui n’utilise ni identifiant, ni nom de classe, ni nom de balise, alors il faut parcourir tout le DOM et vérifier le sélecteur sur chaque noeud. Intuitivement on s’attend à ce que ça soit lent, et visiblement ça se vérifie dans le moteur. Fini donc les :link et [type="text"], ça sera a:link et input[type="text"].

Identifiant, classe ou balise, pas de cumul

La seconde règle est aussi induite par le processus de Gecko. Si je spécifie un identifiant et un nom de balise (par exemple ul#menu), Gecko ira chercher l’identifiant dans son index. Pour vérifier que le sélecteur correspond il devra aller chercher le noeud DOM puis comparer le nom de la balise. Au lieu d’aider le navigateur on va lui demander plus de calcul. La réaction est similaire si je fais un ul.menu ou un #menu.selected. Identifiant, nom de classe ou nom de balise, mais un seul des trois, et dans cet ordre de préférence. À la place d’un ul.menu, il vaudrait mieux faire un .menu-list. Certes on perd en généricité mais on demande moins de travail au moteur.

Limitez le nombre de critères

Plus on multiplie les critères plus le moteur doit faire d’analyse via le DOM en plus de la recherche dans son index. Autant que possible, l’identifiant ou le nom de la classe doit être spécifique et ne pas se reposer sur la hiérarchie. Ainsi, Mozilla recommande un .menu-item plutôt qu’un .menu li pour cibler les items d’un menu sous forme de liste. Si vous devez utiliser la hiérarchie et que vous le pouvez (rapport à la compatibilité MSIE 6), toutefois, préférez le sélecteur enfant (signe « supérieur à ») au sélecteur descendant (simple espace).

Profitez de la cascade

Enfin, et c’est là une optimisation qui ne coûte pas cher, appliquez vos styles au noeud le plus générique possible. Pour exemple la couleur de texte et le style des puces peuvent être appliqués directement sur la liste elle même au lieu d’être appliqués sur chaque item de la liste indépendamment. C’est valable pour une bonne partie des styles, justement à cause de l’aspect « cascade » de nos feuilles de style.

Et le reste ?

Il y a une dernière recommandation concernant les images sous forme de sprites, mais c’est en utilisant une règle propriétaire à Mozilla, et j’ai prévu un billet dédié sur le sujet.

Il y a aussi des choses que j’ai cherché mais pas trouvé, que ce soit sur MSDN, le site développeur de Mozilla ou ceux de Opera et Safari : l’influence que les performances de rendu des positions, flottants, marges négatives, tableaux dynamiques et autres méthodes de stylage. Parfois on ressent réellement que telle ou telle page est lourde à cause du montage CSS, et une connaissance de ce est particulièrement coûteux serait plus qu’intéressant. Si parmi mes fidèles cinq lecteurs, l’un de vous a dans son stock un lien sur le sujet, je le remercie de le partager.