WebDev-FR

Il existe une quantité considérable de règles de bon usage, de trucs, de bidouilles voir même d’outils professionnels pour optimiser la couche CSS d’un site.

Néanmoins, une branche de ce domaine qui a été assez peu analysée est l’impact de l’utilisation des sélecteurs CSS et surtout la nécessité, ou pas, d’avoir des règles avec un grand nombre de sélecteurs.

En fait tout a démarré lorsque Dave Hyatt (le Lead Developer de l’équipe WebKit) a fait remarquer dans un commentaire du blog de Shaun Inman que les sélecteurs CSS enfant (comme le caractère espace) étaient à utiliser à la légère car s’appliquent de droite à gauche et non de gauche à droite.

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers. - Dave Hyatt

Ce qui fait que, comme le résume Jon Sykes, la règle suivante :

body table tr td.myTestClass{
  background-color: red;
}

…est moins efficace que sa version courte :

.myTestClass{
  background-color: red;
}

Pourquoi ? Tout simplement parce qu’avec la première règle, si vous modifiez le DOM cette règle devra probablement être ré-appliquée sur tout le document afin de l’appliquer à de nouveaux noeuds ou au contraire à ne plus l’appliquer sur certains noeuds. Alors qu’avec la seconde règle, la modification du DOM n’aura un impact que si cette modification consiste à ajouter ou à retirer la classe “myTestClass”.

Bref, vouloir faire des règles avec une longue série d’accesseurs enfant pour cibler exactement l’élément qui nous intéresse peut s’avérer couteux sur les performances, il est préférable de donner une classe précise à notre ou nos éléments et de créer une règle qui se base sur cette classe et sur rien d’autre.

Pour montrer ce coût en performances, Jon Sykes a réalisé plusieurs tests. Son dernier test consiste à créer une page contenant trois niveaux de DIV imbriqués, le niveau le plus profond contient un paragraphe contenant lui-même un lien. Le lien a un ID et une classe générée. Au total, il y a 20.000 liens dans la page.
Il a ensuite cherché à comparer le temps mis pour afficher la page avec les conditions suivantes :

• aucun style appliqué
• un fond rouge pour chaque cellule avec une unique règle qui s’applique sur la balise A
• un fond rouge pour chaque cellule avec des règles ayant uniquement le nom de la classe du lien (20.000 règles)
• un fond rouge pour chaque cellule avec des règles utilisant le sélecteur fils (20.000 règles)
• un fond rouge pour chaque cellule avec des règles utilisant le sélecteur descendant (20.000 règles)

Il obtient les résultats suivants (les pourcentages affichés sont par rapport à l’affichage sans aucun style) :

Bref, privilégiez les règles avec des sélecteurs courts. Ca risque d’alourdir votre code HTML avec plus de classes ou d’ID mais les performances d’affichage de votre page s’en sortiront mieux.

Pour lire les articles de Jon Sykes :

1. Testing CSS Performance
2. Testing CSS Performance (pt 2)
3. More CSS Performance Testing (pt 3)

Steve Sounders creuse le sujet un peu plus loin

Les tests de Jon Sykes datent du printemps 2008.

Récemment (début Mars), Steve Sounders (de l’équipe Performances de Yahoo!) a creusé le sujet. Il considérait que bien que justes, les tests de Jon Sykes s’appliquaient à des pages bien trop volumineuses pour représenter la réalité : peu de pages peuvent se vanter d’aligner un DOM de 60.000 noeuds et de 20.000 règles CSS. Les 10 sites les plus fréquentés ont une moyenne de 923 noeuds sur leur homepage pour 1033 règles.

Les tests de Steve Sounders sont dont légèrement différents de ceux de Jon Sykes : il se limite à 2.000 liens et 2.000 règles CSS (et non plus 20.000) ce qui donne une page avec un DOM de 6.000 noeuds.
Il s’est également demandé si les résultats pour la page ne contenant aucun style et celle ne contenant qu’une seule règle sur la balise A n’avaient pas un gain en performance simplement parce que leur code contient 20.000 lignes de code en moins. Il a donc décidé de rajouter, pour ces deux cas, 2.000 règles CSS (qui ne s’appliquent sur rien du tout) afin que la taille des codes HTML soit pratiquement la même pour tous les cas de test.

Bref des tests sur un DOM plus réduit et plus proche de la réalité et des cas de tests de même volume.

Ses tests montrent des résultats assez différents de ceux de Jon Sykes, comme le montre son graphique :

On constate que la plupart des navigateurs conservent des courbes relativement “planes”. Comme le dit Steve, sur les principaux navigateurs (IE6&7 + FF3), la différence entre le test sans style et le test avec les sélecteurs fils ou descendants est en moyenne de 20ms et sur la totalité des navigateurs ça monte à une moyenne de 50ms. Donc un résultat difficile à percevoir à l’oeil nu.

Les résultats de Jon Sykes n’était donc pas vraiment applicable. Mais pourquoi une telle différence de résultats ?

Pour comprendre ce changement, Steve Sounders (qui est décidément très curieux) a décidé de refaire passer son test sur IE6&7 (ce sont les navigateurs pour lesquels il avait la différence la plus flagrante avec les tests de Jon) en les faisant tourner sur des pages ayant de plus en plus de balise A (et par conséquent de noeuds DOM et de règles CSS). Il a donc commencé avec 1.000 liens et a augmenté jusqu’à atteindre les 20.000 du test de Jon.

C’est avec ce test qu’il a constaté un palier autour de 18.000 noeuds, comme le montre son second graph :

En définitive, que devons-nous tirer de ces deux analyses ?
Simplement que la recherche d’optimisation n’est finalement pas dans l’utilisation parcimonieuse des sélecteurs CSS. Dans la plupart des cas le gain sera négligeable et risquerait d’entraîner une baisse de lisibilité du code pour les développeurs.