Optimisation des CSS

[casasierrasalamanca]

je lis ici et ailleurs: regroupe les CSS sur un seul fichier.
Si j'ai plusieurs styles (une dizaine) qui s'appliquent à differentes pages, n'est ce pas logique, comme je l'ai fait, d'avoir un fichier general des styles communs à toutes les pages, et un autre fichier specifique à ces pages. Plutot que de tout mettre sur un meme fichier et dont la moitie ne servira pas à la page concernée.
C'est plus rapide à telecharger un super gros fichier que 2 plus petits?

 

[nervusdm]

C'est ça.
Ca fait moins de requête /get

 

[loubet]

perso, je préfére avoir plusieurs fichiers différents, un général et des particuliers pour une partie des sites. après, il faut que le nombre de fichiers css inclus reste faible.

 

[zeb]

La logique du regroupement en un seul fichier tiens a la particularité des navigateurs qui veux qu'ils conservent le fichier CSS en cache local et qu'ils ne le redemandent pas pour les pages suivantes du même domaine.
Bref avoir 5/6 fichiers en fonction de zones du site est pas forcement aussi interessant qu'en avoir un gros qui comprend tout.

Dans tous les cas le first Load d'une page est important c'est les suivantes qui profitent de l'optimisation.
Après avoir fondamentalement plusieurs fichiers CSS très différents pour un site a design compartimenté indique souvent que la charte graphique globale est bancales car c'est rare de changer fondamentalement de style entre deux sections, c'est souvent qques images de fond qui changent et des couleurs bref pas grand chose ... ce qui ne devrait pas géner un CSS global.

 

[colonies]

La logique du regroupement en un seul fichier tiens a la particularité des navigateurs qui veux qu'ils conservent le fichier CSS en cache local et qu'ils ne le redemandent pas pour les pages suivantes du même domaine.
Bref avoir 5/6 fichiers en fonction de zones du site est pas forcement aussi interessant qu'en avoir un gros qui comprend tout.

Au contraire, c'est mieux d'avoir plusieurs fichiers. Non seulement ça évite de charger tout un tas de CSS inutiles mais en plus ça permet de mieux utiliser le cache.
Si tu regroupes tout en un seul fichier, la moindre petite modification va forcer à recharger la grosse CSS quelle que soit la page.
Si tu compartimentes, seules les pages vraiment affectées par les changements auront besoin de recharger une CSS (plus légère).

 

[zeb]

Ah bah ouais ... c'est vrai que la feuille de style tu la change tous les jours :lol: que du coup tu spécifie un header cache ultra court et que surtout tu utilise pas de CDN des fois qu'un internaute a Tombouctou ai le malheur de pas voir que tu as passé le lien en bleu France a la place du bleu roi ...

Et concernant le "CSS inutile" il ne l'est que pour une page donnée pas pour le site hors un CSS en cache navigateur il est là pour le site pas pour LA page d’atterrissage ....

 

[colonies]

Ah bah ouais ... c'est vrai que la feuille de style tu la change tous les jours

pas tous les jours mais toutes les semaines, sans doute.

que du coup tu spécifie un header cache ultra court et que surtout tu utilise pas de CDN des fois qu'un internaute a Tombouctou ai le malheur de pas voir que tu as passé le lien en bleu France a la place du bleu roi ...

euh... mais comment tu gères le développement de tes sites, toi ? pour que les css soient mises à jour et synchronisées avec le reste de ta page tu ne fais rien, tu attends que le cache de tes visiteurs expire ?

n'oublie pas non plus que même si tu demandes au navigateur de mettre tes ressources en cache :
- l'utilisateur peut vider son cache
- un logiciel tiers peut aussi le vider (certains anti-virus par exemple), ou un réglage du navigateur qui efface tout à la fermeture
- le cache n'est pas infini et par conséquent entre deux visites, tes ressources peuvent avoir été supprimées
- ... tout particulièrement sur les appareils mobiles qui ont des tout petits caches.

 

[noren]

En même temps vous avez des css de plusieurs centaines de ko ou quoi? :mrgreen:
Pas certain que ca soit au niveau de la découpe des css qu'il faille optimiser. D'ailleurs on voit parfoit des sites qui découpent également leurs fichiers javascript (un fichier par fonction)
Ils se retrouvent avec plus d'une dizaines de fichiers a télécharger rien qu'en css et javascript. Autant dire que meme dans ce cas sans un CDN question otomisation c'est pas terrible terrible.

Donc quitte a utiliser un CDN autant tout regrouper dans un fichier. Et éventuellement faire une CSS uniquement dediée pour les mobiles si elle est vraiment trop grosse (car a mon avis c’est uniquement pour les mobiles qu'il est peut être nécessaire de se soucier du poids de la CSS).

En ce qui me concerne j'utilise 2 css sur toutes mes pages (pour mes nouveaux projets). le 1er est celui du framework bootstrap (98 ko, c’est un peu lourd mais pas dramatique), le 2eme très très léger concerne mes petites retouches (5ko pas plus). De cette façon j'évite en cas de MAJ de bootstrap de tout perdre.

Je rejoint également l'avis de zeb, un site ou il y a des changements importants de présentation en fonction des sections est "peut être" à la base un site mal pensé. C’est peut être de ce côté qu'il faudrait envisager une optimisation ?

on fait deja assez d'include , de chargement d'images, de requêtes etc donc beaucoup de GET, il est peut être inutile d'en rajouter avec les CSS et les fichiers javascript.

Il n'y a pas possibilité de compresser les css?

 

[colonies]

je crois que vous vous faites de fausses idées sur les CDN. pour un site vraiment très international ça peut avoir une utilité, en particulier s'il est à fort trafic. sinon ça peut avoir un effet négatif puisque ça demande une résolution DNS supplémentaire et une nouvelle connexion au navigateur. il y a beaucoup de facteurs à prendre en compte qui font qu'un CDN est ou n'est pas intéressant.

les outils qui donnent automatiquement des conseils d'optimisation recommandent systématiquement de tout grouper en un seul fichier bien que ça ne soit pas optimal : c'est facile à comprendre et c'est un assez bon conseil pour les webmasters qui débutent dans l'optimisation des performances. souvent ils gagneront à suivre ce conseil "un peu" bourrin.
pour autant, ça n'est pas une vérité absolue. vérifiez vous-même avec WebPageTest.org ou les infos réseau de votre navigateur ce qui se passe si vous divisez une grosse CSS en deux plus petites. Eh oui : les CSS se téléchargent en parallèle.

un site ou il y a des changements importants de présentation en fonction des sections est "peut être" à la base un site mal pensé. C’est peut être de ce côté qu'il faudrait envisager une optimisation ?

avoir plusieurs CSS est inévitable pour les gros sites. par exemple s'il comporte un forum (qui généralement a en plus un messagerie privée, etc.) : pourquoi charger toutes ces ressources dès la page d'accueil ? et quand tu as plusieurs grosses rubriques, des composants riches... ça gonfle très vite.
bien sûr si le site n'a que 10 pages simples, c'est pas la peine de tout éclater, mais avec de vraies rubriques ayant chacune des dizaines de pages derrière c'est fortement recommandé.

Il n'y a pas possibilité de compresser les css?

si, comme pour toutes les ressources dont le format n'est pas compressé il faut utiliser la compression "à la volée" (Gzip, généralement). Utiliser la minification est également recommandé.


Quoiqu'il en soit, toutes ces histoires de nombre de ressources et compagnie viennent des problèmes de TCP et HTTP 1.1.
Pour ma part je suis passé à SPDY qui est supporté par la majorité des navigateurs des utilisateurs de mon site.
Avec le multiplexing on cherche plutôt à éviter de répartir les ressources sur plusieurs domaines et on n'a plus vraiment besoin de fusionner les fichiers. A tel point que ce qui fonctionnait avec HTTP 1.1 devient souvent contre-productif (et le sera également avec HTTP 2.0). Ca réduit aussi nettement l'intérêt des CDN dans certains cas, du coup.
https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/

 

[zeb]

@colonies > Le problème c'est surtout que 90% des sites sont codés avec les pieds

Les webmaster développent de moins en moins ils se contentent pour beaucoup d’agréger des ressources a coup de plugin qui eux chargent des bibliothèques prémâchées qu'ils n'utilisent qu'a 10% bref les header html sont pour beaucoup des nids a scripts pour faire clignoter un smileys ... :cry:

il comporte un forum (qui généralement a en plus un messagerie privée, etc.)

Mouais ... sur les CMS classiques du genre c'est la même présentation que le reste ...

des composants riches... ça gonfle très vite.

Tu sort du contexte je cite :

Si j'ai plusieurs styles (une dizaine) qui s'appliquent à différentes pages

on parle pas de la même chose je pense. Toi tu défend un découpage stratégique ça se conçoit ça se mesure, mais le sujet ici c'est pas ça, du moins c'est pas comme ça que je le perçoit, voir ma remarque sur les biblio a la con en début de réponse. Je pense qu'on est dans une logique ici qui consiste a unifier un petit site et pas dans une logique gros portail ...
Hors si on parle de gros portail oui tu ne vas pas tout balancer dans un unique script là ou tu auras de toute façon du travail issue de dizaine de personne différentes au niveau du design déjà ... de même tu aura peut être une logique de sous domaine qui viendra se greffer dessus ce qui rend le sujet encore différent.

 

[colonies]

Si j'ai plusieurs styles (une dizaine) qui s'appliquent à differentes pages

on parle pas de la même chose je pense

ah oui ! :lol:
J'étais resté là-dessus :

C'est plus rapide à telecharger un super gros fichier que 2 plus petits?

effectivement, une (ou même quelques) dizaine(s) de styles de plus ça a peu de chances de se terminer en "un super gros fichier" :mrgreen:

 

[noren]

Apres ne faut-il pas prendre en compte le critère serveur : mutualisé ou dédié?

Sur un mutualisé malgré les sois disant débits illimités etc. un des principaux freins c’est les GET (hits), donc si on souhaite resté sur du mutu il est peut être dans ce cas préférable d'opter pour une seule CSS et un seule fichier javascript. Comme le dit Zeb, en évitant d'avoir de scripts inutiles qui alourdissent les pages pour rien.

Je suis d'accord concernant le CDN mais ici je parlais de l'avantage qu'il procure au niveau de la limitaion du nombre de GEt au niveau du serveur. Après qu'il demande une résolution DNS, faudrait encore pouvoir comparer en faisant tel ou tel choix. Ca dépend aussi peut être des CDN non?

Tiens j'en profite pour glisser une petite question, pour le Jquery vous préférez faire ceci :

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

ou le stocker sur votre serveur? Qu'est-ce qui est plus optimisé?

 

[colonies]

sur un dédié : j'héberge moi-même.
sur un mutu... peut-être le CDN, vu que les mutu sont souvent très, très lents.

par contre je n'utiliserais pas le code que tu as indiqué mais celui de google :
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

si tu précises https tu vas toujours avoir en plus l'étape de négociation SSL qui prend un certain temps. si ton site est en http, ça ne sert à rien et c'est du temps de perdu.
quand tu ne mets que //, le navigateur va ajouter le même protocole que celui de ta page (donc http si ton site est en http, https si tu es en https). tu évites l'étape de négociation SSL et si un jour tu décidais de passer au https, le code serait déjà ok.

 

[zeb]

j'en profite pour glisser une petite question, pour le Jquery vous ...

Perso la première question que je me poserais c'est qu'est ce que je vais utiliser dans JQuery ? si c'est pour des anims graphiques je bazarde sans hésiter au profit d'un peu de CSS3 ...

 

[noren]

@colonies : merci je ne savais pas pour les // :wink:

@zeb : j'utilise le framework bootstrap et il s'en sert, notamment pour le carousel et divers outils que je devrais utiliser. J'en ai également besoin t pour plusieurs raisons sur des parties de codes plus personnelles (pas forcément liées a bootstrap).
Je pourrais passer par du javascript pur mais bon...

Par contre ce que je vais peut être faire c’est effectivement de charger ce script uniquement sur les pages qui en ont besoin (pour le moment il est sur tous mes footer).

Après j'essaye surtout d'optimiser mes requêtes et le nombre de hits. :wink:

 

[casasierrasalamanca]

alors, je mets ensemble ou je laisse mes 2 fichiers CSS par page ? (un global d'environ 10 KB et un autre specifique à chaque page (ou pour plusieurs page identiques) de 2kb)

 

[zeb]

tu chipote pour 12 Ko en one shoot :roll: tourne toi qu'on te mette une petit coup de pied au fesse

 

[zeb]

Je pourrais passer par du javascript pur mais bon...

Je te demandais ça car j'ai utilisé comme tout le monde, au moins pour voir, et au final pour ce que j'en faisait ça tenais dans 20 liges de JS :roll:
pour les carrousels ça y est j'ai entamé la grande migration 0JS je passe tout en CSS3 et je prévoie un background fixe sur le truc pour ceux qui sont pas compatibles.
Pour la petite histoire G+ arrivait plu a charger mes pages (les plus grosses bourrée de photos et des mots) et depuis que j'ai viré les carrousels ça passe comme une fleure ...

 

[noren]

@casasierrasalamanca : pour 12ko, utilise une seule CSS. A ce niveau la il n'y a même pas à se poser de question :wink:
T'aurais d'ailleurs dû commencer par là :mrgreen:

@zeb : disons que j'ai l'impression d'être en retard et pas dans l'air du temps si je n'utilise pas javascript, jquery (ajax).Alors j'essaye de m'en servir la ou ca me semble réellement judicieux de le faire. Même si j'ai toujours été adepete du 0JS (non seulement parceque je ne le maitrise pas, mais également pour ne pas alourdir de code). mais en même temps j'aimerais me faire la main en JS, jquery et ajax.

Par contre je ne voix absolument pas comment on pourrait faire un carousel uniquement via le CSS3.
Actuellement j'ai 3 images qui défilent, les 3 je les intègre dans mon CSS (ceci afin d'éviter de charger les images inutilement sur mobiles grâce a media queries). Mais pour faire le défilement c’est le javascript qui s'en occupe. je ne vois pas comment en html et css on pourrait gérer ça

 

[indigene]

alors, je mets ensemble ou je laisse mes 2 fichiers CSS par page ? (un global d'environ 10 KB et un autre specifique à chaque page (ou pour plusieurs page identiques) de 2kb)

Quand j'ai des pages qui doivent avoir une présentation différentes au niveau de certaines balises génériques ou des classes génériques, je préfère faire un nouveau script CSS qui contient tout (avec les changements) et qui sera appelé sur les pages en question uniquement, et à la place du script général. Ca permet de faire des hits en moins. Le seul problème c'est que je dois faire les modifs dans plusieurs scripts si j'ai des changements. Mais je trouve cela plus propre que de découper mon script général en plein de petits scripts car dans 90% des cas c'est le script général qui sera appelé et seulement lui. Si tu découpes, tu te retrouves à devoir appeler 4 ou 5 scripts dans 90% des cas.

Même pour 2ko ça va se ressentir sur la vitesse. Ce n'est pas le poids du script qui génère un pb de lenteur, mais le hit. Exactement comme un include.

Pour bien comprendre, je vais caricaturer un peu avec des chiffres complètement bidon mais c'est pour illustrer :
- Supposons que pour télécharger 1ko tu mettes 1 seconde
- Supposons que pour générer un hit (la traduction d'une url en adresse ip physique) tu mettes 3 secondes
- si sur ta page tu as 1 script général appelé sur toutes les pages, il fait 10ko. Tu as ensuite 4 scripts qui font chacun 2ko

Cas 1 : 5 scripts appelés
10x1 + 2x1 + 2x1 + 2x1 + 2x1 + 5x3 = 18 + 15 = 33

Cas 2 : 1 seul script de 18 ko sur chaque page
18x1 + 1x3 = 18 + 3 = 21

Bien sur ça ne joue que sur la page d'atterrissage mais beaucoup d'internautes ne visitent qu'une seule page, la proportion des visites à 1 page est très importante.

Maintenant reprenons l'exemple avec une 2° page consultée où les 4 scripts sont différents sur cette page et seul le script général reste inchangé (c'est d'ailleurs son but à lui, qu'il ne change jamais quelle que soit la page) :
Cas 1 : 4 nouveaux scripts appelés :
2x1 + 2x1 + 2x1 + 2x1 + 4x3 = 8 + 12 = 20
Cas 2 : 1 nouveau script appelé :
18x1 + 1x3 = 18 + 3 = 21

A partir de la 2° page consultée les temps de chargement sont presque kif kif. C'est donc bien uniquement pour les visites à une page que tu vas gagner un gros paquet de temps en utilisant le moins de scripts possible.

 

[zeb]

Quand j'ai des pages qui doivent avoir une présentation différentes au niveau de certaines balises génériques ou des classes génériques, ...

Tu peux aussi parfois surclasser directement dans la page c'est moins propre mais si c'est occasionnel ça reste acceptable.

 

[casasierrasalamanca]

tu chipote pour 12 Ko en one shoot :roll: tourne toi qu'on te mette une petit coup de pied au fesse

je suis tous les conseils que je trouve sur le net. alors on me dit de comprimer les css, moi je comprime maintenant si c'est pas utile pour si peu, c'est du tarvail en moins..