Y a-t-il un avantage à avoir un seul fichier .css monstre qui contient les éléments de style qui seront utilisés sur presque toutes les pages ?
Pour faciliter la gestion, j'aimerais regrouper les différents types de CSS dans quelques fichiers, et inclure chaque fichier dans mon fichier principal. <link /> C'est mauvais ?
Je pense que c'est mieux
vs.
Avez-vous constaté des problèmes en procédant d'une manière ou d'une autre ?
Il est difficile de répondre à cette question. Les deux options ont leurs avantages et leurs inconvénients à mon avis.
Personnellement, je n'aime pas lire un seul ÉNORME fichier CSS, et sa maintenance est très difficile. D'un autre côté, le fait de le diviser entraîne des requêtes http supplémentaires qui peuvent potentiellement ralentir les choses.
Mon opinion serait l'une des deux choses suivantes .
1) Si vous savez que votre CSS ne changera JAMAIS une fois que vous l'aurez construit, je construirais plusieurs fichiers CSS pendant la phase de développement (pour la lisibilité), puis je les combinerais manuellement avant la mise en ligne (pour réduire les requêtes http).
2) Si vous savez que vous allez changer votre CSS de temps en temps, et que vous avez besoin de le garder lisible, je construirais des fichiers séparés et utiliserais du code (à condition que vous utilisiez une sorte de langage de programmation) pour les combiner à l'endroit suivant temps de fonctionnement le temps de construction (la minification/combinaison au moment de l'exécution est un véritable gouffre à ressources).
Quelle que soit l'option choisie, je recommande vivement la mise en cache côté client afin de réduire encore les requêtes http.
EDITAR:J'ai trouvé ceci blog qui montre comment combiner les CSS au moment de l'exécution en n'utilisant que du code. Cela vaut la peine d'y jeter un coup d'œil (même si je ne l'ai pas encore testé moi-même).
EDIT 2 :
J'ai décidé d'utiliser des fichiers séparés lors de la conception, et un processus de construction pour minifier et combiner. De cette façon, je peux avoir des fichiers css séparés (gérables) pendant que je développe et un fichier minifié monolithique approprié au moment de l'exécution. J'ai toujours mes fichiers statiques et moins de surcharge système car je ne fais pas de compression/minification au moment de l'exécution.
note : pour les acheteurs, je vous conseille vivement d'utiliser bundler dans le cadre de votre processus de construction. Que vous construisiez à partir de votre IDE ou d'un script de construction, bundler peut être exécuté sous Windows par le biais de l'outil inclus exe ou peut être exécuté sur n'importe quelle machine qui exécute déjà node.js.
Outre la réduction du nombre de requêtes HTTP, le fichier monolithique unique présente-t-il des avantages ? Mes css peuvent changer au fil du temps, mais le nombre d'utilisateurs sera assez faible, la plupart accédant via des connexions à haut débit. Je pense donc que l'avantage des fichiers multiples sera bien plus important que la diminution des requêtes HTTP...
La rétention des visiteurs est la priorité numéro 1, donc si votre page se charge lentement, il y a moins de chances qu'ils restent. Si vous avez la possibilité de combiner (je vois que vous utilisez asp.net), je vous recommande vivement de le faire. C'est le meilleur des deux mondes.
"Donc je pense que l'avantage des fichiers multiples sera bien plus important que la diminution des requêtes http..." Non, non, non... exactement le contraire. Avec une connexion à haut débit, le temps de traitement des requêtes HTTP est le goulot d'étranglement. Par défaut, la plupart des navigateurs ne téléchargent que deux fichiers à la fois, donc les navigateurs effectuent 2 requêtes, attendent, téléchargent rapidement les fichiers css, envoient 2 autres requêtes, attendent, téléchargent rapidement les fichiers. Contrairement à une demande HTTP pour un seul fichier css qui est téléchargé rapidement. La communication avec le serveur serait la partie lente.
Un compilateur CSS comme Sass ou LESS est une excellente solution. De cette façon, vous serez en mesure de fournir un seul fichier CSS minimisé pour le site (qui sera bien plus petit et plus rapide qu'un fichier source CSS unique normal), tout en conservant un environnement de développement agréable, avec tout bien séparé en composants.
Sass et LESS présentent l'avantage supplémentaire d'offrir des variables, des imbrications et d'autres moyens de rendre les CSS plus faciles à écrire et à maintenir. Très, très fortement recommandé. J'utilise personnellement Sass (syntaxe SCSS) maintenant, mais j'utilisais LESS auparavant. Les deux sont excellents et présentent des avantages similaires. Une fois que vous avez écrit du CSS avec un compilateur, il est peu probable que vous souhaitiez vous en passer.
Si vous ne voulez pas vous embêter avec Ruby, ce compilateur LESS pour Mac est excellent :
Ou vous pouvez utiliser CodeKit (par les mêmes personnes) :
http://incident57.com/codekit/
WinLess est une interface graphique Windows pour compiler LESS.
Je préfère avoir plusieurs fichiers CSS pendant le développement. La gestion et le débogage sont beaucoup plus faciles de cette façon. Toutefois, je suggère qu'au moment du déploiement, vous utilisiez plutôt un outil de réduction des CSS tel que Compresseur YUI qui fusionnera vos fichiers CSS en un seul fichier monolithique.
Je ne connais pas votre installation, mais ça ne me semble pas être une bonne idée. Vous devriez tester les changements avant de les pousser vers l'extérieur.
Le fait de n'avoir qu'un seul fichier CSS est meilleur pour le temps de chargement de vos pages, car cela signifie moins de requêtes HTTP.
Le fait de disposer de plusieurs petits fichiers CSS facilite le développement (du moins, je le pense : avoir un fichier CSS par module de votre application rend les choses plus faciles) .
Il y a donc de bonnes raisons dans les deux cas...
Une solution qui vous permettrait d'obtenir le meilleur des deux idées serait :
Il existe également des logiciels qui combinent les fichiers CSS au moment de l'exécution, et non au moment de la construction ; mais le faire au moment de l'exécution signifie consommer un peu plus de CPU. (et nécessite évidemment un mécanisme de mise en cache, pour ne pas re-générer le gros fichier trop souvent).
Je pense que cette excellente réponse gagnerait à mentionner au moins les techniques css possibles pour tenir compte des collisions. Par exemple, si vous avez une css modulaire et que deux classes ont le même nom, la classe la plus récente ou la plus spécifique l'emportera, ce qui donnera un résultat inattendu en production.
Les feuilles de style monolithiques offrent de nombreux avantages (décrits dans les autres réponses), mais en fonction de la taille globale du document de feuille de style, vous pourriez rencontrer des problèmes avec IE. IE est limité par le nombre de sélecteurs qu'il peut lire à partir d'une feuille de style monolithique. fichier unique . La limite est de 4096 sélecteurs. Si votre feuille de style monolithique dépasse cette limite, vous devrez la diviser. Cette limitation n'apparaît que dans IE.
Ceci est valable pour toutes les versions d'IE.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
2 votes
Il s'agit d'une VRAIE vieille question, mais confronté au même problème, j'ai trouvé celui que je pense être la meilleure solution au cas où quelqu'un d'autre arriverait sur cette page. Plusieurs fichiers qui sont compressés par PHP et envoyés par une seule requête.
4 votes
@FrankPresenciaFandos faire cela est ok'ish pour un site à faible trafic, mais exécuter ce script à plusieurs reprises sur des sites à fort trafic semble un peu décalé. Si vous utilisez un script de construction, vous pouvez avoir le meilleur des deux mondes et maintenir un serveur web performant puisqu'il n'exécute pas le script php (jamais).
2 votes
Il ne serait exécuté qu'à chaque fois que le css est modifié, et il faudrait alors inclure le fichier css résultant.