汽车之家页面性能监控树立通常

一、前言

关注用户体验，提高页面性能，是每位前端研发同窗的日常上班之一。提高页面性能对业务的协助，虽不易权衡，但必需是利远大于弊。如何权衡页面性能优劣？如何协助研发同窗极速定位到页面性能瓶颈点？不时是前端的重点上班之一。本文分享汽车之家在页面性能监控树立方面的局部上班，关键蕴含三方面：

整合选中技术方案，构建体系化性能监控架构，提供性能监控和性能剖析工具链，支持产研同窗在 DevOps 各阶段中发现和定位页面性能疑问。

有数据，咱们能力度量；有评分，技术才好改良。

应用采集到的泛滥目的，依据运行个性，按各性能目的的关键水平，设置不同的基线和权重，以加权平均的方式，求得运行得分。经过火数，直观通知研发同窗运行页面快或慢？运行性能高或低？能否须要改良？

运行得分只能反映单个运行的性能状况，关键服务于产研同窗。一家公司有多个部门，每个部门有多个团队，一个团队有多个运行，咱们须要公司、部门和团队层级的性能得分，能力让各级指导直观了解其担任队伍的页面性能，也繁难下级指导判别下级各队伍之间的性能高下，所以咱们依据运行 PV 数和运行级别，仍以加权平均算法，取得团队、部门和公司性能得分。

依据监控页面性能时的运转环境，咱们将技术方案分为两种：分解监控（Synthetic Monitoring，SYN）和实在用户监控（Real User Monitoring，RUM）。

指在经过仿真环境运转页面，评价页面性能。早期代表工具备咱们熟知的 YSlow 和 PageSpeed。随着技术提高，三个最成熟的 SYN 工具为：Lighthouse、WebPageTest 和 SiteSpeed。Lighthouse 只管仅支持 Chrome 阅读器、实施老本较高，然而有谷歌支持、易裁减、目的丰盛、有评分诸多优势，已逐渐替代 WebPageTest，成为 SYN 首选工具。 如下以 Lighthouse 为例引见 SYN 的运转环节、优缺陷。

从运转结果页面来看，Lighthouse 除了输入关键性能目的值和评格外，还向咱们提供优化倡导和诊断结果。10.1.0 版 Lighthouse 区分内置 94、16 条性能和最佳通常方面的规范或倡导，其中不乏日常研发比少当心且较无心义的规范，如：最大限制地缩小主线程上班(mainthread-work-breakdown)、网页已阻止复原往复缓存(bf-cache)、缩小 js 文件中未经常使用的 JavaScript (unused-javascript)等。

介绍经常使用 Node Cli 或 Node Module 方式运转 Lighthouse，同时输入 html 和 json 格局的结果。json 中数据更片面，蕴含如：最大内容渲染时期元素(largest-contentful-paint-element)、应防止出现长时期运转的主线程义务(long-tasks)等明细消息。

依据咱们通常，总结 Lighthouse 有如下优缺陷：

针对上述无余和产品需求，咱们做了一些改良：

n为处置 自动无基准环境，相反页面在不同用户端运转，因运转环 境和配件资源不同，造成结果不同的疑问，咱们做了两方面的改良：

首先，提供 SYN 基准运转环境。应用 Lighthouse Node Module 自研 Web 版 SYN 服务并部署在容器中。经过在 Node 服务端参与队列战略，保证单容器恣意时期只准许运转一个 SYN 义务，且每个容器的配件资源( 4 核 + 4G )和网速性能( M 端运行一致经常使用 10M 网速 ）都一样，从而保证运转结果和最终得分是相对公温和牢靠的。

其次，支持以方案义务，距离 6、12 或 24 小时 的方式运转 SYN 义务。 统计屡次运转结果目的的 AVG、TP 值，扫除少数意外运转的结果偏向。

SYN 实施老本低，便于一致规范，相比 RUM，受运转时环境的影响更小，结果更具备可比性和可复现性，是性能监控的关键一环。基于 Lighthouse，借助 K8S 等容器编排技术，极速搭建提供基准环境的 SYN Web 服务是树立页面性能监控体系的第一阶段。该阶段以提供评价页面性能、剖析慢页面等关键性能为主。只管 Lighthouse还存在 仅支持谷歌阅读器，代表性无余，也不能实在反映实在用户端的性能状况这两个疑问，但瑕不掩瑜，可以作为 SYN 的首选方案。同时，这两个疑问咱们将经过参与另外一种技术方案：实在用户监控（RUM）来处置。

望文生义，指监控运转在实在用户终端(阅读器)，采集用户运转页面时刻实在的性能目的。业内技术方案关键分为两种：

附丽 W3C 组织且各阅读器厂商宽泛支持技术方案：PerformanceTiming 和 PerformanceNavigationTiming。倾向从阅读器处置环节角度去权衡页面运转时各节点、各阶段的耗时。

各厂依据实践需求自研技术方案。谷歌 web-vitals 是其中最低劣的代表，它从用户体验角度，用更深刻易懂的目的展现页面性能。

除上述两种经常出现技术方案外，少数商业前端监控服务厂商，除了支持 W3C 和 web-vitals 外，还提供少数自定义性能目的，如：阿里 ARMS 中的 FMP、字节 WebPro 里的 SPA_LOAD。SPA_LOAD 用于评价 SPA 非的页面性能，有较大翻新性，前面还会提及。

技术选型关键处置两个疑问：1）W3C 的 PerformanceTiming 和 PerformanceNavigationTiming 两规范，应该以哪个为主？2）W3C Timing 规范 和 web-vitals 应该如何协作？

W3C 的 PerformanceTiming 和 PerformanceNavigationTiming 两规范，应该以哪个为主？

PerformanceTiming： 已被最新 W3C 规范废除，不过干流阅读器仍支持，旧阅读器支持好，兼容度高。

：最新规范随 Navigation Timing Level 2 于 2019 年推出，Navigation Timing Level 2 目的是替代涵盖 PerformaceTiming 的 Navigation Timing Level 1。

变卦点：

优势：

缺陷：

论断：

从 Can I Use 统计两者兼容度仅差 2.67%，然而从咱们实践用户散布来看，经常使用 PerformanceNavigationTiming，用户兼容度降低 12%，难以接受。所以咱们以 PerformanceNavigationTiming 为主，如阅读器不支持，则经常使用 PerformanceTiming。两者数据格局差异不大，疏忽 PerformanceTiming 中 domLoading 节点，经常使用 PerformanceTiming 时以为阅读器不兼容 workStart 节点即可。

基于 W3C 规范，着重从阅读器处置环节角度权衡页面性能，以下简称 Timing。

优势：

缺陷：

目前含 6 个目的：TTFB、FCP、LCP、FID、INP 和 CLS，其中 FID 将被 INP 替代。TTFB、FCP 和 LCP 反映页面加载性能，FID 与 INP 代表页面交互体验，CLS 示意页面视觉稳固性。仅 6 个目的，就能支持对页面加载、交互和视觉稳固方面的评价。不过 web-vitals 局部目的源头还是来自于 W3C 制订的 LargestContentfulPaint、LayoutShift、PerformanceEventTiming 和 PerformancePaintTiming 等规范，不过兼容性更好、全体性更强。

优势：

缺陷：

实在、主观、片面权衡页面性能。

同时采集 Timing 和 web-vitals 数据，带来好处有：

RUM 技术选型，同时采集 PerformanceNavigationTiming和 web- vitals。假设阅读器不兼容 PerformanceNavigationTiming，则以 PerformanceTiming 替代。

咱们的需求是：在尽或许不影响页面性能，既能主观、片面权衡页面性能，又能协助研发同窗极速定位性能瓶颈点。详细蕴含三方面需求：1) 目的要片面主观；2) 能发现慢页面的瓶颈点；3) 满足前面两需求前提下，尽或许不影响页面性能。

首先，咱们采集了 web- vitals 六个目的，成果如下：

谷歌方案于 2024 年用 INP 交流 FID，FID 表现第一次性交互的提前时期，INP 示意一切交互中最长的提前时期。咱们以为 FID 和 INP 都有各自经常使用场景，同时保管并不矛盾。

其次，咱们对 PerformanceNavigationTiming做了加工处置，成果如下：

所以咱们联合 W3C 示例图，以点、段和线的方式，展现实在的页面运转环节：

此外，为了更片面表现页面性能，还采集和统计了如下输入：

站点统计数据，依据运行类型是 PC 或 M 来制订慢页面规范，详细阈值如下:

针对慢页面，咱们除了采集上节提到的 PerformanceNavigationTiming、web- vitals、小概率的完整 PerformanceEntry 数据和统计数据外，咱们还会采集：

RUM 必需经过入侵页面，在页面引入 JS SDK 来成功，无法防止地影响页面性能。作为一个发现和剖析页面性能的工具，不应该减轻页面性能疑问。为了将性能影响降到最低，咱们做了两方面上班：

异步加载 JS SDK：页面只引入性能繁多、体积小的 JS 头文件，待页面抵达 DomContentLoaded 事情后，以灵活 script 方式异步加载性能完整的 JS 主文件。

综上所述咱们采集目的关键两大类：PerformanceEntry 和 web-vitals。

SPA 运行非性能该如何评价？

采集上述目的，曾经可以较为主观片面评价惯例页面和 SPA 运行的页面性能。然而 SPA 运行非不是阅读器规范，在 SPA 路由切换环节中：

所以，关于上述目的 SPA 非无 法或无法准确拿到，所以咱们暂不评价 SPA 非性能。

针对业内 SPA 非性能难评价的状况，字节 WebPro 发明性地推出 的概念，基本逻辑为：以触发 history.replaceState() 方法为终点，经过 MutationObserver 监听 dom 变卦、资源加载、恳求发送等变卦事情来寻觅一个页面到达稳固态的时期为终点，经过计算起终点之间的耗时，来权衡 SPA 非的页面性能。SPA_LOAD 相似于惯例页面 onload 事情，然而起始时期比实在路由切换时期晚，到中断时期时页面或许曾经加载终了，略有无余，不过已是最佳的方案，前面咱们或许引入。

只要采集实在、准确的目的值，能力实在反映页面性能，反之，或许误导产研同窗，失误评价实在的页面性能。所以选用采集目的机遇有几大准则：

那么如何确定采集机遇？咱们得先剖析 PerformanceEntry 和 web-vitals 两类目的数据得准确生成

关于 PerformanceEntry 数据，onload 事情触发时，页面已凑近加载终了，PerformanceEntry 中影响首屏加载的绝大局部目的数据曾经生成。未生成的数据对评价页面性能影响不大，如：PerformanceNavigationTiming中的 loadEventEnd 目的值。所以咱们以为 onload 事情触发件时，可以采集 PerformanceEntry 目的。

web-vitals 中各目的生成原理不一，onload 事情触发时：

思索，咱们以为至少要满足：触发 onload 事情或关上页面 5s 之一条件时，能力保证 PerformanceEntry 或局部 web-vitals 目的值准确，采集才无心义。在谋求”样本多“的准则下，联合 RUM SDK 是 onload 事情后异步加载的实践状况，咱们针对页面能否被反常封锁前提下，总共设置了三种采集机遇，其特点如下：

为了防止采集目的影响页面性能，咱们异步加载 RUM JS SDK，web-vitals 中各目的自动仅支持异步回调，异步加载再异步回调，造成采集机遇时仍或许无法拿到各目的值，所以咱们对 web-vitals 源码做了革新，支持同步失掉各目的值。

采集到目的后，须要选用失当上报方式，将目的牢靠的发送到后端。上报方式蕴含两个局部：上报机制和上报机遇。

选用适宜的上报机制，首先，要满足性能需求，阅读器兼容度高，对数据大小最好没限制；其次，能感知上报恳求意外，便于上报重试，进而提高上报牢靠性；最后，客户端支持设置超时时期，防止长时期占用忘了衔接，放大后端服务压力。经常出现上报机制有四种，区分是：Image、XMLHttpRequest、sendBeacon、Fetch API。其特点如下：

相比于 Fetch，XMLHttpRequest 性能简直分歧，兼容性更高；与 Image 对比，XMLHttpRequest 具备兼容度高、数据大小没限制、能感知意外和可设置超时时期等优势；XMLHttpRequest 是页面反常(未封锁)状况下，发送目的数据的首选上报机制。至于 sendBeacon，只管存在诸多无余，然而页面封锁时仍可以上报数据，成功率还较高，适宜作为在页面封锁时，发送尚未发送的目的数据的上报机制。

既然选用了 sendBeacon 作为页面封锁时发送目的数据的上报机制，那该如何判别页面被封锁？传统方案是监听 unload 或 beforeunload 事情，该方案存在两个无余：

更适宜、更现代的方案是监听 pagehide 或 visibilitychange===hiden 事情，该方案除了防止传统方案存在的两无余，兼容度也会更高。关于 SPA 名目咱们不采集非性能目的，触发History.replaceState()方法也算分开页面。

综上所述，全体上报机制为：1）页面反常(未封锁)，到采集机遇时，SDK 采集性能目的数据，经常使用 XMLHttpRequest 机制上报；2）经过监听 pagehide 或 visibilitychange===hiden 事情，当页面被封锁时，假设满足任一采集机遇条件，则立刻采集目的，经常使用 sendBeacon 机制上报。

综上所述，咱们整顿 RUM 实施纲要如下：

实践编码环节中，详细处置流程如下：

在实施环节中，咱们总结 RUM 优缺陷如下：

RUM 架构设计复杂，实施老本较高，由于是技术刚需，只能投入资源，努力做好。

针对 无诊断结果和优化倡导的缺陷，可以联合 SYN，扬长避短，应用 SYN 诊断慢页面性能瓶颈点散布。

关于 无评分，没法判别页面性能优劣的疑问，咱们分三步走：首先，制订慢页面规范，判别单次页面能否快慢，规范值前文已无形容；其次，统计该页面各关键目的的 AVG、TP50、TP90、TP99 值，片面评价页面一切恳求的性能散布；最后，咱们会对页面所在的运前启动评分，间接通知研发同窗，该运行性能优劣，运行评分详细做法，会在上方《树立评分体系》章节细讲。

前文深化剖析了 SYN 和 RUM 各自特点、经常使用方法及优缺陷等，咱们发现 SYN 和 RUM 各有千秋、无法替代，最好同时援用 SYN 和 RUM，构建体系化性能监控架构，提供性能监控和性能剖析工具链，支持产研同窗在 devpos 各阶段中发现和定位页面性能疑问。

在编码、构建和测试阶段，研发同窗可以应用 SYN 来做页面性能测试，判别页面性能能否达标？假设页面性能有疑问，再应用 SYN 诊断性能疑问，取得优化倡导。此举处置前端页面常年以来，前端页面做性能测试难、交付页面品质无规范等痛点。运行部署后，再应用 RUM 采集实在用户页面性能，评价实在页面性能，假设还存在慢页面，仍可以经常使用 SYN 定位慢页面性能瓶颈点，并应用诊断结果和优化倡导，提高优化效率。除此之外，SYN 还可以用来做竞品对比，到达知己知彼、快竞争对手一步的目的。

有了 SYN 和 RUM，咱们可以构建在线继续优化慢页面的闭环，如上图。RUM 担任采集实在用户发生的慢页面，经后盾存储、聚合，智能将 TOPN 的慢页面创立 SYN JOB，待 JOB 运转终了，将诊断结果和优化倡导以告警防止通知研发同窗，研发同窗应用 SYN 优化倡导，再应用 devtools、webpack 等工具，改良页面，交付高品质页面，降低慢页面的频次。如此循环迭代，继续优化运行页面性能，最终运行能到达极致性能。

引入 SYN，自研 RUM SDK，采集到泛滥 SYN 和 RUM 目的数据后，咱们将着手树立评判体系，评价各运行、团队、部门，乃至整个公司的性能状况，输入少数几个关键目的和评分，直观通知各层级、各角色员工其所在组织及同级组织的页面性能状况，经过得分和同级对比，评判能否要优化页面性能？

树立评判体系时咱们秉持着：既要突出重点、关键目的，同时还能片面、综合、主观实在地反映页面性能 的准则。所以咱们将评判体系分为两大块，其一，展现最关键的性能目的。其二，输入各目的、运行、团队、部门及公司层级的性能评分和层级。

展现最关键的性能目的

咱们从 web-vitals 和 performanceNavigationTiming 中各选一个最能代表页面性能的目的，区分为：DCL 和 LCP。LCP 兼容度不高且或许被伪造，DCL 既能替代 LCP 局部反映首屏性能且兼容度高、难以伪造，和 LCP 相反相成，最能表现页面性能。

TP90 代表 90%用户的体验下限，与 AVG、TP50、TP75 比，笼罩和统计更广的用户，还能屏蔽页面在手机端不凡网络环境下，发生的少数脏数据，更具备代表性。

为了片面、综合和主观的评价运行页面性能。咱们将选用各维度具备代表性目的，参考 HTTP Archive 给予的业内目的散布，依据运行个性，如运行类型( PC 或 M 端 )、终端用户( C 端用户、B 端客户和外部员工)，设立不同的评分基线，算出各目的得分。再依据各目的关键水平设置权重，经过加权平均算法，求得运行性能评分。流程如下：

失掉运行性能分环节中触及几个关键流程：1) 目的挑选及权重设置；2) 选用评分算法；3) 确立目的基线；4) 经常使用加权平均算法计算运行性能分。上方逐个引见。

此环节中，我关键思索两点：

片面综合思索。页面性能涵盖多方面，传统上只用首字节、白屏、首屏时期等少数目的来权衡，较为片面，不够主观。咱们以为评判页面性能应该涵盖各维度目的，如：页面加载、交互体验和视觉体验。此外咱们还引入慢 API 比例的概念，API 恳求比例指页面关上后 API 耗时超越 3s 的恳求比例，慢 API，即或许影响首屏加载耗时，也会影响交互环节中的用户体验。为了让研发同窗关注慢页面、将在线 SYN 作为日常开发性能评价工具，咱们将 SYN 评分也作为权重目的，后盾系统每天会统计访问次数 TOP10 的慢页面并智能创立 SYN 定时义务，待义务口头、剖析终了后，将优化倡导和诊断结果通知研发同窗。SYN 评分项，蕴含性能分和最佳通常分，两者都是百分制。

突出重点。提高关键目的的权重比。如：加载目的用于权衡页面能不能用，最为关键，所以赋予权重占比最大。LCP 是最关键的加载目的，权重占比也相应提高。由于 LCP 自身不必定齐全正当且或许被伪造，所以评判页面加载性能时，还引入 DCL、FCP、TTFB、WindwLoad 和 PageLoad 等加载目的。该做法，优势：目的多，维度广、角度大、更片面和更主观准确；缺陷：参与评判系统复杂度和难度。

基于上述两点思索，咱们目的挑选结果和权重占比设置，如下图：

各目的以其 TP90 统计值，介入评分运算。

评分算法关键参考 Lighthouse 评分曲线模型，基本原理是：设置两个控制点，通常是 TP50 和 TP90，即得 50 或 90 分时的目的值点，然后依据这两个控制点，生成对数正态曲线，经过该曲线可以取得任一目的值对应的得分。下图是 M 端 LCP 的评分曲线：

m 示意中位数，图中 m 值为 0ms，示意当 LCP 值为 0ms 时，得 50 分；同理 p10 为 2520ms，LCP 值为 2529ms 时，得 90 分。设置 m 和 p10 后，会生成左边的评分曲线模型，依据该模型可以取得 LCP 值从 0 到正无量时的得分。

确立目的基线是为了给评分算法提供两个控制点，即 m 和 p10 的值。确立方法有三种：

确立基线环节中，招思索运行价值和研发要求的不同，依据运行个性，有针对性的设置。首先，PC 端和 M 端类型的运行，要设置不同的目的基线，所幸 Lighthouse 和 HTTP Archive 都提供 PC 端和 M 端的性能参考；其次，依据运行实践终端用户类型，有针对性的调整阈值。C 端和 B 端运行，间接发生业务价值，性能要求要比外部运行高，两控制点值应该更低。

经常使用加权平均算法计算运行性能分

依据目的 tp90 值、目的基线和评分算法，求得该目的的百分制得分。

经常使用加权平均算法求运行性能分，结果 = (Σ (目的tp90值 × 目的权重)) / (Σ 权重) ，其中：Σ 示意求和。

至于求各级组织，含团队、部门及公司的性能分，则依据其管辖的运行个数、运行性能分及运行权重，仍经常使用加权平均算法失掉组织分。流程如下：

求组织性能分的难点是：如何设置运行权重？咱们关键参考运行的 PV 区间和运行级别。PV 层级越大、运行级别越高，权重越大。详细性能参考如下：

PV区间中的PV 值指驳回 PV，而非实在 PV，驳回 PV=采集到 RUM 数据量/抽样比例。

经过上述步骤，咱们能取得运行性能分，以及各级组织的性能分，如团队性能分、部门性能分及之家性能分，展现成果如下：

性能分参考lighthouse规范，50分以上算合格，90分以上才算低劣。

经过页面性能监控和评判体系树立，咱们既有原始页面性能数据，又有聚合统计值，还有最终评分。经过评分、统计和原始数据，买通了发现、定位和剖析性能疑问的链路。研发同窗可以经过评分直观判别运行性能优劣能否须要优化？假设须要优化，再经过聚合统计数据，剖析运行瓶颈点；定位详细瓶颈点时，可以检查明细数据，辅佐剖析发生瓶颈点的详细要素；改良后可以经过经过统计检查优化成果，最终反映到提高评分上。

受限于篇幅，本文仅能引见页面性能监控和评判体系树立关系的通常。一个完整的页面性能监控系统，还应该蕴含：监控、报警、优化、控制等模块，不只仅只是目的，能度量页面性能，发现其中性能瓶颈点，协助研发同窗优化优化效率，还要治标，经过构建一系列前端工具链，改良交付环节，经过规范、工具和流程，从源头上提高页面交付品质，防止将疑问带到线上，先于用户发现性能疑问。

一个搜集和剖析网站性能数据的名目，旨在协助 Web 开发者了解互联网的技术趋向以及性能优化的最佳通常。