性能始终是宏大的话题，前面几讲我们或多或少都有涉及性能优化的各种方案。其实，除了传统的性能优化手段以外，我们还需要对性能进行把关，目的是在性能恶化时有所感知、有所防控。那么，一个性能守卫系统即性能监控系统究竟应该如何设计呢？
借助 Node.js 的能力，这一讲我们就下钻到 CI/CD 流程，设计一个性能守卫系统。希望通过这一讲的学习，你可以认识到：Node.js 除了同构直出、数据聚合以外，还能做一些重要的，且有趣的服务。
性能守卫理论基础
性能守卫的含义是：对每次上线进行性能把关，对性能恶化做到提前预警。它包含了一个性能监控平台，同时也需要给出更多的性能建议和指标建设。
那么我们如何感知到性能的好坏呢？我们对于 Load/DOMContentLoaded 事件、FP/FCP 指标已经耳熟能详了，下面我们再扩充几个更加现代化的指标。
- LCP（Largest Contentful Paint）
衡量页面的加载体验，它表示视口内可见的最大内容元素的渲染时间。相比 FCP，这个指标可以更加真实地反映具体内容加载速度。比如，如果页面渲染前有一个 loading 动画，那么 FCP 可能会以 loading 动画出现的时间为准，而 LCP 定义了 loading 动画加载后，真实渲染出内容的时间。
- FID（First Input Delay）
衡量可交互性，它表示用户和页面进行首次交互操作所花费的时间。它比 TTI（Time to Interact）更加提前，这个阶段虽然页面已经显示出部分内容，但并不能完全具备可交互性，对于用户的响应可能会有较大的延迟。
- CLS（Cumulative Layout Shift）
衡量视觉稳定性，表示页面的整个生命周期中，发生的每个意外的样式移动的所有单独布局更改得分的总和。所以这个分数当然越小越好。
以上是几个重要的、现代化的性能指标。结合我们传统的 FP/FCP/FMP 时间等，我们可以构建出一个相对完备的指标系统。这里我们就不再一一分析如何获取和收集这些性能指标了，相关内容社区上有不少文章。我们把目光放到更高层面，请你思考一下：如何从这些指标中，得到监控素材？
业界公认的监控素材主要由两方面提供：
- 真实用户监控（Real User Monitoring，RUM）
- 合成监控（Synthetic Monitoring，SYN）
真实用户监控是基于用户真实访问应用情况，在应用生命周期内计算产出性能指标，并进行上报。开发者拉取日志服务器上的指标数据，进行清洗加工，最终生成真实的访问监控报告。
真实用户监控一般搭配稳定的 SDK，会在一定程度上影响用户的访问性能，也给用户带来了额外的流量消耗。
合成监控是一种实验室数据，它指的是在某一个模拟场景中，通过工具，搭配规则和性能审计条目，得到一个合成的监控报告。
合成监控的优点比较明显，它的实现比较简单，有现成成熟的解决方案；如果搭配丰富的场景和规则，得到的数据类型也会较多。但它的缺点是数据量相对较小，且模拟条件配置相对复杂，无法完全反映真实场景。
而在 CI/CD pipeline 上，我们需要设计的性能守卫方案就是一种合成监控方案。在方案设计上，我们需要做到扬长避短。
Lighthouse 原理介绍
前文提到，合成监控有成熟的方案，比如 Lighthouse。我们的方案也基于 Lighthouse 进行，这里对 Lighthouse 原理进行介绍。
Lighthouse 是一个开源的自动化工具，它提供了四种使用方式，分别是：
- Chrome DevTools
- Chrome 插件
- Node cli
- Node module
我们先通过 Chrome DevTools 来迅速体验一下 Lighthouse。在 Audits 面板下，进行相关测试，可以得到一个网址的相关测试报告，内容如下图：
这个报告是如何得出的呢？我们先来看 Lighthouse 的架构图：
Lighthouse 架构图
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/60063.html