教你读懂网络请求的瀑布图

本文题目来源于 阮一峰大神的微博

这是原文

我们目前都知道, 一个网页的访问速度对于SEO和用户体验来说非常的重要. 速度快的网站会获得更高的搜索引擎排名, 用户也能浏览其更多的网页;简单说来,聪明的SEO不仅仅优化其网站内容,同时也要考虑如何提升网站的性能.

正如我们在之前这篇文章所讨论的, 你可以使用WebPageTest 这个免费的工具来对你的网站性能进行优化. WebPageTest输出给你的最有用的内容之一, 是一个叫做瀑布图的东西. 瀑布图展现了浏览器为渲染网页而加载的所有的资源, 包括加载的顺序和每个资源的加载时间.  分析这些资源是如何加载的, 可以帮助你了解究竟是什么原因拖慢了你的网页以从而采取对应的措施来提升网页速度.

瀑布图很像Excel表格: 概念很清楚而且用处很大, 但是很多人并没有将它充分的利用起来. 本文中, 我们将介绍SEO人员如何利用工具(比如WebPageTest)生成的瀑布图来提升网站的性能和用户体验.

如何阅读瀑布图

如果你还不知道如何生成瀑布图, 用 WebPageTest 给你的网站跑个测试就生成了. 测试结果生成以后, 点击第一个结果来看瀑布图. 下边是一个简单的瀑布图表(点击看大图).

正如上边提到的, 瀑布图是一个级联图, 展示了浏览器如何加载资源并渲染成网页. 图中的每一行都是一次单独的浏览器请求. 这个图越高, 说明加载网页过程中所发的请求越多. 每一行的宽度, 代表浏览器发出请求并下载该资源的过程中所耗费的时间.

每一行都是一个彩色条, 从彩色条可以看出加载一个资源的过程中,各个阶段消耗的时间,比如:

为了把一个请求的各阶段的时间缩短, 首先需要弄懂每一阶段的含义. 下面简单介绍一下:

• 
  DNS Lookup [深绿色] - 在浏览器和服务器进行通信之前, 必须经过DNS查询, 将域名转换成IP地址. 在这个阶段, 你可以处理的东西很少. 但幸运的是, 并非所有的请求都需要经过这一阶段.
• Initial Connection [橙色] - 在浏览器发送请求之前, 必须建立TCP连接. 这个过程仅仅发生在瀑布图中的开头几行, 否则这就是个性能问题(后边细说).
• SSL/TLS Negotiation [紫色] - 如果你的页面是通过SSL/TLS这类安全协议加载资源, 这段时间就是浏览器建立安全连接的过程. 目前Google将HTTPS作为其 搜索排名因素 之一, SSL/TLS 协商的使用变得越来越普遍了.
• Time To First Byte (TTFB) [绿色] - TTFB 是浏览器请求发送到服务器的时间+服务器处理请求时间+响应报文的第一字节到达浏览器的时间. 我们用这个指标来判断你的web服务器是否性能不够, 或者说你是否需要使用CDN.
• Downloading (蓝色) - 这是浏览器用来下载资源所用的时间. 这段时间越长, 说明资源越大. 理想情况下, 你可以通过控制资源的大小来控制这段时间的长度.

瀑布图上还有一些其他的线. 垂直的绿色线代表渲染开始.在我们上一篇文章上一篇文章讨论过, 在渲染开始之前, 用户看到的都是一个空白的屏幕. 如果渲染开始的时间很长, 用户会觉得你的网站速度很慢, 反应迟钝. 瀑布图上还有一些其他的数据点, 比如"Content Download", 但这些是更高级的话题, 超出了本文所讨论的范围.

根据瀑布图进行性能优化

那么我们如何是一个web页面加载的更快并且创造更好的用户体验呢? 瀑布图提供是三个直观的玩意儿来协助我们达成这一目标:

1. 首先, 减少所有资源的加载时间. 亦即减小瀑布图的宽度. 瀑布图越窄, 网站的访问速度越快.
2. 其次, 减少请求数量 也就是降低瀑布图的高度. 瀑布图越矮越好.
3. 最后, 通过优化资源请求顺序来加快渲染时间. 从图上看, 就是将绿色的"开始渲染"线向左移. 这条线向左移动的越远越好.

咱们把每一条都来详细的解说一下.

把瀑布图变窄

可以通过降低每一个资源的下载时间达到把瀑布图变窄. 瀑布图的每一行使用不同的颜色代表获取资源的不同阶段. 不同的颜色使用不同的优化手段来提升网页的整体速度.哪种颜色出现的多, 就用对应的方式降低那个阶段消耗的时间.

• 橙色出现的比较多? 橙色代表你的网站初始化TCP连接的时间. 对于同一个域名,只有最开始的2到6个请求需要建立TCP连接, 那之后, 已存在的连接会被复用. 如果你在图上看到很多的橙色, 说明你的网站没有使用持久连接(长连接). 下面这张图就是没有使用长连接的网站. 可以看到, 每一行的请求开始部分都有橙色.一旦使用了长连接, 每一行的请求宽度都会缩短一半. 因为浏览器不用为每次请求都建立新的连接了.
• 紫色的部分很长吗? 紫色是用在SSL/TLS协商的时间. 如果你看到同一个网站一次又一次的出现紫色, 这说明你没有优化TLS. 在下面这个截图中, 可以看见2个HTTPS请求. 其中一个服务器做了优化, 而另一个把TLS配置的很差:关于优化TLS的性能, 请看之前这个文章.
• 有长条的蓝色吗? 蓝色是服务端响应之后, 浏览器下载资源所用的时间.如果一行有很长的蓝色条, 八成是说明这个资源非常的大. 提升网站速度的一个妙招就是简单的把需要传到客户端的数据量减少. 如果你看到一大堆蓝条, 反省一下"怎么数据量这么大?" 你还可以通过 HTTP compression, minification, 或者 image optimization 来减小数据量. 举个例子, 在下图中我们看到, 下载PNG图片用了很长时间, 因为蓝条特别长.深入研究一下, 我们发现这个图片有1.1MB那么大! 这说明设计师在PS之后忘了把图片导出成合适的尺寸. 用图片优化技术就能缩短这一行并且使整体页面加载的更快.
• 有很多的绿条? 绿条是等待获取内容的时间. 你可能经常看到绿条(等待时间)有80或者90毫秒, 而资源下载时间仅用了1毫秒. 减小绿条的最好方法就是把你的静态资源, 比如图片, 放到离你用户比较近的CDN上去.更多关于这个的话题, 以后再说.

降低瀑布图的高度

如果瀑布图很高, 说明浏览器加载页面需要发很多的请求. 减少请求的最佳方法就是看看你页面中包含的所有内容然后想想这个内容是否是必需的.比如:

• 看到一大堆CSS和JS文件了没? 我不骗你,下面这个图是一个AOL网站的瀑布图的一部分, 网页中请求了48个CSS文件! 如果你的网站请求了很多独立的CSS或JS文件, 你需要用CMS插件或者作为构建过程中的一步把它们合并. 合并文件可以减少请求数, 提升网页速度.
• 看到很多"小的"(不到2kb)JS文件和CSS文件了吗? 考虑一下用<script>, <code>或者<style>标签直接把这些内容内联到html文件中.(这个链接加的太蛋疼了, 不知道怎么翻译) Consider including the contents of those files directly in your HTML via inline <script>, <code>, or <style> tags.
• 看到很多302重定向吗? 重定向在图中是高亮的黄色行. 代表你页面上的链接经常过期或者出错. 这些过期或者出错, 产生了没必要的重定向, 这玩意儿没什么用, 只能把你的瀑布图变高. 把那些链接替换成新的URL吧.

提升渲染时间

再说一遍, 开始渲染时间代表用户首次从空白页面到看到加载出东西的时间.

你的渲染开始时间如何? 如果超过1.5秒, 就得优化了. 说到优化, 先看一下开始渲染线(垂直的绿线)的"上边和左边"的所有资源. 这些东西就是为了提升渲染时间所要优化的东西.

一些提示:

• 看到加载JS库了吗? 引入JS会阻塞页面的渲染, 如果可能的话, 把这些JS放到页面的下边.
• 看到很多单独的CSS请求吗? 浏览器在渲染页面之前会等待所有CSS下载完成. 能不能合并这些CSS或者把一些CSS内联到HTML中?
• 看到额外的字体了吗? 当使用了额外的字体, 浏览器不会绘制任何东西直到下载了 那个字体. 可能的话, 要尽量避免使用额外加载的字体. 如果避免不了, 确认去掉了任何为了加载字体而做的没什么用的302跳转, 或者(更好的情况) 把那个字体copy一份, 放在你自己的服务器上.

举个例子, 这是一个瀑布图的开头部分:

绿色的开始渲染线刚刚超过一秒一点儿, 这很不错. 然而看线的左侧, 你会看到一些可以优化的地方. 首先, 有多个JS文件. 除了JQuery, 其他的大概都可以延迟加载. 同样, 有很多CSS文件. 这都可以合并. 这些优化能提升开始渲染时间.

你可能需要和你的设计师和开发人员一起合作来做这些优化. 但优化结果很划得来. 没人喜欢看一个空白的屏幕!

其他因素

我的服务器够快吗? 我们知道, 第一字节返回时间是搜索排名的一个因素. 幸好瀑布图能告诉你这个数值. 简单看一下瀑布图的第一行. 这个展示了浏览器如何下载基本HTML页面的时间信息. 看看TTFB结果, 如果超过500毫秒, 你的服务器可能不够给力或者未经优化. 找你的托管服务商聊聊, 提升一下服务器的能力.  下边这个示例的瀑布图展示了一个需要将近10秒才能响应的服务器! 真是慢到家了!

我需要弄个CDN吗?

延迟可能是网站请求的一个大资源造成的, 需要解决的问题是你的服务器和浏览者的地理距离问题.之前讨论过, 延迟受距离和光速影响; 仅仅靠一个高速网络连接解决不了问题. 内容分发网络(CDNs) 通过把你的静态资源(图片, CSS, JS等等)拷贝并存放到全世界的各个服务器上来降低浏览网页的延迟.

瀑布图揭示了网络延迟对你站点的速度的影响, 以及你是否需要使用CDN. 看看浏览器请求静态资源时候的TTFB就知道了. TTFB是由请求发过到服务器的时间, 服务器处理请求时间, 响应中的第一字节返回来的时间组成的. 对于静态资源来说, 服务器对请求不需要做任何的处理, 所以静态资源的TTFB就是请求和响应在浏览器和服务器之间的网络上走一个来回的时间. 如果这个时间很长, 那就说明内容(译者按: 原文是content, 我感觉就是服务器离用户太远吧)离你的用户距离太远.

判断是否需要CDN, 首先要知道服务器的位置. 然后用WebPageTest在离你服务器很远的地方跑一个测试. 如果你的服务器在美国, 那就在亚洲或者欧洲做测试. 现在, 找几条到你服务器的图片或者CSS请求, 然后看看TTFB结果. 如果静态资源的TTFB超过了150毫秒, 你该考虑用CDN了. 商业的来说, 你可能看下AkamaiIf的企业级功能.  至于便宜点儿的, 看这个 CloudFlare which offers free CDN services.

Summary

信不信由你, 我们谈的仅仅是通过瀑布图做性能优化的一些皮毛. 但是这对于看懂瀑布图并且查找网站最基本的性能损耗点来说, 足够用了.

优化内容, 使每个请求变快, 瀑布图就会变窄.减少没必要的请求, 瀑布图就会变矮. 最后, 优化开始渲染之前的所有内容, 是你的用户在最短时间内看到网页从空白到加载出内容.

如果还不知道从哪下手, 看看这个 Zoompf‘s Free Performance Report 来分析你的网站并优先用那些大大改善网站性能和瀑布图指标的手段.

About Zoompf — Zoompf was founded by Billy Hoffman, a well recognized expert in the field of the web application development technologies and web security. Billy served as a research director for leading web app security software firm SPI Dynamics (acquired by Hewlett-Packard in August 2007). Following the acquisition, Billy served as Director for Hewlett-Packard’s Web Security Research Group. Billy’s research focused on Web 2.0 technology and security threats, automated discovery of web application vulnerabilities, and web crawling technologies. After HP, Billy went on to start Zoompf, a technology platform for analyzing the root causes of slow website performance.