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

Posted

技术标签:

【中文标题】单个巨大的 .css 文件与多个较小的特定 .css 文件？ [关闭]【英文标题】：Single huge .css file vs. multiple smaller specific .css files? [closed] 【发布时间】：2011-01-21 03:12:28 【问题描述】：

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

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

我觉得这样更好

    positions.css buttons.css tables.css copy.css

对比

    site.css

您是否看到过一种方法与另一种方法的任何问题？

【问题讨论】：

这是一个非常古老的问题，但面对同样的问题，我找到了我认为是the best solution 的问题，以防其他人访问此页面。使用 php 压缩并通过单个请求发送的多个文件。 @FrankPresenciaFandos 这样做对于低流量站点来说是可以的，但是在高流量站点上一遍又一遍地运行这个脚本似乎有点不对劲。如果您使用构建脚本，则可以两全其美，并且仍然维护高性能的 Web 服务器，因为它不运行 php 脚本（永远）。 它只会在每次更改 css 时运行，然后您必须包含生成的 css 文件。 【参考方案1】：

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

这适用于所有版本的 IE。

请参阅 Ross Bruniges Blog 和 MSDN AddRule page。

【讨论】：

【参考方案2】：

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

然而，截至 2018 年 3 月，超过 80% 的浏览器现在支持 HTTP2，它允许浏览器同时下载多个资源以及能够抢先推送资源。为所有页面使用一个 CSS 文件意味着文件大小超出了必要的大小。如果设计得当，除了更容易编码之外，我认为这样做没有任何优势。

实现最佳性能的 HTTP2 的理想设计是：

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

【讨论】：

这应该是公认的现代答案 RE 性能。其他一些回复已过期。 如果您正在构建一个 SPA（单页应用程序），那么我认为最好的设计是将您的所有 css 和 js 构建成两个完整的文件。 "app.js" 和 "vendor.js" 所有的 html 和样式都被编译为 vendor.js 中的内联 JS 这意味着 "bootstrap.css 和 bootstrap.js" 都在 vendor.js 中，并且通过 sourcemaps 将其最小化为 "供应商.min.js”。与应用程序相同，除了现在您使用 html 到 js 内联转译器，因此即使您的应用程序 html 也在 js 文件中。您可以将它们托管在 CDN 上，浏览器会缓存它们。您甚至可以将图像编译为样式并编译为 JS。【参考方案3】：

你想要两个世界。

你需要多个 CSS 文件，因为你的理智是一件很糟糕的事情。

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

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

一个例子是这样的

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

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

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

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

【讨论】：

但是，运行时压缩/缩小具有系统开销。你必须权衡利弊。如果您的网站流量很大，这不是最佳解决方案。 @ChaseFlorell - 你只需进行一次压缩/缩小并缓存它 @Siler，我知道，这就是我发布答案的原因。 ***.com/a/2336332/124069【参考方案4】：

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

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

【讨论】：

【参考方案5】：

像 Sass 或 LESS 这样的 CSS 编译器是不错的选择。这样，您将能够为网站提供一个最小化的 CSS 文件（这将比普通的单个 CSS 源文件更小、更快），同时保持最好的开发环境，所有内容都整齐地分成组件。

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

http://lesscss.org

http://sass-lang.com

如果你不想乱用 Ruby，这个适用于 Mac 的 LESS 编译器很棒：

http://incident57.com/less/

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

http://incident57.com/codekit/

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

http://winless.org/

【讨论】：

在这里更改我接受的答案，因为这确实是这些天要走的路。当我最初问我时，我觉得 Sass 或 LESS 还没有真正起飞。【参考方案6】：

SASS 和 LESS 使这一切成为一个真正的争论点。开发人员可以设置有效的组件文件并在编译时将它们组合起来。在 SASS 中，您可以在开发时关闭压缩模式以便于阅读，然后将其重新打开以进行生产。

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

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

【讨论】：

【参考方案7】：

有一个临界点，拥有多个 css 文件是有益的。

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

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

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

【讨论】：

是的。这是我来这里的问题。每个人都专注于开发与生产。当然，您的开发环境可能与您的实时站点不同，但哪个更适合实时站点？似乎没有人真正解决这个问题。你知道找到引爆点在哪里的任何资源吗？【参考方案8】：

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

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

我的意见是两件事之一。

1) 如果您知道您的 CSS 在构建后永远不会改变，我会在开发阶段构建多个 CSS 文件（为了便于阅读），然后在上线之前手动组合它们（以减少 http 请求)

2) 如果您知道您将不时更改您的 CSS，并且需要保持它的可读性，我会构建单独的文件并使用代码（假设您使用某种编程语言）来在 runtime 构建时组合它们（运行时缩小/组合是一个资源猪）。

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

编辑：我发现了这个blog，它展示了如何在运行时仅使用代码来组合 CSS。值得一看（虽然我自己还没有测试过）。

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

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

【讨论】：

除了更少的HTTP请求之外，单个整体文件有什么优势吗？我的 css 可能会随着时间而改变，但用户数量会非常少，大多数通过高速连接访问。所以我觉得多文件的好处会远大于http请求少... HTTP 请求减少是原因。留住访问者是第一要务，因此如果您的页面加载缓慢，他们就不太可能留下来。如果您有能力结合（我看到您使用的是 asp.net），那么我强烈建议您这样做。这是两全其美。 “所以我觉得多文件的好处会远大于http请求少的多……”不不不……正好相反。对于高速连接，处理 HTTP 请求所花费的时间是瓶颈。大多数浏览器默认一次只下载两个文件，所以浏览器会做 2 个请求，等待，快速下载 css 文件，再发送 2 个请求，等待，快速下载文件。与对一个 css 文件的一个 HTTP 请求相反，它可以快速下载。与服务器的通信将是缓慢的部分。 您可以使用单独的样式表构建和测试功能，并将它们组合成一个 mongo 一个构建时间。这样，您就不会维护一个 mongo 文件，而是维护许多较小的文件。我们这样做的同时还压缩了所有让人类易于阅读但对您的网页毫无意义的空白和 cmets。 现在应该更新这个答案，因为 http2 减少了更少请求的优势。【参考方案9】：

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

【讨论】：

你知道段落的用途吗？ 这是“UI 框架”，就像 Bootstrap 或其他人一样，一旦你知道了你可以使用的词典，这完全取决于学习曲线和对所用术语的接受度。尽管如此，我仍然可以想到一些非常具体的例子，您的示例将难以满足设计师的要求。【参考方案10】：

这是最好的方法：

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

通过这种方式，您只有一个包含所有共享代码的 css 和一个 html 页面。 顺便说一下（我知道这不是正确的话题）你也可以用 base64 编码你的图像（但你也可以用你的 js 和 css 文件来做）。通过这种方式，您可以将更多的 http 请求减少到 1 个。

【讨论】：

【参考方案11】：

不妨看看compass，这是一个开源的 CSS 创作框架。 它基于Sass，所以它支持很酷的东西，比如变量、嵌套、混合和导入。如果您想保留单独的较小 CSS 文件但将它们自动合并为 1（避免多个慢速 HTTP 调用），导入尤其有用。 Compass 添加了一大组预定义的 mixin，它们很容易处理跨浏览器的东西。 它是用 Ruby 编写的，但它可以轻松地与任何系统一起使用......

【讨论】：

【参考方案12】：

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

【讨论】：

【参考方案13】：

我通常有几个 CSS 文件：

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

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

【讨论】：

这就是我所做的，对我来说效果很好。每个页面最多得到 3 个 css 文件，这是相当合理的【参考方案14】：

我更喜欢在开发过程中使用多个 CSS 文件。这样管理和调试就容易多了。但是，我建议您在部署时改用 YUI Compressor 之类的 CSS 缩小工具，它将您的 CSS 文件合并到一个整体文件中。

【讨论】：

@Randy Simon - 但是如果我们总是直接在 ftp 上编辑 css 会怎样。 我不知道你的设置，但这对我来说似乎不是一个好主意。您应该在推出更改之前对其进行测试。 @RandySimon YUI Compressor 链接已损坏。【参考方案15】：

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

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

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


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

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

等

【讨论】：

这并没有使它更容易维护，因为我仍然需要滚动数英里的不相关 css 才能找到我想要的东西...... @Nate：您是否考虑过切换到具有不错搜索功能的文本编辑器？我个人的偏好是单个 css 文件，我从不滚动浏览它。我只需输入“/classname”（我使用 vi 派生词）和 bam - 我在那个班级。 在多开发人员环境中也更难维护。上面示例中的“标题”是什么？如果其他人不是从地理角度思考，而是在基本设计元素（如按钮或菜单）方面思考，而其他人的思考方式不同怎么办？如果菜单在标题中，它会去哪里？如果不是怎么办？我认为在单独的文件中执行这种纪律更容易。为什么应用程序开发人员不只是创建一个包含所有修饰的巨大应用程序类，而不是一个具有类层次结构的框架？好像和我一样。 如果您不记得要查找的课程名称怎么办？或者您如何决定在哪里添加新课程？ 如果它只是几个页面的网站，那真的没什么大不了的。只是建议另一种做事方式。【参考方案16】：

单个 CSS 文件的优势在于传输效率。每个 HTTP 请求都意味着对每个请求的文件都有一个 HTTP 标头响应，这会占用带宽。

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

【讨论】：

因此，如果我使用 ASP.NET，.ASHX 通用处理程序将是理想的选择，它将它们组合到一个文件中以获得两全其美？ 是的，我会在运行时使用 IHttpHandler 来组合您的 CSS（请参阅上面我的答案中的 #2） @Nate：当我在 ASP.Net 中工作时，我们使用模板文件来完成同样的事情。 @Robusto，你能解释一下什么是模板文件吗？我想我从来没有听说过。我使用过 App_Themes，但它仍然没有结合 CSS。 只是作为更新。在服务器端使用 IHttpHandler 或 PHP 文件组合 css 可以节省带宽并加快请求速度，但也会增加服务器上不必要的负载。最好的方法是在站点的构建/发布期间合并/缩小您的 css/js。这样，您就有了一个不需要任何服务器处理的静态文件。世界上最好的，没有吧。【参考方案17】：

只有一个 CSS 文件可以更好地缩短页面的加载时间，因为这意味着更少的 HTTP 请求。

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

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

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

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

还有一些软件会在运行时而不是在构建时组合 CSS 文件；但是在运行时这样做意味着消耗更多的 CPU （并且显然需要一些缓存机制，以不经常重新生成大文件）

【讨论】：

我认为这个很好的答案将受益于至少提到可能的 css 技术来解决冲突。例如。如果您有模块化 CSS 并且两个类具有相同的名称，那么以后的类或更具体的类都会胜出，从而导致生产中出现意外结果。【参考方案18】：

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

【讨论】：

问题在于，从开发人员的角度来看，这是相当自私的。完成后，您很少需要返回，但您的访问者都必须等待页面加载不必要的 css 文件。 （我认为 Javascript 也是如此） @rockin：在清除缓存后检查我的一个 5-CSS 文件站点时，我发现加载所有 CSS 所需的总时间不到 10 分之一秒。如果人们不能等那么久，我认为他们需要更多的利他林之类的。更大的问题是对双击等广告网站的回调，这可能导致巨大的延迟，正如过去一周在这个网站上所看到的那样。 一个用来测试网站速度的好工具是 Firebug 和 YSlow。这应该可以准确地展示您网站的速度。

以上是关于单个巨大的 .css 文件与多个较小的特定 .css 文件？ [关闭]的主要内容，如果未能解决你的问题，请参考以下文章

索引巨大的文本文件

使用 PHP 将大型 KML 文件拆分为较小的文件

使用 java 中的 OLE 自动化将 word 文件拆分为多个较小的 word 文件

如何隐藏一个在页面上多个位置使用的类，*仅来自特定元素*，使用 css 媒体查询

将一个大的 json 文件拆分为多个较小的文件

rails 4：将 routes.rb 拆分为多个较小的文件