网页性能测试之WebPageTest

想知道您的网站,性能怎么样?

很自然,首先得找一个广被认可的测试工具。我们推荐WebPageTest:

WebPageTest

它是google 开源项目”make the web faster “的子项目(“make the web faster包括page speed,spdy,tcpm等等”),它本来是AOL内部使用的工具,后来在2008年基于BSD开源。其网址如下:
http://www.webpagetest.org/

我们抓取出来里面的主要指标。

那么,问题来了:

  1. 这些指标具体什么意思?
  2. 这些指标之间什么关系?
  3. 我怎么知道自己网站处于什么水平?

本文就是对这些指标逐一分析,分析其之间的关系,并基于HTTPArchive数据库,给您一个基线,以更科学地评估您负责网站的“水平”如何。

HTTPArchive数据库

是一个开源的、用来记录互联网上站点的性能情况和趋势的数据库,存储有国内外很多网站性能指标的“历史”数据。因此可用于网站横向性能比较等。其网址为:
http://httparchive.org/

本文使用的HTTPArchive数据库版本为2015年3月15日。

1. 加载时间(Load Time)

加载时间,或称onLoad Time指的是从开始初始导航到窗口开始加载事件(载入)之间的时间。

分析:

这是一个网页加载事件,许多第三方综合测试工具都会测试这个指标,因其被广泛采用,所以将其作为一个有价值的衡量指标。

其与显示完成(visualComplete)及速度指数(SpeedIndex)关联度非常高。其与页面发送的请求总数之间正相关,即页面中发送的请求总量越多,网站越慢 。

在从HTTP/1.1转换到HTTP2的过程中,这是一个必须要测量的有趣数字。HTTP2(或者H2)的目标是复用TCP连接,旨在减少因为TCP建联3次握手导致的消耗,这样会有助于减少传输总量并缩短通信时长。

作用:

始终测量Load Time,这是因为它是最广泛使用的指标之一,可以在综合测试以及RUM与WebPageTest等不同测量资源间提供性能对比。

需要注意的是,我们认为这是一个非常老的指标,并不能代表用户感知到的性能。随着时间的推移,应该减少对于该指标的倚重,开始采用与性能更加紧密相关、对你的网站更有实际意义的新指标(更多信息请参见注释)。

值分布:

所有值的单位均为毫秒(ms)


HTTPArchive数据

2. 首字节时间(First Byte)

首字节时间(通常缩写为TTFB)指的是从开始初始导航直到浏览器接收基础页面首个字节(重定向之后)之间的时间。

分析:

TTFB似乎与其他指标没有太强的相关性。充其量可以影响启动渲染时间。所有其他指标与该值均相对独立。

作用:

如果针对使用CDN的静态资源收集该指标,该参数可以在一定程度上帮助测量CDN性能。而如果对象是页面上的动态内容,则会有助于确定连接以及后端耗时的健康情况。

由于这是唯一一个可以揭露后端耗时或者CDN比较性能的指标,该指标应当被纳入性能规划的一部分,作为考量依据。

值分布:

所有值的单位均为毫秒(ms)


HTTPArchive数据

3. 开始渲染(Start Render)

开始渲染时间指的是从开始初始导航直到首项非空白内容出现在浏览器显示屏上的时间。

本文暂不做展开。

4. 显示完成(VisualComplete)

visualComplete尝试测量用于渲染“明显位置”(ATF)内容所需要的时间。

分析:

VisualComplete与fullyLoaded(全部加载完毕)、LoadTime及SpeedIndex关系密切。

除非页面上有很多延迟加载的内容,否则visualComplete将与fullyLoaded时间密切相关。

作用:

由于该指标的值与SpeedIndex及onLoad相关,若单独对其测试,则价值不高。

但是,若想要与延迟加载前后的页面性能进行对比,则同时使用visualComplete与fullyLoaded测量实施效率。

值分布:

所有值的单位均为毫秒(ms)


HTTPArchive数据

5. 速度指数(Speed Index)

速度指数是一个计算的指标,用来衡量页面渲染用户可见内容的迅速程度(越低越好)。关于计算方法的更多信息,请点击此处查看。

分析:

SpeedIndex分别和这几个指标紧密关联:visualComplete、renderStart与LoadTime时间。其与首字节时间(TTFB)及pagespeed的相关性较低。

作用:

之所以测量speedindex,是因为它与内容渲染关系密切,尤其是位于明显位置的内容。

因为是一个数字值,其更易于对比,主观解读的空间很小。最大的不足是该指标并非在所有测试产品中都是可用的。

值分布:

对于高度内容导向型的网站,理想的目标值约为1000。

以下是SpeedIndex的分布,所有数值均基于单位(units)而非时间。


HTTPArchive数据

6. 请求总数(Total number of Requests)

请求总数是指一个页面加载完成时,向服务器端发起的请求个数。

分析:

请求总数似乎与第三方域名之类的非性能指标相关联。但是,其确实显示出与fullyLoaded、visualComplete 及onLoad的密切相关性。

作用:

如果已经测量过诸如onLoad这样的指标,那么该指标的价值可能有限。但是当客户过于依赖第三方标签、或者加载了过多第三方内容时我们有理由认为存在第三方内容导致了性能下降,则该指标将可能有用。WebPageTest提供一个选项可以测试前端SPOF。想要了解更多可以点击这里。

值分布:

所有数值均基于单位(units)


HTTPArchive数据

7. 页面速度指数 (PageSpeed Insights)

谷歌PageSpeed主要用于测量“与网络无关的页面性能:服务器配置、页面HTML结构及其对图片、JavaScript与CSS的使用”。

能针对移动设备和桌面设备衡量网页的性能。该工具会抓取网址两次,一次是通过移动设备用户代理,另一次是通过桌面设备用户代理。

PageSpeed得分范围是从0到100分。分数越高,代表性能越好。85分或更高分表明网页性能良好。

分析:

该指标与其他指标的相关性非常低,也能说明其相对的独立性 。同样,还需要注意的是,在多部分情况下为负相关,即时间指标的值越低,pagespeed分数越高。

作用:

谷歌PageSpeed值相对独立于其他指标,但影响网站结构。由于这些是需要由网站开发者实施的测量,因此其是一个非常重要的指标,应成为性能规划工具包的一部分。

除了仅仅作为一个数字,PageSpeed还可以识别页面设计问题,如可能更难以通过其他指标识别的阻止javascripts与样式表。

值分布:

所有值介于0-100之间的单位。


HTTPArchive数据

8. 字节总数 (Total Bytes)

即从页面收到首字节开始计算到整个页面加载完成时一共下载的对象大小总和。

分析:

下载的字节总数与任何指标的关系均不太紧密。但是,其与fullyLoaded、VisualComplete及Load Time的相关性相当高。

值得注意的是,字节总数与fullyLoaded、VisualComplete及onLoad的相关性是非线性的(斯皮尔曼等级相关系数)。

从经验上而言,这可能意味着字节总数2个单位的增长将导致fullyLoaded 1个单位的增长。其可能还意味着字节总数1个单位的增长将导致fullyLoaded 2个单位的增长。

作用:

该指标将有助于揭示规模的突然膨胀,尤其是由于图片或新Javascript库导致的膨胀。

如果你的性能规划中允许使用一个额外指标,则其将会是一个不错的全方位跟踪指标。

值分布:

所有数值单位均为字节(bytes)。


HTTPArchive数据

9.域名数量(domains)

指页面加载的所有资源中,域名数量的总和(由于某些原因,有可能包含很多其他第三方的域名)。

分析:

更高的域名数量似乎意味着网站更加繁忙。同样,更高的域名数量还意味着fullyLoaded时间稍微更高。但是,其相关性并不太高。

作用:

该指标将有助于跟踪碎片与第三方数量。一般而言,必须通过严格的测试流程控制第三方域名数量。

执行始终不同步加载第三方或在onLoad之后对其加以推迟的政策应能确保第三方数量对感知到的性能产生最低影响。

这也是一个需要跟踪的很好的指标,用于确保限制第三方合规性。但是,测量该指标将不会提供关于用户感知性能的任何有益信息。

值分布:

所有值均基于单位/个数。


HTTPArchive数据

性能指标小结

HTTPArchive收集了大量关于桌面网站的数据。SpeedIndex与pageLoad、startRender及visualComplete等感知性能指标拥有显而易见的相关性。许多指标与其相关,如域数量、请求数量以及DOM元素数量。

但是,需要注意的是,如果测量指标有限,建议测量SpeedIndex、LoadTime与PageSpeed分数。

如果面临添加更多第三方的大量压力,那么请测量域数量与请求总数。这些指标对性能的影响可以记录下来,并出示给相应的业务所有者。在合理使用第三方以及使用真正重要的服务方面,这将提供很好的数据支持。

指标相关性的测试说明

看到这里或许您对这些衡量网址性能指标的参数以及他们之间的关系有了一个总体的认识,但可能您对于各个指标之间是怎么形成关联及相关性是如何测试的不太了解,下面将对这部分进行说明。

1. 测试的理论基础

为了计算结果,本文使用了HTTPArchive数据库。从测试之日起,提取了所有的非空值并加以对比,以了解其中的关联。

我们使用下面2个系数来对各个数值之间的关系进行计算:

  • 皮尔逊相关系数(Pearson Correlation):是衡量两个变量X与Y之间线性相关(依赖)的指标,其值介于+1与?1之间,1表示完全正相关,0表示无相关性,?1表示完全负相关。
  • 斯皮尔曼相关系数(Spearman Correlation):是一个衡量两个变量之间统计相关性的非参数指标。其评估的是两个变量之间关系的紧密程度,可以使用单调函数进行描述。如果没有重复的数据值,则当各个变量均是彼此的完美单调函数,则完美的斯皮尔曼等级相关系数为+1或?1。

在本分析中,超过+/-0.7的相关系数被视作显著相关,低于+/-0.4的值被视作相关性不高。

如果两个值之间的相关性不高,其可能意味着两个变量之间相对独立。

2. 测试结论

根据研究结果,在丰富程度与提供不同数据视角方面,以下指标似乎比较突出:

  • SpeedIndex(性能感知)
  • LoadTime(后端兼容性)
  • 谷歌Page Speed(网络独立优化)
  • TTFB(后端效率、CDN效率)
  • 域总数(第三方干扰)

需要注意的是,每个网站都是不同的,而且服务于各种不同的目的 。所以最好的测量指标要能够测量关键业务行为的效率。如果指标均不符合你的要求,请考虑开发有助于提升你业务的自定义指标。

延展阅读

    • 原始的速度分数相关性电子表格:https://docs.google.com/a/akamai.com/spreadsheets/d/1yUvYlJmt2DBrmO0DIxO9ywXEyz_8CmoesWHAYpRQmeM/edit?usp=sharing
    • WebPageTest指标定义:https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics
    • 性能预算的一般概念:https://en.wikipedia.org/wiki/Performance-based_budgeting
    • Tim Kadlec的性能预算博客:http://timkadlec.com/2013/01/setting-a-performance-budget/
    • Lara Callendar Hogan的Etsy性能预算:https://codeascraft.com/2014/12/11/make-performance-part-of-your-workflow/
时间: 2024-12-29 16:47:48

网页性能测试之WebPageTest的相关文章

【原创】性能测试之——网络环境分析

性能测试之——网络环境分析 首先,我们需要了解宽带上网时的网络带宽环境概念: 这里指的是带宽网速的单位计算方式方法及关系. 在计算机网络.IDC机房中,其宽带速率的单位用bps(或b/s)表示:换算关系为:1Byte=8bit 1B=8b             ---------- 1B/s=8b/s(或1Bps=8bps) 1KB=1024B     ---------- 1KB/s=1024B/s 1MB=1024KB  ---------- 1MB/s=1024KB/s 在实际上网应用中

【原创】性能测试之——性能测试需求分析

性能测试之——性能测试需求分析 这里以一个电商购物(B2C)网站为例: 客户的购物网站性能测试(业务)需求: 从12月下旬至农历年底(来年2月初)(<=50天)网站预计营业额(400万),这里营业额可以理解为网站完成购买订单总金额: 访问订单转化率:10%,这里理解为百分之多少的访问量会转化为实际的网站订单: 每日访问时间:24小时×80%,这里理解为正常用户会在早6点至凌晨0点之前进行电子购物,下午18点下班至晚上22点为购物高峰期: 每个订单平均选购商品数:3件左右共计300元左右的金额,这

毫秒必争,前端网页性能最佳实践

你愿意为打开一个网页等待多长时间?我一秒也不愿意等.但是事实上大多数网站在响应速度方面都让人失望.现在越来越多的人开始建立自己的网站,博客,你的网页响应速度如何呢?在这篇文章中我们来介绍一下提高网页性能的最佳实践,以及相应的问题解决方案,让站长或者即将要成为站长的朋友了解如何去测试和提高网站响应速度,对自己的网站更有信心. 最佳实践 最佳实践我们引用的来自yahoo前端性能团队总结的35条黄金定律.原文猛击这里.下面我们分门别类将每条的关键点总结一下. 网页内容 减少http请求次数 减少DNS

smarty对网页性能的影响--开启opcache

在上一篇<smarty对网页性能的影响>中,默认没有开启opcache,于是我安装了一下zend opcache扩展,重新实验了一下,结果如下: 有smarty 用apache的ab命令进行压力测试,并发10个,不算大:同时用sar命令进行cpu利用率的统计.命令如下: ./ab -c 10 -n 100000 http://cq01-rdqa-dev072.cq01.baidu.com:8008/index.php sar -u 2 1000 >/tmp/smarty.sar &

[Android Pro] Android应用性能测试之CPU和内存占用(转载)

首先稍做分析一下测试环境:我们知道CPU和内存占用是一个实时变化的状态,而市面上还没有具体的哪款android应用能做到实时监控CPU和内存占用并使用log日志保存.考虑到android的底层框架是基于Linux的平台,所有我们可以通过Linux的资源监控命令来实现对android平台的资源实时监控. 要做到上边的测试环境的实现,需要具备以下几点: 1.被测试的手机具备root权限:因为涉及到底层的linux命令,需要读取或执行相应的文件.至于如何root你的手机,不同型号的手机root的方法不

性能测试之-wrk(转)

性能测试之-wrk(转) 转载地址:http://zjumty.iteye.com/blog/2221040 http://www.cnblogs.com/rainy-shurun/p/5867946.html 测试先行是软件系统质量保证的有效手段. 在单元测试方面, 我们有非常成熟的 xUnit 方案. 在集成测试方面, 我们 selenium 等自动化方案. 在性能测试方面也有很多成熟的工具, 比如 LoadRunner, Jmeter 等. 但是很多工具都是给专门的性能测试人员使用的, 功

老李分享知识:性能测试之TPS和吞吐率

老李分享知识:性能测试之TPS和吞吐率      当增大系统的压力(或添加并发用户数)时,吞吐率和TPS的改变曲线呈大体一致,则系统基本稳定. 若压力增大时,吞吐率的曲线添加到一定程度后出现改变缓慢,甚至平坦,同时TPS也趋于平坦,查看系统资源运用,假如资源运用率比较低,说明服务器硬件资源不存在疑问,查看网络流量,估计网络带宽存在疑问. 同理若点击率/TPS曲线出现改变缓慢或者平坦, 点击率(用户每秒发出的请求数)假如在压力添加时,趋于平坦,很可能是服务器响应时间添加,观察服务器资源运用情况,确

毫秒必争,前端网页性能最佳实践--转载

转载,原文地址:http://www.cnblogs.com/developersupport/p/webpage-performance-best-practices.html#httprequest 你愿意为打开一个网页等待多长时间?我一秒也不愿意等.但是事实上大多数网站在响应速度方面都让人失望.现在越来越多的人开始建立自己的网站,博客,你的网页响应速度如何呢?在这篇文章中我们来介绍一下提高网页性能的最佳实践,以及相应的问题解决方案,让站长或者即将要成为站长的朋友了解如何去测试和提高网站响应

网页性能优化

文章首发: http://www.cnblogs.com/sprying/p/4251682.html 本文先从网页性能优化点说起,然后介绍怎么实施性能优化,有哪些性能检测工具. Yahoo!性能优化35条 Yahoo!性能优化现在有35条,划分成了几个类别,content.server.Cookie.CSS.JavaScript.Images.Mobile. 减少HTTP的请求数 合并Js.CSS文件,使用CSS sprites,使用Inline images(将base64的图片数据放在页面