javascript和css解析性能

语境: 虽然HTTP开销确实比解析JS和CSS更重要,但是忽略解析对浏览器性能的影响(即使您的JS不足一兆兆),这是让您陷入麻烦的一个好方法。

yslow、fiddler和firebug不是监控解析速度的最佳工具。除非最近更新了它们,否则它们不会将通过HTTP获取JS或从缓存加载所需的时间量与解析实际JS负载所花费的时间量分开。

解析速度有点难测量,但是我们在我研究过的项目中多次关注这个指标,即使使用大约500k的JS,对页面加载的影响也非常显著。很明显,旧浏览器遭受的损失最大……希望Chrome、TraceMonkey等能够帮助解决这种情况。

建议: 根据您站点上的流量类型,将JS负载拆分开来可能非常值得,这样,一些不会在最流行的页面上使用的大块JS就不会被发送到客户端。当然,这意味着当一个新客户机访问到需要这个JS的页面时,您必须通过网络发送它。

但是,很可能是这样的,比如说,由于您的流量模式,80%的用户永远不需要50%的JS。如果是这样,那么您应该只在需要JS的页面上使用更小的、打包的JS有效负载。否则,80%的用户将遭受不必要的JS解析惩罚 每个页面加载 .

底线: 很难找到JS缓存和更小的打包有效负载之间的适当平衡,但是根据您的流量模式,考虑一种技术(而不是将所有JS粉碎到每个页面加载中)绝对值得。

我相信 YSlow 是的,但请注意,除非所有请求都通过环回连接,否则您不必担心。拆分文件的HTTP开销将影响性能 远的 不仅仅是解析,除非您的CSS/JS文件超过几兆字节。

为了增加卡门的答案,我想说在一些浏览器上,大型JS资源的解析时间呈非线性增长。也就是说,一个1兆JS文件解析两个500K文件需要更长的时间。因此,如果您的很多流量都是可能缓存JS的人(返回访问者),并且您的所有JS文件都是缓存稳定的,那么即使您最终在每个页面视图上加载了所有JS文件,也可能有必要将其拆分。