在小飞的博客上看到他写了一篇关于reset.css的文章，文章中关于css的部分分析的非常不错，但对于文中关于强调把CSS分别配置，对每一个项目都放置一个reset.css这一类观点，我有不同的看法。
诚然，将reset的东西只写进reset.css里，将layer的东西只写进layer.css里，将represent的东西只写进represent.css在思想是没有错的，但是他并没有考虑到一点，那就是成本。
yahoo搞了一个YUI，可是你在Yahoo的主页上能看到YUI的
吗？没有，访问一下google，看看他所有的页面里面有reset这样的东西吗？没有。为什么？成本。
Eric作为个人，可以搞reset.css，YUI作为推动，可以搞reset.css，但是一个网站的架构，是否都应该一股脑的用reset.css？这是根据公司的实际情况来做看的。
让我们以Yahoo为例，我们假定当前我们访问的服务器最大支持2500次并发/秒（不考虑squid，memcache这些东西），当用户访问首页的时候，一共多少个并发？
就目前的情况，一共是26次请求，耗时2.56秒。记做A。
ok，假设yahoo增加了一个reset.css，请求数增加到27次，耗时2.57秒。记做B。
A每秒请求服务器 26 / 2.56 = 10.15 次/秒
B每秒请求服务器 27 / 2.57 = 10.50 次/秒
在A的情况下，1万元的服务器每秒最大支持 2500/10.15 = 246.30 人；
在B的情况下，1万元的服务器每秒最大支持 2500/10.50 = 238.09 人；
换句话说，B运营成本相对于A增加了 （246.30-238.09）/ 246.30 × 10000 = 333.32 元。
仅仅是增加了这样一个文件，我就要多支出333.33元，这样划算吗？
如果按照文中的想法，还要将其他的样式都分门别类的独立出去，那么成本的增长将会是多么可怕的“弧度”
所以“每每有新项目，第一步就是应当使用一个reset.css来重置样式。”，“建议把.clearfix放入layout.css,而把h1、h2之类的定义放进typography.css”还是应该有所选择的去做。
Shawphy
三月 8th, 2009 @ 01:37
观点很不错，作为增加http请求来说确实不合理，所以作为一个兼顾前台设计以及服务器开销的方案，就是一份是作为开发版，每次发布时再生成一份合并且压缩过的公用的css（不同的页面再各自一个，一共2个）；同时，也有建议通过程序读取，输出合并后的css的方案。单纯的读取再输出的系统开销是很小的。如果要进一步减少http请求，甚至可以把css和js都合并输出到页面文件上。但随之而来的的就是这些文件不能缓存了，所以全合并到页面的方案并不多见。之间的平衡点可以根据测试得到。前台也有通过合并图片等方式减少http请求的情况。总之只要前台后台通力合作优化页面，才能把成本控制到最低。
回复
神飞
三月 8th, 2009 @ 02:50
从开发的角度来说，使用CSS Reset是没有错误的，而且也是必须的，这是实现浏览器兼容性的基础。
但是单纯从网站部署来说，其实目前各大网站更喜欢用的方法是文件压缩，也就是把多个CSS文件（JS也可以这样做）压缩至单个文件中，这样就不用考虑请求的问题。
YUI也专门开发了一个压缩工具，YUI Compressor，可以使用这个工具将相关的CSS和JS文件压缩一下，压缩后，网站的性能会有非常大的提高。
当然这样可能会增加一些网站的开发和维护成本，但是从网站性能上来说，是个非常不错的选择。
回复
盛传
三月 8th, 2009 @ 07:53
我一直使用着轻兼容的原则。因为并发请求的消耗非常大，而对于较大型的实用型网站，我认为在在各种用户环境下，网站界面上只要不出较大的问题，这个CSS就是成功的。
回复
张经纬
三月 8th, 2009 @ 11:49
@Shawphy
谢谢，已经在你的博客回复了。
@神飞
通过YUI可以在服务器端直接压缩。结合squid和memcache可以达到较为理想的状态。
不过过多的link是否对客户端的样式渲染有影响呢？刚才想到的。
@盛传
俺和你的观点一致。
回复
不敢苟同
三月 24th, 2009 @ 23:49
=..= 不敢苟同…
只接用
引入 YUI 的不就好了??
回复
Noker
八月 2nd, 2009 @ 00:28
不同阶段，不同的情况，不同方式，辩证唯物主义～～～
回复
Evance
十二月 30th, 2009 @ 10:54
说实话,这篇文章大量的数据都是基于”未合并不压缩”的情况下.
在网站实际部署中,只要做到”合并压缩”的前提.
提出的异议完全被打破.
而且在21世纪,以带宽作为运算成本计算主要开销,其实已经是一种滞后的观点.
这篇文章立足在:
“小型投入,没有成熟部署(CDN,缓存系统,压缩合并机制)”的条件下.
不是很合理
回复
张经纬 reply on 十二月 31st, 2009 11:00:
首先感谢指点。
我个人的看法是，CDN,服务端的压缩时需要成本去做的，具我所知帝联的CDN价格就不是中小网站可以承受的，而有能力做CDN的，例如新浪、网易等门户也是有选择使用。
带宽一直是运营成本的巨大开销，以前土豆，youku在带宽上的成本投入占总投入的50%以上，这个是有数据可查的，而即便我现在所在的公司，带宽投入成本也按7位数去计算。不过也有带宽成本很少的，例如谷歌，这与机制不同。
这篇文章还是立足于国内，可能有些观点较为保守，我也赞成你的合并压缩观点。
不过需要指出的是合并压缩并不是一个简单的东西，它涉及到3方面，合并，压缩，版本管理。
合并没有什么好说的。
压缩如果自己去做的话，比较复杂，现在压缩JS的组件很多，packer,jsMin,Esc,JSA,yui-compressor这些都行，但要有一个ANT去在服务端处理。
而管理就需要使用包管理，否者在CDN中必然会引起缓存的问题，如果每次都手工更新缓存，那就能把人累死：）
再说下去太多了，就说到这里吧。
回复