拥有一个包含几乎每个页面都要使用的样式元素的怪物.css文件有什么好处吗?
我在想，为了便于管理，我想把不同类型的CSS拉出到几个文件中，并包括我的主<link />是坏的吗?
我觉得这样更好
positions.css buttons.css tables.css copy.css
vs.
site.css
你见过用一种方法做和用另一种方法做有什么问题吗?
当前回答
存在一个临界点，在这个临界点上使用多个css文件是有益的。
一个拥有100万以上页面的网站，平均用户可能只看到其中的5个，可能有一个巨大的样式表，所以试图通过大量的初始下载来节省每次页面加载的单个额外请求的开销是虚假的经济。
把这个论点延伸到极致——这就像是建议整个网络应该维护一个大的样式表。显然是荒谬的。
每个网站的临界点都不一样，所以没有硬性规定。这将取决于每个页面的唯一css数量、页面数量以及普通用户在使用网站时可能经常遇到的页面数量。
其他回答
单个CSS文件的优点是传输效率高。每个HTTP请求意味着每个请求的文件都有一个HTTP头响应，这需要占用带宽。
我把我的CSS作为一个PHP文件，在HTTP头中带有“text/ CSS”mime类型。这样，我可以在服务器端拥有多个CSS文件，并在用户请求时使用PHP include将它们推入单个文件。每个现代浏览器都会接收包含CSS代码的.php文件，并将其作为. CSS文件处理。
捆绑的样式表可以节省页面加载性能，但是样式越多，浏览器在页面上呈现动画的速度就越慢。这是由于大量未使用的样式可能不在您所在的页面上，但浏览器仍然需要计算。
参见: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">
也许可以看看compass，这是一个开源的CSS创作框架。 它基于Sass，所以它支持一些很酷的东西，比如变量、嵌套、mixin和导入。如果您想要保持独立的较小CSS文件，但将它们自动合并为一个(避免多次缓慢的HTTP调用)，则导入非常有用。 Compass在此基础上增加了一组预定义的mixin，便于处理跨浏览器的东西。 它是用Ruby编写的，但是它可以很容易地用于任何系统....
我更喜欢在开发过程中使用多个CSS文件。这样管理和调试就容易得多。但是，我建议你在部署时使用像YUI Compressor这样的CSS缩小工具，它可以将你的CSS文件合并成一个整体文件。
这个问题很难回答。在我看来，这两种选择各有利弊。
我个人不喜欢阅读一个巨大的CSS文件，维护它是非常困难的。另一方面，分离它会导致额外的http请求，这可能会降低速度。
我的观点有两种。
1)如果你知道你的CSS一旦你构建了它就永远不会改变，我会在开发阶段构建多个CSS文件(为了可读性)，然后在正式运行前手动组合它们(以减少http请求)
2)如果你知道你会偶尔改变你的CSS，并且需要保持它的可读性，我会构建单独的文件，并使用代码(如果你使用某种编程语言)在运行时构建时将它们组合起来(运行时缩小/组合是一个资源猪)。
无论是哪种选择，我都强烈建议在客户端进行缓存，以进一步减少http请求。
编辑: 我发现了这个博客，它展示了如何在运行时只使用代码就组合CSS。值得一看(尽管我自己还没有测试过)。
编辑2: 我决定在设计时使用单独的文件，并通过构建过程来缩小和合并。这样，我可以有单独的(可管理的)css，而我开发和一个适当的整体缩小文件在运行时。我仍然有我的静态文件和更少的系统开销，因为我没有在运行时进行压缩/缩小。
注意:对于你的购物者，我强烈建议使用捆绑器作为构建过程的一部分。无论您是从IDE内部构建，还是从构建脚本构建，捆绑器都可以通过包含的exe在Windows上执行，也可以在任何已经运行node.js的机器上运行。
