Un seul fichier .css unique par rapport à plusieurs fichiers .css plus petits?

Y a-t-il un avantage à avoir un seul fichier .css contenant des éléments de style qui seront utilisés sur presque toutes les pages?

Je pense que pour faciliter la gestion, je voudrais sortir différents types de CSS dans quelques fichiers, et inclure tous les fichiers dans mon est-ce que c’est mauvais?

Je pense que c’est mieux

  1. positions.css
  2. buttons.css
  3. tables.css
  4. copy.css

contre.

  1. site.css

Avez-vous vu des pièges à le faire d’une manière ou d’une autre?

Un compilateur CSS tel que Sass ou LESS est un excellent moyen de procéder. De cette façon, vous serez en mesure de fournir un fichier CSS unique et minimisé pour le site (qui sera beaucoup plus petit et plus rapide qu’un fichier source CSS normal), tout en conservant l’environnement de développement le plus agréable, tout étant divisé en composants.

Sass et LESS ont l’avantage supplémentaire des variables, de l’imbrication et d’autres façons de rendre le CSS plus facile à écrire et à gérer. Fortement recommandé. J’utilise personnellement Sass (syntaxe SCSS) maintenant, mais j’ai utilisé LESS précédemment. Les deux sont excellents, avec des avantages similaires. Une fois que vous avez écrit CSS avec un compilateur, il est peu probable que vous souhaitiez vous en passer.

http://lesscss.org

http: //sass-lang.com

Si vous ne voulez pas gâcher avec Ruby, ce compilateur MOINS pour Mac est génial:

http://incident57.com/less/

Ou vous pourriez utiliser CodeKit (par les mêmes gars):

http://incident57.com/codekit/

WinLess est une interface graphique Windows pour comstackr LESS

http://winless.org/

C’est difficile à répondre. Les deux options ont leurs avantages et leurs inconvénients à mon avis.

Personnellement, je n’aime pas lire un seul fichier HUGE CSS, et le maintenir est très difficile. D’un autre côté, le fractionnement entraîne des requêtes http supplémentaires qui pourraient ralentir les choses.

Mon opinion serait l’une des deux choses.

1) Si vous savez que votre CSS ne changera JAMAIS une fois que vous l’aurez construit, je créerai plusieurs fichiers CSS au stade du développement (pour des raisons de lisibilité), puis les combinerai manuellement avant de les mettre 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 devez le garder lisible, je créerais des fichiers séparés et utiliserais du code (à condition d’utiliser un langage de programmation) pour les combiner à temps d’exécution de l’exécution (la minification / combinaison à l’exécution est un cochon de ressource).

Avec l’une ou l’autre option, je recommande fortement la mise en cache côté client afin de réduire davantage les requêtes HTTP.

MODIFIER:
J’ai trouvé ce blog qui montre comment combiner CSS au moment de l’exécution en n’utilisant que du code. Cela vaut la peine de regarder (même si je ne l’ai pas encore testé).

EDIT 2:
J’ai décidé d’utiliser des fichiers séparés au moment de la conception et un processus de génération pour réduire et combiner. De cette façon, je peux avoir des css séparés (gérables) pendant que je développe et un fichier minifié monolithique approprié au moment de l’exécution. Et j’ai toujours mes fichiers statiques et moins de temps système parce que je ne fais pas de compression / minification à l’exécution.

note: pour vous, les acheteurs, je vous conseille fortement 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 via l’ exe inclus ou peut être exécuté sur n’importe quel ordinateur qui exécute déjà node.js.

Je préfère plusieurs fichiers CSS au cours du développement. La gestion et le débogage sont beaucoup plus faciles. Cependant, je suggère que, au moment du déploiement, vous utilisiez plutôt un outil de miniaturisation CSS comme YUI Compressor qui fusionnera vos fichiers CSS en un seul fichier monolithique.

Avoir un seul fichier CSS est préférable pour le temps de chargement de vos pages, car cela signifie moins de requêtes HTTP.

Avoir plusieurs petits fichiers CSS signifie que le développement est plus facile (du moins, je le pense: avoir un fichier CSS par module de votre application facilite les choses) .

Donc, il y a de bonnes raisons dans les deux cas …

Une solution qui vous permettrait de tirer le meilleur parti des deux idées serait:

  • Développer en utilisant plusieurs petits fichiers CSS
    • c’est-à-dire plus facile à développer
  • Pour avoir un processus de construction pour votre application, cela “combine” ces fichiers en un seul
    • Ce processus de construction pourrait également réduire ce gros fichier, btw
    • Cela signifie évidemment que votre application doit avoir des éléments de configuration qui lui permettent de passer du “mode multi-fichiers” au “mode mono-fichier”.
  • Et pour utiliser, en production, uniquement le gros fichier
    • c’est-à-dire des pages de chargement plus rapides

Il existe également des logiciels qui combinent des fichiers CSS au moment de l’exécution et non au moment de la construction. mais le faire à l’exécution signifie consumr un peu plus de CPU (et nécessite un certain mécanisme de mise en cache, pour ne pas recréer trop souvent le gros fichier)

Vous voulez les deux mondes.

Vous voulez plusieurs fichiers CSS parce que votre santé mentale est une chose terrible à gaspiller.

Dans le même temps, il est préférable d’avoir un seul fichier volumineux.

La solution consiste à avoir un mécanisme qui combine les fichiers multiples dans un seul fichier.

Un exemple est quelque chose comme

  

Ensuite, le script allcss.php gère la concaténation des fichiers et leur livraison.

Idéalement, le script vérifierait les dates de modification de tous les fichiers, créerait un nouveau composite si l’un d’entre eux change, puis renvoie ce composite, puis vérifie les en-têtes HTTP If-Modified afin de ne pas envoyer de CSS redondant.

Cela vous donne le meilleur des deux mondes. Fonctionne très bien pour JS aussi.

Les feuilles de style monolithiques offrent de nombreux avantages (décrits dans les autres réponses). Cependant, en fonction de la taille globale du document de feuille de style, vous pourriez rencontrer des problèmes dans IE. IE a une limitation avec le nombre de sélecteurs qu’il lira dans un seul fichier . La limite est de 4096 sélecteurs. Si votre feuille de style monolithique aura plus que cela, vous voudrez la diviser. Cette limitation ne fait que grimper dans IE.

Ceci est pour toutes les versions d’IE.

Voir le blog de Ross Bruniges et la page MSDN AddRule .

Il y a un sharepoint basculement au cours duquel il est avantageux d’avoir plus d’un fichier CSS.

Un site avec des pages 1M +, que l’utilisateur moyen ne verra probablement que 5, pourrait avoir une feuille de style de proportions immenses. Il est donc faux d’essayer d’enregistrer la surcharge d’une seule requête supplémentaire par chargement de page en téléchargeant un téléchargement initial massif économie.

Étirez l’argument à l’extrême limite – c’est comme suggérer qu’il devrait y avoir une grande feuille de style pour l’ensemble du Web. Clairement insensé.

Le sharepoint basculement sera différent pour chaque site, il n’y a donc pas de règle ssortingcte. Cela dépendra de la quantité de CSS unique par page, du nombre de pages et du nombre de pages que l’utilisateur moyen est susceptible de rencontrer en cours d’utilisation du site.

J’ai généralement une poignée de fichiers CSS:

  • un fichier CSS “global” pour les réinitialisations et les styles globaux
  • “module” css fichiers spécifiques pour les pages qui sont regroupés de manière logique (peut-être chaque page dans un assistant de caisse ou quelque chose)
  • “page” fichiers css spécifiques pour les remplacements sur la page (ou mettez ceci dans un bloc sur la page individuelle)

Je ne suis pas vraiment préoccupé par les demandes de pages multiples pour les fichiers CSS. La plupart des utilisateurs disposent d’une bande passante décente et je suis sûr que d’autres optimisations auront un impact bien plus important que la combinaison de tous les styles en un seul fichier CSS monolitique. Le compromis est entre vitesse et maintenabilité, et je me tourne toujours vers la maintenabilité. Le YUI Comperssor semble plutôt cool, je devrais peut-être vérifier cela.

Jetez un oeil à Compass , qui est un framework de création CSS open source. Il est basé sur Sass , il prend en charge des choses intéressantes comme les variables, l’imbrication, les mixins et les importations. Les importations sont particulièrement utiles si vous souhaitez conserver des fichiers CSS plus petits et séparés, mais les combiner automatiquement en 1 (en évitant plusieurs appels HTTP lents). Compass ajoute à cela un grand ensemble de mixins prédéfinis faciles à manipuler. C’est écrit en Ruby mais il peut facilement être utilisé avec n’importe quel système ….

Je préfère plusieurs fichiers CSS. De cette façon, il est plus facile d’échanger des “skins” à l’intérieur de votre corps. Le problème avec un fichier monolithique est qu’il peut devenir incontrôlable et difficile à gérer. Que faire si vous voulez des fonds bleus mais que vous ne voulez pas que les boutons changent? Modifiez simplement votre fichier d’arrière-plans. Etc.

voici le meilleur moyen:

  1. créer un fichier css général avec tout le code partagé
  2. Insérez tout le code CSS de la page spécifique dans la même page, sur la balise ou en utilisant l’atsortingbut style = “” pour chaque page

De cette façon, vous n’avez qu’un seul CSS avec tout le code partagé et une page HTML. au fait (et je sais que ce n’est pas le bon sujet) vous pouvez aussi encoder vos images en base64 (mais vous pouvez aussi le faire avec vos fichiers js et css). De cette façon, vous réduisez encore plus les requêtes HTTP à 1.

SASS et LESS rendent tout cela vraiment discutable. Le développeur peut configurer des fichiers de composants efficaces et les comstackr tous ensemble. Dans SASS, vous pouvez désactiver le mode compressé en cours de développement pour en faciliter la lecture et le réactiver pour la production.

http://sass-lang.com http://lesscss.org

En fin de compte, un fichier CSS minifié est ce que vous voulez, quelle que soit la technique utilisée. Moins de CSS, moins de requêtes HTTP, moins de demande sur le serveur.

L’avantage d’un fichier CSS unique est l’efficacité du transfert. Chaque requête HTTP signifie une réponse d’en-tête HTTP pour chaque fichier demandé et qui prend la bande passante.

Je sers mon CSS en tant que fichier PHP avec le type mime “text / css” dans l’en-tête HTTP. De cette façon, je peux avoir plusieurs fichiers CSS côté serveur et utiliser PHP pour les envoyer dans un seul fichier à la demande de l’utilisateur. Chaque navigateur moderne reçoit le fichier .php avec le code CSS et le traite comme un fichier .css.

Vous pouvez simplement utiliser un fichier css pour les performances, puis commenter les sections comme ceci:

 /******** Header ************/ //some css here /******* End Header *********/ /******** Footer ************/ //some css here /******* End Footer *********/ 

etc

J’utilise Jammit pour gérer mes fichiers CSS et utiliser de nombreux fichiers différents pour la lisibilité. Jammit fait tout le sale travail de la combinaison et de la compression des fichiers avant le déploiement en production. De cette façon, j’ai beaucoup de fichiers en développement, mais un seul fichier en production.

J’ai créé une approche systématique du développement des CSS. De cette façon, je peux utiliser une norme qui ne change jamais. J’ai d’abord commencé avec le système de grid 960. Ensuite, j’ai créé des lignes simples de CSS pour les dispositions de base, les marges, le remplissage, les fonts et les tailles. Je les enchaîne ensuite au besoin. Cela me permet de conserver une mise en page cohérente dans tous mes projets et d’utiliser les mêmes fichiers CSS à plusieurs resockets. Parce qu’ils ne sont pas spécifiques. Voici un exemple: —- div class = “c12 bg0 m10 p5 fl blanc” / div — Cela signifie que le conteneur contient 12 colonnes, utilise bg0 avec des marges de 10px padding de 5, le texte est blanc et il flotte la gauche. Je pourrais facilement changer cela en supprimant ou en ajoutant un nouveau – Ce que j’appelle un style “léger” – au lieu de créer une classe unique avec tous ces atsortingbuts; Je combine simplement les styles simples lorsque je code la page. Cela me permet de créer toute combinaison de styles et ne limite pas ma créativité ni de créer un grand nombre de styles similaires. Vos feuilles de style deviennent beaucoup plus faciles à gérer, réduites au minimum et vous permettent de les réutiliser encore et encore. Cette méthode s’est avérée fantastique pour la conception rapide. Je ne conçois pas non plus d’abord dans le PSD mais dans le navigateur, ce qui permet également de gagner du temps. En outre, parce que j’ai également créé un système de nommage pour mes arrière-plans et mes atsortingbuts de conception de page, je modifie simplement mon fichier image lors de la création d’un nouveau projet (bg0 = fond de corps selon mon système de nommage). Le fond avec un projet en changeant simplement en noir signifie simplement que sur le projet suivant, bg0 sera un fond noir ou une autre image ….. Je n’ai pas encore trouvé de problème avec cette méthode et cela semble fonctionner très bien.

Une feuille de style intégrée peut économiser les performances de chargement de la page, mais plus il y a de styles, plus le rendu des animations sur la page que vous utilisez est lent. Cela est dû à la quantité énorme de styles inutilisés qui peuvent ne pas figurer sur la page sur laquelle vous vous trouvez, mais le navigateur doit toujours calculer.

Voir: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

Avantages des feuilles de style groupées: – performances de chargement de la page

Inconvénients des feuilles de style groupées: – Comportement plus lent, qui peut causer du désordre pendant le défilement, l’interactivité, l’animation,

Conclusion: pour résoudre ces deux problèmes, pour la production, la solution idéale consiste à regrouper tous les css dans un seul fichier pour enregistrer les requêtes http, mais utilisez javascript pour extraire de ce fichier, le CSS de la page sur laquelle vous vous trouvez. .

Pour savoir quels composants partagés sont nécessaires par page et réduire la complexité, il serait intéressant d’avoir déclaré tous les composants utilisés par cette page, par exemple:

   

Historiquement, l’un des principaux avantages de x un seul fichier CSS est la rapidité d’utilisation de HTTP1.1.

Cependant, en mars 2018, plus de 80% des navigateurs supportaient maintenant HTTP2. HTTP2 permet au navigateur de télécharger plusieurs ressources simultanément tout en étant capable de pousser des ressources de manière préventive. Avoir un seul fichier CSS pour toutes les pages signifie une taille de fichier plus grande que nécessaire. Avec une conception correcte, je ne vois aucun avantage à le faire si ce n’est plus facile à coder.

La conception idéale pour HTTP2 pour de meilleures performances serait: -Avoir un fichier CSS de base contenant les styles communs utilisés sur toutes les pages. -Have CSS spécifique à la page dans un fichier séparé -Utilisez HTTP CSS push pour minimiser le temps d’attente (un cookie peut être utilisé pour empêcher les poussées répétées) -Souvent en option au-dessus du pli CSS et poussez d’abord le CSS -bandwidth mobile devices) -Vous pouvez également charger les CSS restants pour le site ou des pages spécifiques après le chargement de la page si vous souhaitez accélérer le chargement des pages futures.