使用 Visual Round Trip Analyzer 加快网页加载速度的 12 个步骤
Jim Pierson
本文基于 VRTA 的预发布版本。文中的所有信息均有可能发生变更。
本文将介绍以下内容：
| 本文使用了以下技术： Visual Round Trip Analyzer |
目录
有诸多因素可能会影响网页的性能—服务器与客户端之间的距离、页面上元素的数量、浏览器加载这些元素的方式和可用带宽。找出这些瓶颈并指出其中的作梗者并非易事。但如果真能查明原因，则会产生很大的改进。
在本文中，我为您介绍如何发现造成性能不佳的原因并加以补救。我还将为您介绍 Visual Round Trip Analyzer (VRTA)，这款工具能从众多因素中区分出导致性能问题的根源，并将其显示为图形。然后教您使用 VRTA 执行分析。首先我们来做一个本文中的快速测试，名为“您如何改进页面加载？”，通过它了解您已经掌握的情况。
位置、位置、位置
页面加载延迟的两个影响最大因素是距离（表现为往返时间 RTT）和客户端与服务器之间的往返数量。往返是指客户端向服务器发出网络数据包，服务器随后发回响应数据包。如果页面内容不多，下载一个网页可能只需要 2 或 3 个往返；如果页面包含相当多的内容，可能需要数十个往返。打开 TCP 连接是一个往返。发送 Get 并接收第一个 3KB 是一个往返。为更多数据发送确认需要多个往返。
对于与网站数据中心相距不远的用户，即在几百英里之内，例如洛杉矶的用户连接硅谷的服务器，RTT 仅是 20 毫秒（.020 秒），在页面加载时间中所占比例不大。在这种情况下，客户端和服务器之间可能有 50 个往返，不算任何服务器时间，这仍只有 1 秒的网络延迟（50 RT × 20 毫秒 = 1 秒）。
但对于欧洲和亚洲的用户，连接同一台硅谷服务器时，情况就截然不同了。目前从加洲到日本和英格兰一次往返的最低时间是 120 毫秒。考虑到每次请求的服务器磁盘搜寻时间不到 10 毫秒，而往返要花费数百毫秒并且多次重复，您就会发现如果页面加载时间长，距离和往返数量在其中占有相当大的比例。
要消除这种耗时往返的影响，您可以试用三种主要的解决方案：通过更多地采用并行方式并去除冗余，可以减少串行往返的数量；通过更为靠近用户减少往返时间，或减少服务器时间。
准确表达出页面下载的情况，就象它真正流动一样，这是性能分析的关键。例如，通常很难知晓页面的哪些内容是串行下载的，哪些是并行下载的。文件下载通常表示为瀑布（如
图 1 中所示），一个文件代表报告中的一行。但这种表示没有考虑到自 HTTP1.1 起，TCP 连接已反复使用。保持连接状态并通过现有连接调用其他文件会减少往返数量，但在传统的瀑布图示中却很难看到。要用图片更准确地表示页面的真实加载情况，您需要将 TCP 端口添加为图形的维度。
图 1
HTTP1.0 瀑布图
图 2 显示了在七个 TCP 端口加载的文件，由灰色的水平线和耗用的毫秒数表示。彩条是文件，红色的是 HTML 文本，金色代表样式表，棕褐色代表 JavaScript，蓝色线则代表图像。一个端口先打开，随后又打开了另外两个端口。第一个文件 (CSS) 加载后，在同一端口加载了更多文件（JavaScript 和图像）。
图 2
HTTP1.1 Keep-Alives
VRTA 以 Microsoft Network Monitor（称为 NetMon）3.2 数据包分析程序为基础，虽然您不必了解如何使用 NetMon，但应清楚这一点。此工具的最新版本现已公开发布，整体性能小组向其中加入了文件和数据包的可视细节。
图 3 显示了这些细节。建立 TCP 连接后，粉色的阴影线显示来自服务器的 TCP 响应数据包。灰线是从服务器到第一字节的时间，阶梯代表响应数据包使用 TCP 慢启动形成阶梯。
图 3
文件和数据包的细节
12 个简单步骤
我们通常假设网页始终以全速下载，更多的字节只会让网页减速。而实际情况是，除非用户离数据中心很近，否则浏览器绝少能利用所有可用带宽。您可以使用 12 个不同的步骤缓解这一问题。
1. 打开足够的端口浏览器和应用程序都可以限制并行打开的端口数。Internet Explorer 7.0 及更早的版本将 HTTP1.1 端口数限定为每个域 2 个。因此，像 msn.com 只能有两个端口。如果您在一个域中托管所有的静态 JavaScript、CSS 和图像，如图 4 所示，旧的浏览器仍将只打开两个端口。将内容散布到多个域中允许浏览器打开更多端口。或者可以通过修改浏览器打开更多端口。Internet Explorer 团队目前正在考虑这一修改。
下载单个文件时，页面通常会产生瓶颈，在逐个下载一系列单个文件时，情况甚至更糟。理想情况是一个页面并行加载 6 到 8 个文件。请看一下
图 4 中的比特速率图。您可以看到在前三秒流量极小。在
图 5 中，图表左上角的橙色文件是 SSL 握手。矩形内部是数据包流动的趋势，稍后我将更详细地对其加以讨论。如果您从左到右扫视图片并计算一次同时活动下载的文件数，您将发现直到三秒后才有文件同时下载。首先加载 SSL，随后是串行加载两个红色的 HTML 文件，最后使用 6 个端口加载 9 个文件。
图 4
端口过少而小文件过多
图 5
并发端口
2. 限制下载的小文件数量在广域网 (WAN) 中传送许多小文件时，很难做到充分利用所有带宽。图 4 显示在整个页面下载过程中均存在这种情况，但在第 10 秒之后尤其明显。每个图标图像文件都不到 500 字节。如果用户到服务器的 RTT 是 200 毫秒，每个文件需要一个往返，则每秒只能加载 5 个这样的文件（5 个文件/秒 × 500 字节/每个文件 × 8 比特/字节 = 20Kbps/TCP 端口）。
如果将小文件合并为大文件，则每个往返能传送更多的字节。对于图像，这称为图像群集或使用精灵。将图像并行排列，加以修整后放在页面上，然后下载一个文件。以下是这一概念的实际运作示例：在发布 Windows 2000 时，我们接到报告，说从雷蒙德向德国下载升级需要 6 个小时。我通过分析发现有 30,000 个非常小的文件在排队下载。将它们压缩成一个文件后，只用 35 分钟就完成了下载。
3. 在 JavaScript 引擎之外加载 JavaScript 文件运行 Internet Explorer 7 或更早版本的浏览器在遇到 JavaScript 文件时会产生阻碍。通常，它们在以所谓的推测模式下载时速度足够快。但如果遇到 JavaScript，浏览器会跳出此模式，专门下载 JavaScript。如果您在 VRTA 中看到这种情形，您将发现 JavaScript files 文件之间不会出现并行，也绝少会同时加载其他类型的文件。
一种解决办法是将 JavaScript 文件移到最后，但这会错过带宽的最佳使用时机。更好的解决方案是使用文件的 document.write，在浏览器中于 JavaScript 引擎之外加载这些文件，如下所示：
function AsyncLoad()
{
var l = arguments.length;
for (var i=0;i<l;i++)
{
document.write("<script src='" + arguments[i] + "'></" + "script>");
}
}
AsyncLoad(
"file1.js",
"file2.js",
"file3.js");
我们预期 Internet Explorer 8.0 将最终解决这一问题。
4. 开启 Keep-Alives 打开一个 TCP 端口要用到一个往返，而获取文件至少要用到一个往返。如果连接对其他文件也保持打开状态，就能减少往返数量并增加有效吞吐量。注意，在
图 6 中每个 TCP 连接只有一个端口（灰色水平线）。只有大型文件才出现比特速率跃升。在每个文件矩形的内部您还会看到因响应量增加而产生的阶梯模式。
图 6
Keep-Alives
这是 TCP 慢启动算法的提升效应，随着成功往返的增多发出送更多字节。也是大文件传送速度加快的原因。如果能反复利用 TCP 连接，后续文件就能持续扩大窗口尺寸，而不并再从头开始。IIS 默认开启 Keep-Alive，除非您只托管一个文件，否则应始终将其打开。
5. 指出网络拥塞区分出服务器与网络延迟十分重要。查看 TCP 连接时间或查找重发通常会发现网络延迟。在
图 7 的第四列中，您可以数据包之间的传送时间（以毫秒计）。TCP 的开启连接请求是客户端发出的第一个数据包（
图 7 中的帧 67）2914 毫秒（2.9 秒）后客户端重新发送请求（图中的帧 306），因为它没有从服务器收到响应。发出第二个请求后，服务器在 110 毫秒后给出了响应（帧 307）。
图 7
数据包之间的传送时间
一个有趣的现象是 TCP 连接数据包的重传按指数级回退，而连接中的数据包则快速重传。因此，失败的连接通常需要 2 或 3 秒才能有第一次重传，而数据包仅有几百毫秒的超时。
6. 提高网络最大传输单元 (MTU) 或 TCP 窗口尺寸在以太网中，数据包的尺寸可以大到 1,514 字节。有时，服务器可能会将 MTU（数据包的尺寸）限制为更小的尺寸。如果您发现大文件的响应数据包远小于 1,500 字节，则应检查这一设置。
TCP 窗口尺寸是另一个相关因素。通常是 16 或 32KB，具体视操作系统而定。这意味着 TCP 在必须等待确认前可以增大它发送的字节数。您可以将其视为每个往返的字节数，尽管这有些过于简化。TCP/HTTP 一开始通常是在第一个响应中发送包含两个数据包的窗口，大约 3KB 的数据。 在发送下一个窗口前，服务器会等待确认。 随着收到每个成功的确认，窗口尺寸会逐步加大。这样 TCP 就能判断两个设备之间有多大的可用带宽。
查找来自服务器且一直小于 16KB 的窗口，然后将其改回默认值。要掌握窗口尺寸，开启 NetMon 并查看服务器响应数据包的“窗口”尺寸。
7. 找出服务器拥塞慢服务器通常表现出快速 TCP 连接、在 TCP 层级快速确认，但到第一字节的数据响应包很慢。试想一下，服务器在各个层级运行（就象开放系统互联或 OSI 模型中一样），彼此独立工作。TCP 层在内核级或 NIC 卡中运行。它的速度非常快。请求数据包到达后，它将数据向上转发到 HTTP 层，该层可能需要寻找磁盘。TCP 层必须在收到 HTTP 层的响应后才能发出确认（请参见
图 8）。
图 8
慢服务器
8. 检查不必要的往返在下载页面时，不是所有的内容都是必须的。有些操作之所以发生，有些决定之所以做出只是因为浏览器没有得到足够的指令，比如缓存文件需要的时间。
9. 设置到期日期缓存 JavaScript、CSS、图像和 XML 这类静态文件是为方便用户下次加载页面。浏览器将在 HTTP 标头中查找到期日期，以了解文件是否仍旧完好无损。遗憾的是，许多站点并不设置这些日期。因此，浏览器从缓存中取出文件后，从中找不到日期，就会向服务器发送一个 Get-if-Modified。大多数情况下，服务器的响应为 304 Not-Modified，从而依旧使用缓存中的文件。
好的站点将会把其日期设成三年。更改文件名称或路径、添加参数字符串，这些都会让浏览器重新加载文件。想象一下，有多少新服务器和带宽用在了处理文件的 Get 请求上，而用户已经拥有了这些文件。
到期日期的另一益处是它们对实体标记 (Etags) 的影响。Etags 有可能导致性能问题。它们专门用于使用服务器生成的数字为每个文件给出唯一的标记。在服务器群集中，每个服务器都会创建不同的数字。例如，假设浏览器针对它在缓存中找到的文件发送了一个 Get-If-Modified。如果只有一个服务器，则很可能匹配到文件并发回一个 304 Not-Modified 错误。但是，如果用户访问的是一个大型的服务器场，则很可能到达另一个使用不同实体标记的服务器，造成该服务器向浏览器重新加载整个文件。
使用 VRTA 后，如果您发现有多个 JavaScript 文件从服务器得到 200-OK，则说明该服务器未识别实体标记并将重新发送整个文件。不只是重新加载文件，浏览器通常还会发现这个文件与缓存中的文件相同并试图阻止服务器重新发送完整的文件。
浏览器的做法是发出一个 Reset 标记来关闭 TCP 端口。这会增加往返数量，原因是需要新端口来完成剩余文件的下载。一个简单的解决方案是为文件设置到期日期，这样浏览器就可以重复使用缓存的文件，而不必调用服务器。
10. 重定向前三思站点地址处在不断变化中，通常使用重定向将用户指向新位置。但是，这些重定向很费时间，应该加以替换。想想站点是否能从旧的 URL 给出响应。
11. 使用压缩许多 JavaScript、CSS 和 HTML 文件可以压缩到 4 比 1 的比例。XML 的压缩比更大。这些类型文件的好处是服务器可以一次性压缩它们，然后存储压缩的版本。这就能减小服务器上的 CPU 负载和网络流量。
ASPX 这类动态文件需要针对每个用户即时压缩，因此它们通常使用负载平衡器这类外部设备进行压缩。人们经常问我压缩是不是会占用很多浏览器时间，是不是所有浏览器都能处理压缩。首先想想在网络中加载大文件需要花费的时间。如果 VRTA 将每个文件都放入压缩实用程序，然后在可压缩性一列中显示新文件与旧文件的比率，该值不大于 1 表示文件已经压缩。在这一实例中，加载站点上的 JavaScript 文件需要 1 到 5 秒。
对于多数现代 PC，解压缩这些文件的时间以毫秒计。浏览器必须在 Get 请求中发送一个 "will accept gzip, deflate" 声明，告诉服务器它可以处理压缩。
用做缩略图时，全尺寸图像通常重新设定格式。另外，最好试用不同的图像格式以确定哪种压缩效果最佳—JPG、GIF 或 PNG。奇怪的是，我曾发现过显示没有压缩的图像，因此不要假定所有的图像都已正确压缩。
另外，记住从文件中删除空格，这通常会使文件尺寸减小 20%。注意：这里的空格包括制表符、新行，尤其是批注。可以使用几种工具完成这一操作。建议使用压缩和混淆两种技术，它们的效果是累积的。
12. 编辑您的 CSS出于某些原因，开发人员习惯在其 CSS 文件中拼出每个字体实例，而不是利用层叠效应。如果您读取一个 CSS 文件，您会看到许多反复重复的词汇，这不是一种高效的编写方式。
使用 Visual Round Trip Analyzer
您知道了要查找什么；现在返回来查看自己的站点。您可以从《MSDN 杂志》
网站上下载并安装 VRTA。如果用户没有安装 NetMon 3.2 或更高版本，会收到安装提示。这要用到您所使用的机器上的管理权限。
安装完成后，VRTA 将自动启动。您还会在自己的桌面上发现图标。单击启动按钮会让 VRTA 打开 NetMon 捕捉。现在再次访问您的网站。一次仅完成一个原子事务（称为任务）。浏览到一个页面并让它进行渲染—这就是一个事务。停止 VRTA 以进行查看。在单击“下一步”按钮前，先再次启动 VRTA，渲染后重复上述步骤。
接下来，打开左侧的文件夹来打开现有的捕获文件。并用它查看所有文件。VRTA 会创建所有文件的文本版本，称为 RTA.txt。NetMon 图标可以直接将您引至捕获文件。可以正常保存、复制、粘贴并打印作业。您已经使用了“启动”和“停止”按钮。您可以使用“缩放”按钮放大文件的可视区域。查看微小细节时，这一功能非常有帮助。使用“选择网络”告诉 VRTA 侦听您的有线或无线 LAN 接口。使用最长时间下拉列表设置数值范围。
工具中有三个悬停窗口。第一个在“主图表”选项卡上，您可以从中看到端口下载的文件。悬停在任意文件上方可以查看其更多详细信息。在“所有文件”选项卡上，您可以看到按启动顺序排序的文件。悬停在 URI 上方可以查看每个文件的详细信息。在“分析”选项卡上，悬停在任意规则上方可以查看文件的异常列表。
除了“复制”和“粘贴”按钮，VRTA 还创建两个文件。NetMon 捕获文件包含原始数据包的详细信息。您可以利用它重新创建所有 VRTA UI。您还可以深入研究捕获文件，以便了解专用工具未能显示的更多内容。RTA.txt 文件是表格形式的页面加载时间统计数据。您可使用 Microsoft Office Excel 将其打开以便阅读。
如果您使用工具查看多个不同的网页，我想确保您了解 Web 性能测试的几个要点。如果测试时您实际上离服务器不远（基本上在几百英里之内），但您的用户遍布全球，则您需要全球冲浪或使用 WAN 模拟器（仿真器）。有一些软件实用程序可以修改您所用网络中的比特速率、RTT 和数据包丢失。
在 Microsoft，我们使用的 WAN 模拟器基准是比特速率为 300/64Kbps，全球内容的 RTT 为 300 毫秒，本地内容传输网络的 RTT 为 50 毫秒。我们的数据包丢失设为 3%。这一基准让我们能跨多种应用程序的多个版本进行测试，并在相同的环境内查看其相对性能。
记住，一个示例代表的只是一个示例。每次捕获都略有不同，由于网络或服务器中的内容更改或拥塞，它们常常会截然不同。我强烈建议您多选几个示例，直到出现稳定状态。
安装 NetMon 时，它包括一个名为 NM_cap.exe 的命令行版本。创建脚本来启动 NM_cap，浏览到页面，在渲染后停止 NM_cap 并保存文件。使用 VRTA UI 执行打开和查看操作。
您还应转到 "About:Blank" 页，在 Explorer | 工具 | Internet 选项中删除缓存的文件，来重新创建第一时间用户体验（称为第 1 次加载页面）。我们使用空白页是因为 Internet Explorer 将自动重新加载您正在查看的页面。关闭浏览器会强行关闭所有 TCP 连接。然后在浏览器中打开您的测试页。对于第 2 次加载页面（用户第二天返回页面），只需关闭浏览器再重新打开测试页即可。
最后一个警告：注意公司的代理服务器—这些服务器建立起防火墙，防止公司资源受到来自 Internet 的恶意入侵。但是，它们也会改变您的性能示例。压缩功能通常是关闭的，这会对您有误导，让您认为来源服务器上该功能也是关闭的。代理服务器还会屏蔽 Keep-Alives。所以最好避开公司的代理服务器，直接在 Internet 上做测试。
结论
报告由 VRTA 生成。您在此读到的最佳实践代表的是目前已知的水平。但事物是不断发展的。仔细研究 NetMon 捕获的原始数据，从中找出适合您的新模式和最佳实践。
非常感谢帮我创建这一新可视化工具的杰出团队：Ron Oshima、Lucius Fleuchaus、Jason He 和 Doug Franklin。
Jim Pierson 已在 Microsoft 工作了 12 年，其中有 5 年专门研究 Web 性能工程。Jim 是全局性能团队的首席经理，这个团队负责为评估、分析及 MSN 和 Windows Live 在线服务最佳实践培训提供工具。
测验答案：1=b、2=b、3=a、4=a、5=a、6=a、7=b、8=b
扫一扫
64
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
