简述移动网站性能监控思路

本文将阐述移动网站性能监控的意义,并从指标角度叙述移动网站性能监控思路。

站在起跑线和终点线上

给一个网页计时,就像F1比赛一样,站在起点掐着秒表等待其抵达终点的那一刻。客户端见证了这一切的发生,但似乎有些过程并不明亮,仿佛就像发车区的看台看不到背面赛道的情况。但好在时间是不会“骗人”的。比赛最在意的是时间,跑一圈耗时最少的就是冠军。虽然英特网上很难选出一个绝对的冠军,但对于每个网站,它们的用户会在意,甚至在心里默默画个圈圈。所以如果跑得慢,用户往往是不会买账的,甚至会路转别家的粉;那些跑得快的,凭借一条铁律“网页延迟1秒74%用户离开”,然后趁虚而入。
中国有句老话:

别让孩子输在起跑线上。
我们即将讨论的话题就是针对这“孩子”——我们的网站。在解决“不输在起跑线”之前,我们要做的事情就是搞清楚孩子为什么“输在起跑线上”。

插一句:为什么是移动网站?

本文重点关注移动网站,原因有二。一方面,是我从事的工作中移动端的业务占比很大,也是转化率最高的一部分。另一方面,相比PC接入互联网的方式和体验,移动端的现状仍需要“特殊关怀”。

优化与投入产出比

前人总结了很多关于网页优化的最佳实践,随便拿来一个,不一定适用在我们的网站上,但不代表不能用。于是,开始了一轮又一轮优化,然后总结陈词,优化带来了多少回报。验证一套正确的方案的路上会绕多少弯路不得而知,反正结果是对的。然而,在我看来这些都是像追求KPI一样的做法。除了结果,过程更为重要,优化的方法有很多,哪个最有效,哪个更具性价比,这些不能让用户告诉我们。特别是在开发资源相对紧张,聚焦业务导向时,优化不是用嘴说出来的。那么是否有必要做一个整体的性能监控方案呢?这个还是得看实际的需求,看ROI。但有一套普适价值观值得借鉴“运筹帷幄之中,决胜千里之外”。

问题的分析与分解

从前后端实现方法(渲染模式)来看,网站的实现类型有很多,SPA(单一页面应用程序)、Server-side Render(服务端渲染)、Multi-Pages(多页面站点)以及混合型,模式不同,客户端请求的资源配比就不同。
通常来看,浏览网页包含这些资源:
1. html文档:即网页内容,网站信息的基本载体。
1. css:必须的样式文件。
1. js:必须的脚本文件。
1. images:加载的图片资源。
1. ajax:异步网络请求。


页面的加载可以划分为三部分:网络时间、后端时间、前端时间。《高性能网站建设指南》中的数据表明,发生在网络和后端的时间占到整体加载时间的10%和20%,而前端资源加载时间占到整体加载时间的70%~80%。这里必须强调的是这种划分方法覆盖面较广,同时也迎合了用户的直观期望,即访问网址后能立刻看到网页的骨架,而图片、字体等内容相对加载的比较缓慢。

那么进一步,将这三个部分细化到对应的网络资源,可以通过以下方法分析。

文档资源

访问网页的第一个资源就是网页文档,在访问url时,首先进行的就是浏览器导航状态的变化。

向下箭头左边是文档资源对应的三部分时间,而右边是浏览器端可以捕获到对应的更为详细的时间节点。这些节点中,与用户直观感受相关的节点是domLoading。在此之前,用户看到的主要是浏览器加载中的进度条或者旋转的加载图标,以及空白的屏幕③。另外我们还需要关注,在domComplete之前,如果JS需要访问未完成解析的DOM元素,可能会导致无法访问的错误,这是一种不可交互的状态。实际上,在DOM加载过程接近尾声,DOM会改变这个状态变成可交互。

访问外部资源

对绝大多数浏览器来说,处文档外的资源访问规则如下:

JS脚本

web的模式是同步的,开发者希望解析到一个script标签时立即解析执行脚本,并阻塞文档的解析直到脚本执行完。如果脚本是外引的,则网络必须先请求到这个资源——这个过程也是同步的,会阻塞文档的解析直到资源被请求到。这个模式保持了很多年,并且在html4及html5中都特别指定了。开发者可以将脚本标识为defer,以使其不阻塞文档解析,并在文档解析结束后执行。Html5增加了标记脚本为异步的选项,以使脚本的解析执行使用另一个线程。

预解析(Speculative parsing)

Webkit和Firefox都做了这个优化,当执行脚本时,另一个线程解析剩下的文档,并加载后面需要通过网络加载的资源。这种方式可以使资源并行加载从而使整体速度更快。需要注意的是,预解析并不改变DOM树,它将这个工作留给主解析过程,自己只解析外部资源的引用,比如外部脚本、样式表及图片。

样式表(Style sheets)

样式表采用另一种不同的模式。理论上,既然样式表不改变DOM树,也就没有必要停下文档的解析等待它们,然而,存在一个问题,脚本可能在文档的解析过程中请求样式信息,如果样式还没有加载和解析,脚本将得到错误的值,显然这将会导致很多问题,这看起来是个边缘情况,但确实很常见。Firefox在存在样式表还在加载和解析时阻塞所有的脚本,而Chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻塞这些脚本。

每一类资源的请求过程是这样的:

我们需要关注资源的加载状况是否影响到页面进程,以及其他资源的加载。

关键指标

以上描述了网页和资源加载的过程,从三个部分(网络、后端、前端)提炼出几个关键指标分别是:
1. 白屏时间(first Paint Time)—— 用户从打开页面开始到页面开始呈现内容为止;
2. 首屏时间 —— 用户浏览器首屏内所有内容都呈现出来所花费的时间;
3. 用户可操作时间 (DOM Interactive) —— 用户可以进行正常的点击、输入等操作;
4. 页面加载总时间 —— 页面所有资源(文档+外部资源)都加载完成并呈现出来所花的时间。
5. 资源分类加载时间 —— 除文档资源外,页面每个资源的加载时间。
实现方面分别需要结合Navigation Timing API 与 Resource Timing API。

其他问题

吞吐量

系统在单位时间内处理请求的数量被称作吞吐量,是决定系统响应时间要素,在不同的业务领域TPS(Task per Second)的统计方式不同。我们希望通过吞吐量和PV之间的关系,衡量服务器总体性能。而这种趋势通过页面数据难以评估。

异常与错误

针对脚本,异常和错误会在JS的执行过程中产生,而这些错误可能会导致页面无法达到预期展示。因此也是我们关注的一类问题。这部分信息应包括资源请求异常和堆栈错误信息。

数据处理与分析

维度划分

目前通常以页面、地理区域、浏览器、操作系统、性能指标为几个维度。

样本处理

抽样

当页面请求较高时,应对请求进行抽样,未被抽中的数据进行抛弃。

均值衡量法

在一段时间内,对多个采样点求均值,并用该值代表这段时间内的指标的做法。

参考与引用

OneAPM
美团性能分析框架
“运筹帷幄之中,决胜千里之外” —— 《史记·高祖本纪》,司马迁

发表评论

电子邮件地址不会被公开。 必填项已用*标注