Firebug中的性能事实与YSlow相矛盾

Question

我有一个简单的基于ASP.Net MVC3的网络应用程序。我最近一直在做一些性能调整。我在Mozilla中使用Firebug来检查资源负载大小和时间。后来，我使用YSlow来推导出一些可能的优化。

我想将重点缩小到'捆绑＆amp; amp;的一般优化概念。缩小'我们缩小 js＆amp; css和捆绑合并为一个组合的js＆amp; CSS。根据YSlow，它可以节省额外的服务器请求以及一些带宽/时间。但是，在我的情况下，它是矛盾的！我正在使用SquishIt lib。

这是我的统计数据（请查看附图）

Old Login page: Requests(10), Size(434), Load Time in seconds(29), YSlow grade C(78)
New Login page: Requests(6), Size(414), Load Time in seconds(42), YSlow grade B(88)

旧原始页面 - 这是新的优化页面 -

  

理想情况下它必须颠倒！但它看起来像是组合的js文件   占用更多时间。我放慢了带宽以获得更多   准确的差异，我已经在非缓存测试它（也做过   Ctrl + F5）确保两个页面都获得公平的机会。他们在   具有相同设置的相同服务。

注意： 请忽略图片中的最后一次图片重新加载 - 我刷了一下。我在登录页面上预加载了一些额外的jQuery lib，以便后续页面获得缓存资源。你可以忽略这些事情，但请告诉我这是否可能或我是否犯了错误？

关于捆绑销售的另一个问题缩小 - 我认为如果我使用CDN引用作为我的资源（不能捆绑tehy），它就不适用。在那种情况下，什么是首选 - CDN引用或捆绑？

Answer 1

总体而言，我认为您走在正确的轨道上：请求数量减少+总请求数量减少=大多数用户的效果更佳。

在您的测试结果中，我认为您会看到以下几点：

1. 使用较大的组合文件的一个缺点是您失去了并行下载的一些好处。我不认为这是你的主要贡献者，但你可以在原始案例中看到许多jquery JS文件是并行下载的。
2. 总页面时间负载因运行而异，具体取决于网络速度和服务器负载。在您的原始情况下，jquery-ui文件为222KB，大约8 KB / s需要27.8秒。在优化页面中，新组合的JS为254KB，速度为6.2 KB / s时耗时41秒。这是非常粗略的数学，但我认为它可能会给你所看到的差异提供线索。

如果您的网站在公共互联网上可用，则可以使用WebPageTest或GTmetrix等工具从外部服务器（以及多个位置）运行一些测量。

关于CDN与捆绑的问题，最终你可以测试一些原型，看看哪种方式更适合你。一个选项会有大量不经常更改的文件，例如来自CDN的jQuery，以及托管在服务器上的所有自己的JS（捆绑）。

要记住CDN托管静态文件的一件事，当您拥有地理位置分散的用户群时，最大的好处就在于此。然后，他们可以利用全球CDN网络，从更接近他们的服务器（因此更快）提供静态文件。相反，如果您的用户群没有遍布全球，或者这是一个内部应用程序，那么使用CDN可能没什么好处。