单个巨大的。css文件vs.多个较小的特定。css文件?

拥有一个包含几乎每个页面都要使用的样式元素的怪物.css文件有什么好处吗?

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

我觉得这样更好

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

vs。

  1. site.css

你见过用一种方法做和用另一种方法做有什么问题吗?

161341 次浏览
小开

我更喜欢多个CSS文件。这样就可以更容易地根据需要将“皮肤”换入和换出。单一文件的问题在于，它可能会失控，难以管理。如果你想要蓝色背景但又不想改变按钮怎么办?只要改变你的背景文件。等。

小开

这个问题很难回答。在我看来，这两种选择各有利弊。

我个人不喜欢阅读一个巨大的CSS文件，维护它是非常困难的。另一方面，分离它会导致额外的http请求，这可能会降低速度。

我的观点有两种。

1)如果你知道你的CSS一旦你构建了它就永远不会改变，我会在开发阶段构建多个CSS文件(为了可读性)，然后在正式运行前手动组合它们(以减少http请求)

2)如果你知道你会偶尔改变你的CSS，并且需要保持它的可读性，我会构建单独的文件并使用代码(提供你使用某种编程语言)在运行时构建时将它们组合起来(运行时缩小/组合是一个资源猪)。

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

< p > 编辑: < br > 我发现这个博客显示了如何在运行时结合CSS只使用代码。值得一看(尽管我自己还没有测试过)

< p > 编辑2: < br > 我决定在设计时使用单独的文件，并通过构建过程来缩小和合并。这样，我可以有单独的(可管理的)css，而我开发和一个适当的整体缩小文件在运行时。我仍然有我的静态文件和更少的系统开销，因为我没有在运行时进行压缩/缩小

注意:对于你的购物者，我强烈建议使用捆绑器作为构建过程的一部分。无论你是从IDE中构建，还是从构建脚本，捆绑器都可以通过包含的exe在Windows上执行，或者可以在任何已经运行node.js的机器上运行。

小开

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

拥有几个小的CSS文件意味着开发更容易(至少，我是这么认为的:为应用程序的每个模块提供一个CSS文件会让事情变得更简单)。

所以，这两种情况都有很好的理由……

< p > < br > 一个可以让你得到两个想法的最好的解决方案是:

  • 使用几个小的CSS文件进行开发
    • 也就是更容易发展
      • 李< / ul > < / > 要为应用程序建立一个构建过程，将这些文件“组合”为一个文件
      • 顺便说一句，这个构建过程也可以缩小那个大文件
      • 这显然意味着你的应用程序必须有一些配置，允许它从“多文件模式”切换到“单文件模式”。
        • 李< / ul > < / >
      • 并且在生产中只使用大文件
        • 即更快的加载页面
          • 李< / ul > < / >

        也有一些软件可以在运行时组合CSS文件，而不是在构建时;但是在运行时这样做意味着要消耗更多的CPU (显然需要一些缓存机制，以避免频繁地重新生成大文件)

小开

我更喜欢在开发过程中使用多个CSS文件。这样管理和调试就容易得多。然而，我建议你在部署时使用像YUI Compressor这样的CSS缩小工具，它会将你的CSS文件合并成一个整体文件。

小开

单个CSS文件的优点是传输效率高。每个HTTP请求意味着每个请求的文件都有一个HTTP头响应，这需要占用带宽。

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

小开

你可以只使用一个css文件来提高性能，然后像这样注释掉部分:

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


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




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


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

等

小开

你想要两个世界。

您需要多个CSS文件，因为浪费您的理智是一件可怕的事情。

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

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

一个例子是

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

然后，allcss.php脚本处理连接文件并传递它们。

理想情况下，脚本会检查所有文件的mod日期，如果其中任何一个文件发生变化，则创建一个新的组合，然后返回该组合，然后检查if - modified HTTP头，以便不发送多余的CSS。

这让你两全其美。也适用于JS。

小开

整体样式表确实提供了很多好处(在其他答案中有描述)，但是根据样式表文档的总体大小，您在IE中可能会遇到问题。IE对从单独的文件中读取的选择器数量有限制。限制为4096个选择器。如果你是单片样式表，你会想要拆分它。这种限制只会在IE中暴露出来。

这适用于所有版本的IE。

参见Ross Bruniges博客和MSDN AddRule页面。

小开

我通常有一些CSS文件:

  • 一个用于重置和全局样式的“全局”CSS文件
  • “模块”特定的CSS文件用于逻辑分组的页面(可能是结帐向导或其他东西中的每个页面)
  • 用于覆盖页面的“page”特定CSS文件(或者，将其放在单个页面的块中)

我真的不太关心CSS文件的多页请求。大多数人都有不错的带宽，我相信还有其他优化会比将所有样式组合到一个单独的CSS文件中产生更大的影响。在速度和可维护性之间进行权衡，我总是倾向于可维护性。YUI压缩机听起来很酷，但我可能要检查一下。

小开

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

小开
也许可以看看指南针，这是一个开源的CSS创作框架。 它基于萨斯，所以它支持一些很酷的东西，比如变量、嵌套、混合和导入。如果您想要保持独立的较小CSS文件，但将它们自动合并为一个(避免多次缓慢的HTTP调用)，则导入非常有用。 Compass在此基础上增加了一组预定义的mixin，便于处理跨浏览器的东西。 它是用Ruby编写的，但它可以很容易地用于任何系统....

小开

以下是最好的方法:

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

这样你只有一个CSS所有共享代码和一个HTML页面。 顺便说一下(我知道这不是正确的主题)，你也可以在base64编码你的图像(但你也可以用你的js和CSS文件)。通过这种方式，您可以将更多的HTTP请求减少到1

小开

我创建了一个系统的CSS开发方法。这样我就可以利用一个永不改变的标准。首先我从960网格系统开始。然后我创建了单行css的基本布局，边距，填充，字体和大小。然后根据需要将它们串在一起。这允许我在所有项目中保持一致的布局，并一遍又一遍地利用相同的css文件。因为它们不具体。下面是一个例子:----div class="c12 bg0 m10 p5 white fl"/div——这意味着容器是12列，利用bg0有10像素的边距，填充5文本是白色的，它漂浮在左边。我可以通过删除或添加一个新的-我称之为“轻”风格-而不是创建一个具有所有这些属性的单一类;我只是在编写页面代码时将单个样式组合在一起。这允许我创建任何风格的组合，而不限制我的创造力或导致我创建大量的风格是相似的。您的样式表变得更加易于管理，最小化，并允许您反复使用它。我发现这种方法非常适合快速设计。我也不再首先在PSD中设计，而是在浏览器中设计，这也节省了时间。此外，因为我还为我的背景和页面设计属性创建了一个命名系统，所以在创建新项目时，我只需更改我的图像文件。(bg0 =身体背景根据我的命名系统)这意味着，如果我以前有一个白色的背景与一个项目简单地改变它为黑色仅仅意味着在下一个项目bg0将是一个黑色背景或另一个图像.....我还没有发现这个方法有什么问题，而且它似乎工作得很好。

小开
最佳答案

像Sass或LESS这样的CSS编译器是一个很好的方法。通过这种方式，你可以为网站交付一个最小化的CSS文件(这将比普通的单个CSS源文件小得多，速度也快得多)，同时保持最好的开发环境，所有东西都整齐地分割成组件。

Sass和LESS具有变量、嵌套和其他方法的附加优势，使CSS更容易编写和维护。强烈推荐。我个人现在使用Sass (SCSS语法)，但以前使用LESS。两者都很棒，好处相似。一旦你用编译器编写了CSS，你就不太可能不需要编译器。

http://lesscss.org < a href = " http://lesscss.org " > < / >

http://sass-lang.com < a href = " http://sass-lang.com " > < / >

如果你不想在Ruby上浪费时间，这个Mac版的LESS编译器非常棒:

http://incident57.com/less/ < a href = " http://incident57.com/less/ " > < / >

或者你可以使用CodeKit(同样的人):

http://incident57.com/codekit/ < a href = " http://incident57.com/codekit/ " > < / >

WinLess是一个用于编译LESS的Windows GUI

http://winless.org/ < a href = " http://winless.org/ " > < / >

小开

存在一个临界点，在这个临界点上使用多个css文件是有益的。

一个拥有100万以上页面的网站，平均用户可能只看到其中的5个，可能有一个巨大的样式表，所以试图通过大量的初始下载来节省每次页面加载的单个额外请求的开销是虚假的经济。

把这个论点延伸到极致——这就像是建议整个网络应该维护一个大的样式表。显然是荒谬的。

每个网站的临界点都不一样，所以没有硬性规定。这将取决于每个页面的唯一css数量、页面数量以及普通用户在使用网站时可能经常遇到的页面数量。

小开

SASS和LESS使这一切都成为一个有争议的问题。开发人员可以建立有效的组件文件，并在编译时将它们全部组合起来。在SASS中，您可以在开发过程中关闭压缩模式以方便阅读，并在生产过程中切换回来。

http://sass-lang.com http://lesscss.org < / p >

最后，不管你使用什么技术，一个简化的CSS文件就是你想要的。更少的CSS，更少的HTTP请求，更少的服务器需求。

小开

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

看: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文件的主要优势之一是使用HTTP1.1时的速度优势。

然而，截至2018年3月，超过80%的浏览器现在支持HTTP2，它允许浏览器同时下载多个资源，以及能够预先推送资源。为所有页面使用一个CSS文件意味着文件大小大于所需大小。有了适当的设计，我不认为这样做有任何好处，除了更容易编码。

HTTP2的最佳性能的理想设计是:

  • 有一个核心CSS文件，其中包含所有页面使用的常用样式。
  • 有页面特定的CSS在一个单独的文件
  • 使用HTTP2推送CSS来最小化等待时间(可以使用cookie来防止重复推送)
  • 可选地在折叠CSS上面分开，先推这个，然后再加载剩下的CSS(适用于低带宽移动设备)
  • 如果您想加快未来的页面加载速度，还可以在页面加载后加载站点或特定页面的剩余CSS。

提交答案