拥有一个包含几乎每个页面都要使用的样式元素的怪物.css文件有什么好处吗?
我在想,为了便于管理,我想把不同类型的CSS拉出到几个文件中,并包括我的主<link />是坏的吗?
我觉得这样更好
positions.css buttons.css tables.css copy.css
vs.
site.css
你见过用一种方法做和用另一种方法做有什么问题吗?
拥有一个包含几乎每个页面都要使用的样式元素的怪物.css文件有什么好处吗?
我在想,为了便于管理,我想把不同类型的CSS拉出到几个文件中,并包括我的主<link />是坏的吗?
我觉得这样更好
positions.css buttons.css tables.css copy.css
vs.
site.css
你见过用一种方法做和用另一种方法做有什么问题吗?
当前回答
你想要两个世界。
您需要多个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。
其他回答
我更喜欢在开发过程中使用多个CSS文件。这样管理和调试就容易得多。但是,我建议你在部署时使用像YUI Compressor这样的CSS缩小工具,它可以将你的CSS文件合并成一个整体文件。
也许可以看看compass,这是一个开源的CSS创作框架。 它基于Sass,所以它支持一些很酷的东西,比如变量、嵌套、mixin和导入。如果您想要保持独立的较小CSS文件,但将它们自动合并为一个(避免多次缓慢的HTTP调用),则导入非常有用。 Compass在此基础上增加了一组预定义的mixin,便于处理跨浏览器的东西。 它是用Ruby编写的,但是它可以很容易地用于任何系统....
存在一个临界点,在这个临界点上使用多个css文件是有益的。
一个拥有100万以上页面的网站,平均用户可能只看到其中的5个,可能有一个巨大的样式表,所以试图通过大量的初始下载来节省每次页面加载的单个额外请求的开销是虚假的经济。
把这个论点延伸到极致——这就像是建议整个网络应该维护一个大的样式表。显然是荒谬的。
每个网站的临界点都不一样,所以没有硬性规定。这将取决于每个页面的唯一css数量、页面数量以及普通用户在使用网站时可能经常遇到的页面数量。
对于页面的加载时间来说,只有一个CSS文件更好,因为这意味着更少的HTTP请求。
拥有几个小的CSS文件意味着开发更容易(至少,我是这么认为的:应用程序的每个模块拥有一个CSS文件会让事情变得更容易)。
所以,这两种情况都有很好的理由……
一个可以让你得到两个想法的最好的解决方案是:
使用几个小的CSS文件进行开发 也就是更容易发展 要为您的应用程序建立一个构建过程,将这些文件“组合”成一个文件 顺便说一句,这个构建过程也可以缩小那个大文件 这显然意味着你的应用程序必须有一些配置,允许它从“多文件模式”切换到“单文件模式”。 而要在生产中使用,只有大文件 即更快的加载页面
也有一些软件可以在运行时组合CSS文件,而不是在构建时;但是在运行时这样做意味着消耗更多的CPU(并且显然需要一些缓存机制,以避免太频繁地重新生成大文件)
捆绑的样式表可以节省页面加载性能,但是样式越多,浏览器在页面上呈现动画的速度就越慢。这是由于大量未使用的样式可能不在您所在的页面上,但浏览器仍然需要计算。
参见: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">