单个巨大的.css文件与多个较小的特定.css文件？[关闭]

拥有一个包含将在几乎所有页面上使用的样式元素的单个Monster .css文件有什么好处？

我在想，为了便于管理，我想将不同类型的CSS提取到几个文件中，并在我的主文件中包含每个文件，这<link />有什么不好吗？

我觉得这样比较好

1. positions.css
2. button.css
3. table.css
4. copy.css

与

1. site.css

您有没有看到一种相对于另一种方法的陷阱？

像Sass或LESS这样的CSS编译器是一种不错的选择。这样，您将能够为该站点交付一个最小化的CSS文件（它将比普通的单个CSS源文件小得多，并且速度更快），同时保持最佳的开发环境，并将所有内容整齐地分成组件。

Sass和LESS具有变量，嵌套和其他使CSS易于编写和维护的其他方式的优点。高度推荐。我现在个人使用Sass（SCSS语法），但是以前使用LESS。两者都很棒，具有相似的好处。用编译器编写CSS后，如果没有CSS，就不太可能想做。

http://lesscss.org

http://sass-lang.com

如果您不想弄乱Ruby，那么适用于Mac的LESS编译器非常有用：

http://incident57.com/less/

或者您可以使用CodeKit（由同一个人）：

http://incident57.com/codekit/

WinLess是一个Windows GUI，用于连接LESS

http://winless.org/

这是一个很难回答的问题。我认为这两种选择都有其优缺点。

我个人不喜欢阅读单个巨大的CSS文件，并且维护它非常困难。另一方面，将其拆分会导致额外的http请求，这可能会减慢速度。

我认为这是两件事之一。

1）如果您知道自己的CSS永远不会改变，那么我将在开发阶段构建多个CSS文件（以提高可读性），然后在上线之前手动组合它们（以减少http请求）

2）如果您知道不时要更改CSS，并且需要保持可读性，那么我将构建单独的文件并使用代码（假设您使用某种编程语言）在以下位置将它们组合在一起运行构建时间（运行时最小化/组合是资源消耗）。

无论使用哪种方法，我都强烈建议在客户端进行缓存，以进一步减少http请求。

编辑：
我发现这个博客展示了如何在运行时仅使用代码就结合CSS。值得一看（尽管我自己还没有测试过）。

编辑2：
我已经决定在设计时使用单独的文件，并采用最小化和组合的构建过程。这样，我可以在开发时拥有单独的（可管理的）css，并在运行时拥有适当的整体式缩小文件。而且我仍然拥有我的静态文件，并减少了系统开销，因为我没有在运行时进行压缩/压缩。

注意：对于那些在那里购物的人，我强烈建议在您的构建过程中使用捆绑程序。无论是从IDE内部构建，还是从构建脚本构建，捆绑程序都可以通过Windows中包含的捆绑程序执行，exe也可以在已经运行node.js的任何计算机上运行。

我更喜欢在开发过程中使用多个CSS文件。这样，管理和调试就容易得多。但是，我建议在部署时改用CSS最小化工具（如YUI Compressor），它将CSS文件合并为一个整体文件。

你想要两个世界。

您需要多个CSS文件，因为您的理智浪费了。

同时，最好有一个大文件。

解决方案是采用某种机制将多个文件合并为一个文件。

一个例子是

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

然后，allcss.php脚本处理文件的串联并传送它们。

理想情况下，脚本将检查所有文件的修改日期，如果其中任何文件发生更改，则创建一个新的组合，然后返回该组合，然后对照If-Modified HTTP标头进行检查，以免发送多余的CSS。

这使您两全其美。同样适用于JS。

只包含一个CSS文件对于页面的加载时间会更好，因为这意味着更少的HTTP请求。

拥有几个CSS文件意味着开发更容易（至少，我认为是这样：每个应用程序模块一个CSS文件使事情变得更容易）。

因此，在两种情况下都有充分的理由...

一个可以让您充分利用这两个想法的解决方案是：

• 使用几个小的CSS文件进行开发
  • 即更容易开发
• 要为您的应用程序创建一个构建过程，该过程将这些文件“组合”为一个
  • 该构建过程还可以缩小该大文件，顺便说一句
  • 显然，这意味着您的应用程序必须具有一些配置内容，才能从“多文件模式”切换到“单文件模式”。
• 在生产中仅使用大文件
  • 即更快地加载页面

也有一些软件可以在运行时（而不是在构建时）组合CSS文件。但是在运行时执行此操作意味着要消耗更多的CPU （并且显然需要一些缓存机制，以免过于频繁地重新生成大文件）

从历史上看，拥有单个CSS文件的主要优势之一是使用HTTP1.1时的速度优势。

但是，截至2018年3月，超过80％的浏览器现在支持HTTP2，这允许浏览器同时下载多个资源以及能够抢先推送资源。所有页面只有一个CSS文件意味着文件大小超出了必要。通过适当的设计，除了易于编码之外，我看不到这样做的任何优势。

HTTP2以获得最佳性能的理想设计是：

• 有一个核心CSS文件，其中包含所有页面使用的通用样式。
• 在单独的文件中包含页面特定的CSS
• 使用HTTP2推送CSS可以最大程度地减少等待时间（可使用cookie来防止重复推送）
• （可选）在折叠式CSS上方分离并先推送，然后再加载其余CSS（适用于低带宽移动设备）
• 如果要加快将来的页面加载速度，也可以在页面加载后为网站或特定页面加载剩余的CSS。

整体样式表确实提供了很多好处（在其他答案中有描述），但是根据样式表文档的整体大小，您可能会在IE中遇到问题。IE有一个限制，即它将从一个文件中读取多少个选择器。限制为4096个选择器。如果您使用的是整体样式表，那么您将需要拆分它。此限制只会使它在IE中变得丑陋。

这适用于IE的所有版本。

请参阅Ross Bruniges博客和MSDN AddRule页面。

有一个转折点，拥有多个css文件有益。

一个拥有超过1M页的网站（普通用户可能只看到其中的5个）的样式表可能具有巨大的比例，因此，通过进行大量的初始下载来尝试节省每个页面加载单个额外请求的开销是错误的经济。

将参数扩展到极限-就像建议为整个Web维护一个大的样式表。显然是荒谬的。

尽管每个站点的转折点都不同，所以没有硬性规定。这将取决于每页唯一CSS的数量，页数以及普通用户在使用该网站时可能经常遇到的页数。

我通常有一些CSS文件：

• 用于重置和全局样式的“全局” css文件
• 逻辑分组页面的“模块”特定css文件（可能是结帐向导中的每个页面等）
• 用于页面上替代的“页面”特定css文件（或将其放在单个页面上的块中）

我不太关心CSS文件的多个页面请求。大多数人的带宽都不错，我敢肯定还有其他优化措施比将所有样式组合到一个单一的CSS文件中具有更大的影响。折衷是在速度和可维护性之间，而我始终倾向于可维护性。不过，YUI压缩器听起来很酷，我可能必须检查一下。

我更喜欢多个CSS文件。这样一来，您就可以更轻松地交换“皮肤”。一个整体文件的问题在于它可能会失控并且难以管理。如果您想要蓝色背景但又不想更改按钮怎么办？只需更改您的背景文件。等等。

也许看看指南针，这是一个开放源代码CSS创作框架。它基于Sass，因此它支持诸如变量，嵌套，mixins和import之类的很棒的东西。如果要保留单独的较小CSS文件但将它们自动合并为1（避免多次缓慢的HTTP调用），则导入尤其有用。指南针为此添加了一大堆预定义的mixin，可轻松处理跨浏览器的内容。它是用Ruby编写的，但是可以很容易地在任何系统上使用。

这是最好的方法：

1. 使用所有共享代码创建通用的CSS文件
2. 将所有特定页面的CSS代码插入到同一页面中，在标记上，或对每个页面使用style =“”

这样，您只有一个带有所有共享代码的CSS和一个HTML页面。顺便说一句（我知道这不是正确的主题），您还可以在base64中编码图像（但也可以使用js和css文件来编码）。这样，您可以将更多的http请求减少到1。

SASS和LESS使得这一切真正成为问题。开发人员可以设置有效的组件文件，并在编译时将它们全部合并。在SASS中，您可以在开发时关闭“压缩模式”，以便于阅读，然后再将其打开以进行生产。

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

最后，无论您使用哪种技术，都只需要一个缩小的CSS文件。更少的CSS，更少的HTTP请求，更少的服务器需求。

单个CSS文件的优点是传输效率。每个HTTP请求意味着对每个请求的文件的HTTP标头响应，并且占用带宽。

我将CSS作为PHP文件提供，在HTTP标头中使用“ text / css” mime类型。这样，我可以在服务器端拥有多个CSS文件，并使用PHP包括在用户请求时将它们推送到单个文件中。每个现代的浏览器都会接收带有CSS代码的.php文件，并将其作为.css文件进行处理。

您可以只使用一个css文件来提高性能，然后注释掉以下部分：

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

等等

我正在使用Jammit处理我的CSS文件，并使用许多不同的文件来提高可读性。Jammit并不会在将产品部署到生产环境中之前完成所有合并和压缩文件的工作。这样，我正在开发许多文件，但在生产中只有一个文件。

捆绑的样式表可能会节省页面加载性能，但是样式越多，浏览器在您所在页面上呈现动画的速度就越慢。这是由于您的页面上可能没有大量未使用的样式而导致的，但浏览器仍然需要计算。

参见：https : //benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

捆绑样式表的优点： -页面加载性能

样式表捆绑 在一起的缺点： -行为较慢，在滚动，交互性，动画，

结论： 要解决这两个问题，对于生产而言，理想的解决方案是将所有css捆绑到一个文件中以保存在http请求上，但是使用javascript从该文件中提取您所在页面的css并用其更新页眉。

为了知道每页需要哪些共享组件并降低复杂性，最好声明此特定页面使用的所有组件-例如：

<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">

我为CSS开发创建了一种系统的方法。这样，我就可以利用永远不变的标准。首先，我从960网格系统开始。然后，我为基本布局，边距，填充，字体和大小创建了一行CSS。然后，根据需要将它们串在一起。这使我可以在所有项目中保持一致的布局，并一遍又一遍地使用相同的CSS文件。因为它们不是特定的。这是一个示例：---- div class =“ c12 bg0 m10 p5 white fl” / div ---这意味着该容器的宽度为12列，利用bg0的边距为10px填充为5，文本为白色，并且浮动剩下。我可以通过删除或添加新的样式来轻松更改此样式-我称之为“轻型”样式-无需创建具有所有这些属性的单个类；在编写页面代码时，我只是简单地组合了单个样式。这使我可以创建样式的任何组合，并且不会限制我的创造力，也不会导致我创建大量相似的样式。您的样式表变得更加易于管理，最小化，并允许您反复使用它。我发现这种方法非常适合快速设计。我也不再首先在PSD中进行设计，而是在浏览器中进行设计，这也节省了时间。另外，因为我还为背景和页面设计属性创建了一个命名系统，所以我在创建新项目时只需更改图像文件即可。（bg0 =根据我的命名系统生成的主体背景）这意味着如果我以前有一个白色一个项目的背景，只需将其更改为黑色就意味着在下一个项目中，bg0将是黑色背景或另一张图像...