Votre affirmation selon laquelle vous êtes mieux avec un fichier CSS plus gros est correcte. Il ne sera probablement que de quelques Ko lorsqu'il est compressé, et devrait être mis en cache, donc pas une énorme surcharge. Il y a cependant quelques points à vérifier.
Si du CSS n'est utilisé que sur une seule page, il peut être préférable dans ce cas de mettre le CSS sur la page, dans certaines balises de style. (Remarque: cela peut rendre les choses difficiles à maintenir, surtout lorsque vous décidez ultérieurement d'utiliser un style similaire ailleurs.)
Si vous prenez vos pages les plus populaires (par exemple, les pages qui représentent 50% + de vos pages vues) et constatez que seule une très petite quantité de votre CSS est utilisée sur ces pages, il peut être plus rapide pour les utilisateurs de la diviser en deux fichiers CSS. Désormais, les nouveaux utilisateurs visitant vos pages les plus populaires ont beaucoup moins à télécharger. Sur d'autres pages, il y a une demande HTTP supplémentaire, mais ce n'est pas énorme.
Assurez-vous que votre CSS est bien optimisé. Évitez les sélecteurs descendants lorsque cela est possible. Si le côté droit d'un sélecteur est trop générique, cela peut ralentir le temps de rendu. Par exemple, ce .class div {}
serait un peu lent car le navigateur doit vérifier chaque <div>
élément de la page, puis rechercher l'arborescence DOM tout en haut pour trouver (ou non) un élément avec la classe.
Chèvre mécontente
la source
Je pense que c'est une lacune de l'outil speedtest que vous utilisez, qu'il ne regarde pas l'ensemble du site et ne voit pas du tout quel CSS n'est jamais utilisé. Si vous pouvez trouver un outil qui fonctionne, faites-le nous savoir!
Oui, cela a du sens, à moins qu'il y ait un ensemble de pages qui nécessitent un peu de CSS supplémentaire, auquel cas vous pouvez l'inclure sur celles-ci.
la source
media="print"
- certains navigateurs n'émettront pas la demande jusqu'à ce que vous tentiez réellement d'imprimer / prévisualiser la page.Il existe un petit plug-in Firefox pratique appelé Dust-Me Selectors , qui vérifie votre CSS et signale toutes les règles inutilisées. Cependant, cela ne fonctionne pas avec la dernière version de Firefox (v8.0), ce qui est un peu dommage.
PS: Si j'étais vous, je prendrais CSS Lint avec une pincée de sel - il y a une école de pensée qui dit que ses «recommandations» sont pédantes, et simplement exagérées. (Pour plus de détails, voir l'article convaincant de Matt Wilcox, « CSS Lint is nocif » ). Au mieux, ce n'est pas du tout officiel… et, avouons-le, avons-nous vraiment besoin d'un autre outil / pseudo-standard pour satisfaire?
la source
La façon la plus optimisée et évolutive que j'imagine de gérer cela consiste à:
Création d' un fichier CSS principal pour tout ce qui concerne la "portée globale" (comme la conception du site, les classes globales, les bibliothèques, les plugins, etc ...).
Création d'un système impliquant un dossier contenant un fichier CSS unique par pages (uniquement si nécessaire). Ces fichiers peuvent avoir le même nom de fichier que la page à laquelle ils sont liés afin que vous puissiez exécuter un script côté serveur sur chaque page qui recherche un fichier CSS dans ce dossier et l'ajouter à la page s'il y en a un.
Peut-être, en créant différents fichiers CSS pour des choses spécifiques au navigateur que vous ne chargez que lorsque le visiteur a le navigateur correspondant.
En faisant cela, vous vous retrouverez avec un moyen solide et optimisé de séparer votre CSS. Oui, il y aura toujours des règles inutilisées dans le fichier principal, mais elles seront là où elles sont censées être d'un point de vue logique.
Gardez également à l'esprit que ces 3 "couches" de fichiers CSS seront mises en cache comme le serait un seul fichier CSS.
la source