[BP#22] Limiter le nombre de CSS

[Fred-artwai]

Dans la description il est noté "Si plusieurs feuilles de style sont utilisées sur toutes les pages du site, concaténez-les dans un seul fichier." Je pense que c'est daté HTTP/1 et "peut-être" contreproductif, notamment dans le cadre d'un site responsif. La solution que je recommande est plutôt de faire un fichier par media queries. Exemple :

<link rel='stylesheet' id='css-css'  href='communs.css' type='text/css' media='all' />
<link rel='stylesheet' id='css-xs-css'  href='petits-ecrans.css' type='text/css' media='(max-width: 959px)' />
<link rel='stylesheet' id='css-sm-css'  href='tablettes.css' type='text/css' media='(min-width: 768px)' />
<link rel='stylesheet' id='css-mdlg-css'  href='grands-ecrans.css' media='(min-width: 960px)' />
<link rel='stylesheet' id='css-print-css'  href='print.css' type='text/css' media='print' />

Dès lors, le navigateur va charger en priorité ce qui le concerne et va déprioriser le reste. C'est moins de travail pour le rendu CSS et donc çà sollicite moins le device.
çà rejoint la BP21 Découper les CSS et la BP27 Fournir une CSS print

Par contre, la compression n'a rien à faire là dedans. Cela doit être dans une autre BP.

[florinesueur]

Si je comprends bien, tu changes "Limiter le nombre de CSS" par quelque chose du genre "Découper les fichiers CSS par media queries".

[Fred-artwai]

Pas vraiment, limiter le nombre de CSS me va bien.
C'est le cotés systématique de "concaténez-les dans un seul fichier" qui me dérange.

Je supprimera çà dans la description et je le remplacerai par
Limiter de le nombre de CSS à un maximum de 10 par page en préférant les découper par media queries
[mettre un exemple]
et proscrire les @import.

[tbroyer]

10 par page c'est un peu énorme non ? (ou alors on parle de l'ensemble des fichiers "disponibles", et pas ceux réellement utilisés)
Pour moi ça n'a pas de sens de parler des fichiers "disponibles". Dans ton exemple, il n'y en aurait que 2 sur les 5 qui seraient utilisés à un moment donné, et puisque le but est en fait de limiter le nombre de requêtes HTTP, c'est plutôt les fichiers utilisés qu'il faut surveiller.

+1 pour reformuler dans ce sens (et explicitement proscrire les @import)

Au lieu de "en préférant les découper par media queries", je pense que ce serait mieux de dire que si on a des feuilles de style alternative (par exemple par media queries), alors on peut (devrait ?) factoriser ce qui est partagé dans une feuille de style séparée.

[Fred-artwai]

J'ai dis 10 car c'est la référence Dareboost. Tu as généralement 3 à 5 paliers de références dans une CSS responsive. Mais tu peux avoir des petits fichiers chargés conditionnellement à la page pour un composant X ou Y. Du coup, 10 çà me semble pas déconnant.

Après reste le poids de tout çà mais on est sur une autre BP : je recommande pour la webperf un poids max décompressé de 50ko pour la commune et la CSS spécifique aux smartphones, reprenant ainsi la contrainte originale d'AMP désormais à 75ko. Les autres excèdent rarement les 20ko.

[DocRoms]

Je suis plutôt d'accord avec ça , en spécifiant que l'un ne va pas sans l'autre :
On peut déjà réduire et limiter les CSS puis les séparer par palier de media-queries. Ca va effectivement améliorer (beaucoup) la génération du CSSTree :)

L'ancienne description était surement due à une vielle bonne pratique pour accélérer le premier rendu des éléments au dessus de la ligne de flottaison vu que les CSS étaient en général éparpillés : le temps de résolution DNS + la connexion et le DDL de chaque fichier CSS étaient > à un seul gros fichier (ce qui n'est plus aussi évident depuis HTTP/2).

🎉 Le fait de découper les CSS rentre aussi dans la case écoConception, vu que la taille des fichiers téléchargés sera bien plus petit qu'un seul gros fichier.

🤔 Il faudrait peut-être rajouter un point pour spécifier d'avoir les styles des éléments présents au dessus de la ligne de flottaison dans le premier fichier CSS si il y en a plusieurs ;) (c'est plus un tips #webPerf qu' #ecoConception mais, on peut facilement gagner des demi-secondes d'affichage si il y a des éléments bloquant dedans, ce qui peut éviter à l'utilisateur de trouver le site lent, et de revenir en arrière pour consulter le site d'après 😅)

[florinesueur]

@DocRoms Tu penses au critical css ?

[ACTLEM]

Vu le consensus :-), j'ai créé l'issue pour modification: #293

[ldevernay]

Je profite de la V5 pour faire remonter cette discussion (et l'issue correspondante) : à mon sens, cette bonne pratique doit être reformulée. Le découpage des fichiers CSS peut au contraire être bénéfique pour tirer du multiplexing et la définition du chemin critique.

[ldevernay]

En complément, je pense qu'il serait intéressant de plutôt mettre en avant la bonne pratique "Découper les CSS".