La corrélation entre nombre de règles CSS et le temps de reflow me semble plus claire. J’aurais aussi apprécié de voir une courbe du nombre de déclarations CSS, et pourquoi pas du nombre de nœuds DOM, et du nombre total de déclarations appliqués aux différents nœuds (moyennant quelques multiplications savantes). Les deux critères retenus dans ce graphique ne me semblent pas être les plus intéressants, même s’ils sont plus simples à obtenir. :/

Quand la CSS globale devient trop importante tu peux exploser ta CSS en plein de petits fichiers côté développement et chaque type de page va chercher un fichier CSS qui sera en fait juste l’aggrégation des différents petits fichiers utiles. Pas besoin de dupliquer le code côté développement.

Après effectivement, avoir une CSS différente par type de page met en échec partiel le cache sur les feuilles de style. Il faudra retélécharger la CSS à chaque fois que tu passes sur un nouveau type de page. C’est à toi de faire les calculs pour voir ce qui est intéressant suivant la taille de ta CSS globale, ce que tu peux gagner en différenciant les CSS sur chaque type de page, le nombre de pages visitées en moyenne par tes visiteurs, la proportion de nouveaux visiteurs.

J’avais fait un de mes premiers billets sur cette problématique http://performance.survol.fr/2008/03/strategies-doptimisation-du-cache/
Yahoo a aussi publié quelques stats sur l’utilisation du cache qui peuvent modérer le côté négatif d’avoir des CSS différentes http://yuiblog.com/blog/2007/01/04/performance-research-part-2/

Concernant les reflow, je ne vois pas pourquoi ça serait le cas mais je n’en sais rien, à tester.

Par contre tu devrais de toutes façons concaténer ta reset.css et ta CSS principale. Vu le faible poids de la reset, la séparer n’a aucun bénéfice ou presque

Bref, comme je suis « webmaster » d’un seul mais gros site, je pense beaucoup à l’aspect maintenance. Et je ne me vois pas du tout faire 1 grosse CSS par section contenant à chaque fois les mêmes instructions pour tout l’entourage et la structure du site : seule la partie centrale change beaucoup selon le type de contenu (annuaire, magazine, agenda, fiche technique, lexique, boutique…).

Si je veux donc faire des CSS « légères » et éviter de tout faire en 1 seul fichier, je pense finalement que je n’ai pas d’autre choix que d’appeler 2 CSS : template.css d’environ 10 à 20Ko et ensuite, 1 CSS par type de contenu (article.css, annuaire.css, agenda.css…).
Sachant qu’on tourne à environ 160.000 visiteurs uniques par mois en moyenne, et sachant qu’actuellement j’utilise 2 feuilles CSS : une reset.css de 3Ko et surtout une CSS géante de 75Ko et 2800 lignes comprenant quasiment toutes les instructions du site (quelque soit le contenu central), je pense que scinder mes CSS ne pourra être que bénéfique, je me trompe ?

Question (peut-être idiote) : les reflow sont-ils encore plus lents lorsqu’ils sont générés par 2 instructions se trouvant dans des CSS différentes ou non ?
Exemple : dans la CSS template, j’indique un style par défaut pour mon h1{color:#777; font-size:1.5em}, puis dans ma CSS de type article, j’indique h1 {color:#FFF;background-color:red;padding:0 5px;}.
(je sais que je vais déjà perdre un peu de temps à faire 2 requêtes HTTP différentes…).

La reflexion que vous menez est la bonne, mais savoir quand faire une seule CSS et quand faire une CSS par type de page, ça dépend de votre traffic, de vos CSS, de vos statistiques, etc. Difficile de répondre de manière générale.

Est-ce moi qui suit tordu ou bien vous êtes-vous aussi fait ce raisonnement ? Comment gérez vous ce genre de problématique pour des gros sites ?

Sur un petit appareil type iPhone, je peux imaginer que l’on ai quelque chose à gagner de relativement important. En revanche, sur un ordinateur de bureau, je suis perplexe. J’aimerais quelques graphs comparitifs, sur des exemples types (page Amazon complexe, blog WordPress standard, page HTML simple).

@Louis:

Pas beaucoup de chiffres, c’est trop dépendant de la CSS et de la page.

On sait toutefois que les expressions et les filter ralentissent la page avec des délais de l’ordre de 100ms, ce qui est déjà pas mal. On sait aussi que la phase de rendu est fortement impactée par la complexité et l’écriture des CSS, et ça se joue à chaque reflow (cf graphique plus haut).

Google et Steve Souders ont l’air de beaucoup se focaliser sur les CSS en ce moment. Je n’ai pas plus d’infos à apporter pour ma part malheureusement. Disons que c’est beaucoup moins simple à (dé)montrer que les systèmes de cache ou de requêtes HTTP, donc il reste à croire sur paroles qu’ils ont effectivement obtenu de bons résultats.

Je crois que Nicole Sullivan travaille un peu là dessus, à refaire des CSS plus légères pour améliorer les perfs. Si ça vous intéresse je peux tenter de lui poser quelques questions et publier ça ici.

Aurais tu un site montrant les bonnes et mauvaises pratique en terme de sélecteurs CSS ?