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

像sass或更少这样的css编译器是一个很好的方法。这样,您就可以为站点提供一个单一的、最小化的CSS文件(比普通的单一CSS源文件小得多,速度也快得多),同时保持最好的开发环境,所有东西都整齐地拆分成组件。

sass和less具有变量、嵌套和其他方法的附加优势,使css更易于编写和维护。高度推荐。我个人现在使用sass(scss语法),但以前很少使用。两者都很好,有相似的好处。一旦你用编译器编写了CSS,你就不可能不使用它了。

http://lesscss.org

http://sass-lang.com

如果你不想和Ruby混在一起,那么这款针对Mac的编译器就太棒了:

http://incident57.com/less/

或者你可以使用codekit(由同一个人使用):

http://incident57.com/codekit/

Winless是一个Windows图形用户界面,用于减少

http://winless.org/

这是一个很难回答的问题。在我看来,这两种选择都有其利弊。

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

我的意见是两件事之一。

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

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

对于这两个选项,我强烈建议在客户端缓存,以便进一步减少HTTP请求。

编辑:
我发现了这个 blog 这说明了如何在运行时使用代码以外的任何东西组合CSS。值得一看(虽然我自己还没有测试过)。

编辑2:
我已经决定在设计时使用单独的文件,以及缩小和合并的构建过程。这样,我可以在开发时使用单独的(可管理的)CSS,并在运行时使用适当的单片小型文件。我仍然有我的静态文件和更少的系统开销,因为我没有在运行时进行压缩/缩小。

注意:对于您在那里购物的顾客,我强烈建议您使用 bundler 作为构建过程的一部分。无论您是从您的IDE中构建,还是从构建脚本构建,bundler都可以通过包含的 exe 或者可以在已经运行node.js的任何计算机上运行。

我喜欢在开发期间使用多个CSS文件。这样管理和调试就容易得多。但是,我建议在部署时使用类似CSS的小型工具 YUI Compressor 它将把你的CSS文件合并成一个整体文件。

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

拥有几个小的CSS文件意味着开发更容易 (至少,我认为是这样的:在应用程序的每个模块中有一个CSS文件会使事情变得更简单) .

所以,这两种情况都有充分的理由…

一个能让你充分利用这两种想法的解决方案是:

• 使用几个小的CSS文件进行开发
  • 即更容易开发
• 要为应用程序建立一个构建过程,需要将这些文件“组合”成一个
  • 这个构建过程也可以缩小那个大文件,btw
  • 很明显,这意味着应用程序必须有一些配置工具,允许它从“多文件模式”切换到“单文件模式”。
• 在生产中只使用大文件
  • 即更快地加载页面

还有一些软件可以在运行时(而不是在构建时)合并CSS文件;但是在运行时这样做意味着占用更多的CPU (显然需要一些缓存机制,以避免过多地重新生成大文件)

你想要两个世界。

你需要多个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 Blog 和 MSDN AddRule page .

有一个临界点,在这个临界点上有多个CSS文件是有益的。

一个拥有100万页以上页面的网站,一般用户可能只看到5页以上的页面,其样式表的比例可能非常大,因此试图通过大量的初始下载来节省每页加载一个额外请求的开销是错误的。

把论点扩展到极限——这就像建议应该为整个Web维护一个大型样式表。显然是胡说八道。

每个站点的临界点是不同的,所以没有硬性和快速的规则。它将取决于每个页面的唯一CSS数量、页面数量和平均用户在使用网站时可能经常遇到的页面数量。

我通常有一些CSS文件:

• 用于重置和全局样式的“全局”CSS文件
• “模块”特定的CSS文件,用于逻辑分组的页面(可能是签出向导中的每个页面或其他内容)
• 页面上用于覆盖的“页面”特定CSS文件(或者,将其放在单独页面的一个块中)

我不太关心CSS文件的多页请求。大多数人都有不错的带宽,我相信还有其他的优化比将所有样式组合成一个单一的CSS文件有更大的影响。在速度和可维护性之间进行权衡,我总是倾向于可维护性。不过,YUI的竞争对手听起来很酷,我可能得看看。

也许看看 compass 这是一个开源的CSS创作框架。 它是基于 Sass 所以它支持一些很酷的东西,比如变量、嵌套、混合和导入。如果您想保留单独的较小的CSS文件,但将它们自动合并为1(避免多次缓慢的HTTP调用),则导入尤其有用。 Compass还增加了一大组预先定义的混音器,这些混音器很容易处理跨浏览器的东西。 它是用Ruby编写的,但它可以很容易地用于任何系统….

我喜欢多个CSS文件。这样就可以更容易地根据您的需要交换“皮肤”。一个单片文件的问题是它可能失控并且难以管理。如果你想要蓝色背景但不想改变按钮怎么办?只需更改背景文件。等。

从历史上看,x拥有单个css文件的主要优势之一是使用http1.1时的速度优势。

然而,截至2018年3月,超过80%的浏览器现在支持HTTP2。HTTP2允许浏览器同时下载多个资源,并能够先发制人地推送资源。所有页面都有一个CSS文件意味着文件大小大于所需大小。有了适当的设计,我认为这样做除了更容易编写代码外没有任何好处。

HTTP2最佳性能的理想设计是: -有一个核心的CSS文件,其中包含所有页面上使用的通用样式。 -将特定于页面的CSS放在单独的文件中 -使用http2 push css将等待时间最小化(cookie可用于防止重复推送) -可以选择在折叠CSS上方分离,然后先推这个,然后再加载剩余的CSS(对于低带宽移动设备很有用) -如果您想加速将来的页面加载,也可以在页面加载后为该站点或特定页面加载剩余的CSS。

最好的方法是:

1. 创建一个包含所有共享代码的常规CSS文件
2. 将所有特定页的CSS代码插入同一页、标记上或对每个页使用属性style=“”。

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

沙斯和更少使这一切真的是一个无意义的点。开发人员可以设置有效的组件文件,并在编译时将它们组合在一起。在SASS中,您可以在开发过程中关闭压缩模式,以便于阅读,并在生产中重新打开压缩模式。

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

最后,不管使用哪种技术,一个小型化的CSS文件都是您想要的。更少的CSS,更少的HTTP请求,更少的服务器需求。

单个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 *********/

等

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

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

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

见: 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">