对于前端来说,最重要的是体验,而在前端体验中,最为核心的就是性能。
相信大多数用户接入前端性能监控(RUM)都是为了通过 RUM 质量评价体系来验证前端性能和质量如何,而直接影响性能和质量的则是一系列的指标,因此了解页面性能指标显得格外重要!前端性能监控 RUM 是腾讯云的大前端领域页面质量和性能监控平台,聚焦提升用户体验。了解详情
通俗点说,某用户想了解页面访问速度快,是否快,究竟有多快?怎么衡量?需要一个中立的裁判来裁决,而 RUM 的角色正是这个裁判。本文会结合前端监控 SDK 源码 - Aegis 和 Google 最新的页面性能规范为大家讲解下列两大个主题:2.如何看懂 RUM 可视化图表?并通过图表数据进行项目优化?在前端监控中指标众多繁杂,例如:白屏时间、首屏时间、FCP、FMP、LCP、FID、TTFB等等,一般人难以把握。我们从中抽取一些最常见,最实用的规范跟大家一一解释。要解释这些指标,还是要先祭出网络连接瀑布图,想必只要对页面性能稍有了解的用户都见过这张图。与这张图一一对应的,是浏览器里面的 `performance.timing` 属性,我们将其同时打印出来,做一个数据的对比说明。- navigationStart: 表示从上一个文档卸载结束时的 unix 时间戳,如果没有上一个文档,这个值将和 fetchStart 相等。
- unloadEventStart: 表示前一个网页(与当前页面同域)unload 的时间戳,如果无前一个网页 unload 或者前一个网页与当前页面不同域,则值为 0。
- unloadEventEnd: 返回前一个页面 unload 时间绑定的回调函数执行完毕的时间戳。
- redirectStart: 第一个 HTTP 重定向发生时的时间。有跳转且是同域名内的重定向才算,否则值为 0。
- redirectEnd: 最后一个 HTTP 重定向完成时的时间。有跳转且是同域名内部的重定向才算,否则值为 0。
- fetchStart: 浏览器准备好使用 HTTP 请求抓取文档的时间,这发生在检查本地缓存之前。
- domainLookupStart/domainLookupEnd: DNS 域名查询开始/结束的时间,如果使用了本地缓存(即无 DNS 查询)或持久连接,则与 fetchStart 值相等
- connectStart: HTTP(TCP)开始/重新 建立连接的时间,如果是持久连接,则与 fetchStart 值相等。
- connectEnd: HTTP(TCP) 完成建立连接的时间(完成握手),如果是持久连接,则与 fetchStart 值相等。
- secureConnectionStart: HTTPS 连接开始的时间,如果不是安全连接,则值为 0。
- requestStart: HTTP 请求读取真实文档开始的时间(完成建立连接),包括从本地读取缓存。
- responseStart: HTTP 开始接收响应的时间(获取到第一个字节),包括从本地读取缓存。
- responseEnd: HTTP 响应全部接收完成的时间(获取到最后一个字节),包括从本地读取缓存。
- domLoading: 开始解析渲染 DOM 树的时间,此时 Document.readyState 变为 loading,并将抛出 readystatechange 相关事件。
- domInteractive: 完成解析 DOM 树的时间,Document.readyState 变为 interactive,并将抛出 readystatechange 相关事件,注意只是 DOM 树解析完成,这时候并没有开始加载网页内的资源。
- domContentLoadedEventStart: DOM 解析完成后,网页内资源加载开始的时间,在 DOMContentLoaded 事件抛出前发生。
- domContentLoadedEventEnd: DOM 解析完成后,网页内资源加载完成的时间(如 JS 脚本加载执行完毕)。
- domComplete: DOM 树解析完成,且资源也准备就绪的时间,Document.readyState 变为 complete,并将抛出 readystatechange 相关事件。
- loadEventStart: load 事件发送给文档,也即 load 回调函数开始执行的时间。
- loadEventEnd: load 事件的回调函数执行完毕的时间。
根据上述的定义,我们总结出来常见的页面指标的计算公式:// 计算加载时间
getPerformanceTiming() {
const t = performance.timing;
const times = {};
// 页面加载完成的时间,用户等待页面可用的时间
times.loadPage = t.loadEventEnd - t.navigationStart;
// 解析 DOM 树结构的时间
times.domReady = t.domComplete - t.responseEnd;
// 重定向的时间
times.redirect = t.redirectEnd - t.redirectStart;
// DNS 查询时间
times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;
// 读取页面第一个字节的时间
times.ttfb = t.responseStart - t.navigationStart;
// 资源请求加载完成的时间
times.request = t.responseEnd - t.requestStart;
// 执行 onload 回调函数的时间
times.loadEvent = t.loadEventEnd - t.loadEventStart;
// DNS 缓存时间
times.appcache = t.domainLookupStart - t.fetchStart;
// 卸载页面的时间
times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;
// TCP 建立连接完成握手的时间
times.connect = t.connectEnd - t.connectStart;
return times;
}
下列我通过各前主流图表来深入了解 RUM 的性能指标。
瀑布图是表示网站资源如何下载、由引擎解析的图表,其包含首耗时、请求响应等8个性能指标,它让我们可以查看资源之间的顺序和依赖关系。有助于确定加载过程中发生重要事件的位置,还可以让用户轻松看到他们的网站性能的好坏,从而准确显示哪些速度正在减慢网站性能。const t: PerformanceTiming = performance.timing;
if (!t) return;
// 这里不知道为什么有时候 t.loadEventStart - t.domInteractive 返回一个很大的负数,暂时先简单处理
let resourceDownload = t.loadEventStart - t.domInteractive;
if (resourceDownload < 0) resourceDownload = 1070;
result = {
dnsLookup: t.domainLookupEnd - t.domainLookupStart,
tcp: t.connectEnd - t.connectStart,
ssl: t.secureConnectionStart === 0 ? 0 : t.requestStart - t.secureConnectionStart,
ttfb: t.responseStart - t.requestStart,
contentDownload: t.responseEnd - t.responseStart,
domParse: t.domInteractive - t.domLoading,
resourceDownload
};
备注:`resourceDownload` 有时会出现一个极大的负数,所以做了简单兼容,取了几个项目的平均值。其他的页面性能指标计算规则大家可以通过代码比较直观的看出来。RUM 中有一个首屏时间,那么Aegis SDK 是如何计算这个指标的呢?1. 默认通过 MutationObserver 这个 API 来监控浏览器 document 对象的 DOM 变化,只计算在首屏内的 DOM 元素,把 DOM 变化时间作为 x 轴,单位时间内 DOM 变化的数量作为 y 轴,绘制曲线后,我们找到 DOM 变化最高点,认为是首屏完成。2. 如果开发者觉得该算法不准确,希望自己标记 DOM 元素,可以添加属性 <div AEGIS-FIRST-SCREEN-TIMING
></div>,把某个元素识别为首屏关键元素,SDK 认为只要用户首屏出现此元素就是首屏完成。也可以添加属性 <div AEGIS-IGNORE-FIRST-SCREEN-TIMING
></div>,把该 DOM 列入黑名单。除了上述的数据外,RUM 还根据上报的数据计算了以上几个页面性能相关的指标。计算公式如下:1. 首字节(TTFB) = DNS + SSL +TCP + TTFB2. DOM Ready = DNS + SSL +TCP + TTFB + ContentDownload + DomParse3. 页面完全加载 =DNS + SSL +TCP + TTFB + ContentDownload + DomParse + ResourceDownload上述计算首屏的算法是 Aegis SDK 自主提供的算法,用户场景千变万化,无法覆盖所有场景,而且这个算法也无法得到所有开发者的认同。这个时候就需要祭出 Web Vitals 了。
Google 给的定义是一个良好网站的基本指标 (Essential metrics for a healthy site)。因为过去要衡量一个好的网站,需要使用的指标太多,推出 Web Vitals 是简化这个学习的曲线,站主只要关注 Web Vitals 指标表现即可。目前 Google 的 Web Vitals 源码 中提供了5个指标,分别为:1. CLS(Cumulative Layout Shift - 累积布局移位): CLS 会衡量在网页的整个生命周期内发生的所有意外布局偏移的得分总和。得分是零到任意正数,其中 0 表示无偏移,且数字越大,网页的布局偏移越大。2. FCP(First Contentful Paint - 首次内容绘制):FCP 度量从页面开始加载到页面内容的任何部分呈现在屏幕上的时间,页面内容包括文本、图像(包括背景图像)、<svg>元素或非白色的<canvas>元素。3. FID(First Input Delay - 首次输入延迟):从用户首次与您的网页互动(点击链接、点按按钮,等等)到浏览器响应此次互动之间的用时。这种衡量方案的对象是被用户首次点击的任何互动式元素。4. LCP(Largest Contentful Paint - 最大内容绘制):LCP 度量从用户请求网址到在视口中渲染最大可见内容元素所需的时间。最大的元素通常是图片或视频,也可能是大型块级文本元素。5. TTFB (Time To First Byte - 从服务器接收到第一个字节耗时) TTFB 是发出页面请求到接收到应答数据第一个字节的时间总和,它包含了 DNS 解析时间、 TCP 连接时间、发送 HTTP 请求时间和获得响应消息第一个字节的时间。目前 RUM 采有了其中最重要的三个属性:LCP,FID 和 CLS。这里可以看出与之前 “首屏时间” 比较模糊的定义不同,Google 对 Web Vitals 给出了非常明确的指标定义,并且官方提供了算法支持,那么我们是不是可以直接用 LCP 取代我们自己写的 “首屏算法” 呢?目前显然还是不可行的,由于 LCP 底层使用的是 PerformanceObserver ,还存在兼容性问题,因此短期内还无法完全替代。不过,在可预见的未来,Web Vitals 会成为业界的主流衡量标准,到那个时候,我们也可以卸下历史包袱,全面拥抱开源算法了。
拥有了 RUM 这个好用的工具,下面就可以用数据指导开发和决策了。
我们的项目接入到 RUM 后,怎么样根据 RUM 展示的数据来优化项目呢?下列拿某团队邀请我们对其项目做的一次针对性优化举例。