Html 单个巨大的 .css 文件与多个较小的特定 .css 文件？

Single huge .css file vs. multiple smaller specific .css files?

提问by Nate

Is there any advantage to having a single monster .css file that contains style elements that will be used on almost every page?

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

I'm thinking that for ease of management, I'd like to pull out different types of CSS into a few files, and include every file in my main <link />is that bad?

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

I'm thinking this is better

我觉得这个更好

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

1. 职位.css
2. 按钮.css
3. 表格.css
4. 复制.css

vs.

对比

1. site.css

1. 网站.css

Have you seen any gotchas with doing it one way vs. the other?

你有没有看到以一种方式与另一种方式做的任何问题？

采纳答案by Marc Edwards

A CSS compiler like Sass or LESS is a great way to go. That way you'll be able to deliver a single, minimised CSS file for the site (which will be far smaller and faster than a normal single CSS source file), while maintaining the nicest development environment, with everything neatly split into components.

像 Sass 或 LESS 这样的 CSS 编译器是一个很好的方法。这样，您就可以为站点提供一个最小化的 CSS 文件（它比普通的单个 CSS 源文件小得多，速度也快得多），同时保持最好的开发环境，将所有内容整齐地拆分为组件。

Sass and LESS have the added advantage of variables, nesting and other ways to make CSS easier to write and maintain. Highly, highly recommended. I personally use Sass (SCSS syntax) now, but used LESS previously. Both are great, with similar benefits. Once you've written CSS with a compiler, it's unlikely you'd want to do without one.

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

http://lesscss.org

http://lesscss.org

http://sass-lang.com

http://sass-lang.com

If you don't want to mess around with Ruby, this LESS compiler for Mac is great:

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

http://incident57.com/less/

http://incident57.com/less/

Or you could use CodeKit (by the same guys):

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

http://incident57.com/codekit/

http://incident57.com/codekit/

WinLess is a Windows GUI for comipiling LESS

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

http://winless.org/

http://winless.org/

回答by Chase Florell

This is a hard one to answer. Both options have their pros and cons in my opinion.

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

I personally don't love reading through a single HUGE CSS file, and maintaining it is very difficult. On the other hand, splitting it out causes extra http requests which could potentially slow things down.

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

My opinion would be one of two things.

我的意见是两件事之一。

1) If you know that your CSS will NEVER change once you've built it, I'd build multiple CSS files in the development stage (for readability), and then manually combine them before going live (to reduce http requests)

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

2) If you know that you're going to change your CSS once in a while, and need to keep it readable, I would build separate files and use code (providing you're using some sort of programming language) to combine them at runtimebuild time (runtime minification/combination is a resource pig).

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

With either option I would highly recommend caching on the client side in order to further reduce http requests.

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

EDIT:
I found this blogthat shows how to combine CSS at runtime using nothing but code. Worth taking a look at (though I haven't tested it myself yet).

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

EDIT 2:
I've settled on using separate files in my design time, and a build process to minify and combine. This way I can have separate (manageable) css while I develop and a proper monolithic minified file at runtime. And I still have my static files and less system overhead because I'm not doing compression/minification at runtime.

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

note: for you shoppers out there, I highly suggest using bundleras part of your build process. Whether you're building from within your IDE, or from a build script, bundler can be executed on Windows via the included exeor can be run on any machine that is already running node.js.

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

回答by Randy Simon

I prefer multiple CSS files during development. Management and debugging is much easier that way. However, I suggest that come deployment time you instead use a CSS minify tool like YUI Compressorwhich will merge your CSS files into one monolithic file.

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

回答by Will Hartung

You want both worlds.

你想要两个世界。

You want multiple CSS files because your sanity is a terrible thing to waste.

你想要多个 CSS 文件，因为你的理智是一件可怕的事情。

At the same time, it's better to have a single, large file.

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

The solution is to have some mechanism that combines the multiple files in to a single file.

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

One example is something like

一个例子是这样的

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

Then, the allcss.php script handles concatenating the files and delivering them.

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

Ideally, the script would check the mod dates on all the files, creates a new composite if any of them changes, then returns that composite, and then checks against the If-Modified HTTP headers so as to not send redundant CSS.

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

This gives you the best of both worlds. Works great for JS as well.

这为您提供了两全其美的优势。也适用于 JS。

回答by Pascal MARTIN

Having only one CSS file is better for the loading-time of your pages, as it means less HTTP requests.

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

Having several little CSS files means development is easier (at least, I think so : having one CSS file per module of your application makes things easier).

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

So, there are good reasons in both cases...

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

A solution that would allow you to get the best of both ideas would be :

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

• To develop using several small CSS files
  • i.e. easier to develop
• To have a build process for your application, that "combines" those files into one
  • That build process could also minify that big file, btw
  • It obviously means that your application must have some configuration stuff that allows it to swith from "multi-files mode" to "mono-file mode".
• And to use, in production, only the big file
  • i.e. faster loading pages

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

There are also some software that do that combining of CSS files at run-time, and not at build-time ; but doing it at run-time means eating a bit more CPU (and obvisouly requires some caching mecanism, to not re-generate the big file too often)

还有一些软件可以在运行时而不是在构建时组合 CSS 文件；但是在运行时这样做意味着要多吃一点 CPU （并且显然需要一些缓存机制，不要过于频繁地重新生成大文件）

回答by DD.

Historically, one of the main advantages x in having a single CSS file is the speed benefit when using HTTP1.1.

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

However, as of March 2018 over 80% of browsers now support HTTP2which allows the browser to download multiple resources simultaneously as well as being able to push resources pre-emptively. Having a single CSS file for all pages means a larger than necessary file size. With proper design, I don't see any advantage in doing this other than its easier to code.

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

The ideal design for HTTP2 for best performance would be:

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

• Have a core CSS file which contains common styles used across all pages.
• Have page specific CSS in a separate file
• Use HTTP2 push CSS to minimise wait time (a cookie can be used to prevent repeated pushes)
• Optionally separate above the fold CSS and push this first and load the remaining CSS later (useful for low-bandwidth mobile devices)
• You could also load remaining CSS for the site or specific pages after the page has loaded if you want to speed up future page loads.

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

回答by TheClair

Monolithic stylesheets do offer a lot of benefits (which are described in the other answers), however depending on the overall size of the stylesheet document you could run into problems in IE. IE has a limitation with how many selectors it will read from a single file. The limit is 4096 selectors. If you're monolithic stylesheet will have more than this you will want to split it. This limitation only rears it's ugly head in IE.

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

This is for all versions of IE.

这适用于所有版本的 IE。

See Ross Bruniges Blogand MSDN AddRule page.

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

回答by Claud

There is a tipping point at which it's beneficial to have more than one css file.

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

A site with 1M+ pages, which the average user is likely to only ever see say 5 of, might have a stylesheet of immense proportions, so trying to save the overhead of a single additional request per page load by having a massive initial download is false economy.

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

Stretch the argument to the extreme limit - it's like suggesting that there should be one large stylesheet maintained for the entire web. Clearly nonsensical.

将论点扩展到极限 - 这就像建议应该为整个 Web 维护一个大型样式表。显然是无稽之谈。

The tipping point will be different for each site though so there's no hard and fast rule. It will depend upon the quantity of unique css per page, the number of pages, and the number of pages the average user is likely to routinely encounter while using the site.

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

回答by Nicholas Cloud

I typically have a handful of CSS files:

我通常有一些 CSS 文件：

• a "global" css file for resets and global styles
• "module" specific css files for pages that are logically grouped (maybe every page in a checkout wizard or something)
• "page" specific css files for overrides on the page (or, put this in a block on the individual page)

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

I am not really too concerned with multiple page requests for CSS files. Most people have decent bandwidth and I'm sure there are other optimizations that would have a far greater impact than combining all styles into one monolitic CSS file. The trade-off is between speed and maintainability, and I always lean towards maintainability. The YUI comperssor sounds pretty cool though, I might have to check that out.

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

回答by Robusto

I prefer multiple CSS files. That way it is easier to swap "skins" in and out as you desire. The problem with one monolithic file is that it can get out of control and hard to manage. What if you want blue backgrounds but don't want the buttons to change? Just alter your backgrounds file. Etc.

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