Commentaires sur : Performance des sélecteurs CSS

Par : Éric

Éric — Mon, 11 Aug 2008 19:21:37 +0000

Oh, des problèmes à résoudre il y en a (toujours) plusieurs. Le site parfait n’existe pas et il y a toujours un historique à supporter. Le notre est en partie cette CSS gigantesque (mais pas uniquement)

Par : Louis

Louis — Mon, 11 Aug 2008 16:37:56 +0000

Je pense que quand on en est à 100 ko de CSS, on a un problème à résoudre :/

Néanmoins, si contrainte il y a, alors oui je comprend que tu sois obliger de surveiller les performances CSS.

Par : Éric

Éric — Mon, 11 Aug 2008 13:25:39 +0000

Je n’aime pas ce « enfin » étant donné que dès le départ il est clairement dit que ça ne vaut pas le coup de réécrire quoi que ce soit.
Maintenant, c’est à voir. Des sites avec plus de 40ko de CSS ça devient courant. Je suis là sur un site à très fort traffic et malheureusement la CSS principale fait 100ko non compressée. Les pages HTML ne sont pas super légères non plus et contiennent bien plus de noeuds DOM que souhaitable.

Avec le nombre de règles et de noeuds DOM, si un tiers ajoutent un * en fin de règle, les différences sont tout de même visibles. La phase de rendu c’est entre un quart et la moitié de l’occupation du moteur (stat de MSIE), quand ça occupe autant au total on ne peut pas simplement dire « tout est équivalent »

Mais l’important et l’objectif du billet c’est effectivement surtout la compréhension des mécanismes et du pourquoi on fait tout ça. Je lutte contre les fausses optimisations et les fausses croyances, par exemple les gens qui ajoutent des critères en pensant que ça précise donc que ça accélère.

Par : Louis

Louis — Mon, 11 Aug 2008 12:02:05 +0000

À 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.

Dans le billet qui fait suite à celui-ci, tu comprends enfin que ces idées sont démesurées comparées aux gains de performances quasi-nuls qu’elles permettent. Bien sûr, ça reste très intéressant à étudier :)

J’avais fait des recherches dans ce sens il y a un certain temps déjà, concernant le sélecteur universel (*). Un développeur Mozilla m’a confirmé que son impact sur les performances était ridicule, et que le seul cas où l’on pouvait fignoler la dessus, c’est le cas d’un site très complexe, sur un lecteur mobile ; dans ce cas seulement, on peut constater éventuellement des ralentissements.

Par : Éric

Éric — Mon, 12 May 2008 18:48:04 +0000

Puis qu’il faut parler des gains concrets et expliciter clairement l’implication de ces informations sommes toutes négligeables, voilà quelques informations supplémentaires sur http://performance.survol.fr/2008/05/gains-de-performance-des-selecteurs-css/

Par : Oliv G.

Oliv G. — Thu, 08 May 2008 09:18:54 +0000

Tout à fait d’accord avec Sunny, quand cela est possible, il est plus « classe » (ptite blague de geek) de faire un code XHTML le plus clean possible. Cela ne veut pas dire que je considère que les classes ou les ID pourrissent la feuille de style (ne caricaturons pas) mais éviter de mettre des classes dans tout les sens permet d’avoir un document XHTML propre, facile à la compréhension et encore une fois, plus facile à maintenir.
Il y a des cas concret ou pour justement pallier aux faiblesses de IE, on est dans l’obligation de mettre pour le premier élément d’une liste à puce la classe « first-child » afin de créer une pseudo-pseudo-classe :) Mais s’il est possible d’avoir un document XHTML pur, c’est mieux.

Et puis, il ne faut pas que l’optimisation de la feuille CSS se fasse au détriment du document XHTML et vice versa.

Par : Comme une image

Comme une image — Wed, 07 May 2008 08:43:54 +0000

Le gros soucis avec le sélecteur enfant, c’est qu’il n’est pas compatible IE6.
D’où sa rareté dans les feuilles de style que j’ai pu croiser pour l’instant (je précise que je ne suis pas du tout spécialiste du CSS). Faut-il faire une CSS par navigateur pour optimiser les performances de rendu ou ne pas trop se casser le c** et accepter de faire perdre, quoi ?, quelques µs en écrivant
p span { … } plutôt que p > span { …} ?

Par : Rik

Rik — Tue, 06 May 2008 12:17:07 +0000

J’en ai discuté un peu avec Dave Hyatt (auteur original du document) et il disait que ce document été principalement écrit pour les applis en XUL. C’est à dire de gros documents, avec de grosses CSS complexes.

Il m’a aussi précisé que ces conseils s’adaptent à Webkit (ce n’est pas étonnant). C’était une discussion informelle, ne pas prendre au pied de la lettre, tout ça.

Par : Éric

Éric — Tue, 06 May 2008 12:12:06 +0000

C’est une question à laquelle je n’ai pas la réponse. Le gain de performance est probablement réduit par rapport à ce que peut apporter le cache ou les modifications qui ont trait au réseau.
Bref, je doute qu’il soit pertinent de commencer à réécrire ses feuilles de style, par contre ça ne peut pas faire de mal à connaître quand on rédige une nouvelle CSS.

Pour l’aspect dev+maintenance Vs performance c’est la question persistante quelle que soit la technique mise en oeuvre. Si tu veux faire des tests j’en discuterai avec plaisir, je ne demande que ça.

Pour l’instant j’ai justement tendance à penser que les gains sont assez faibles et que je perdrai mon temps à faire des tests. Bref, le temps personnel est cher et il y a d’autres choses dans ma liste qui sont AMHA plus importantes à tester.

Par : Sunny

Sunny — Tue, 06 May 2008 12:07:00 +0000

Plus rapide d’accord, mais de quel ordre ? Quels sont les gains ?

Je trouve aberrant de voir des dizaines de

...

à la suite…

Est ce que cela vaut le coup d’optimiser ses sélecteurs CSS quitte à rendre les feuilles de style moins lisibles et le code html plus lourd ?