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

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

这是原文

咱们目前都知道, 一个网页的访问速度对于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.