大家好，我是双越老师，也是 wangEditor 作者。
我正致力于开发一个 Node 全栈 AIGC 知识库 划水AI，包括 AI 写作、多人协同编辑。复杂业务，真实上线，大家可以去注册试用，围观项目研发过程。
我在给很多同学评审简历的时候，一问性能优化如何统计、如何量化？都答不好，不知道怎么统计。
正好，近期我把 划水AI 项目接入到了 Sentry 进行错误监控和性能监控，并记录解释了接入的过程，和一些图表数据的结果。
本文就分享一下前端性能统计中最重要的一些数据 Google Web Vitals ，结合 划水AI 项目的性能统计结果。
Web Vitals 是什么
Web Vitals 是一系列的数据，用于衡量一个网页加载性能的体验如何，即网页性能监控的关键数据。
它主要包含如下数据。前 3 个体现首屏加载和渲染速度，后 3 个体现用户使用和交互的体验。
- Time to First Byte (TTFB) 第一字节时间
- First Contentful Paint (FCP) 首次内容绘制
- Largest Contentful Paint (LCP) 最大内容绘制
- First Input Delay (FID) 首次输入延迟
- Cumulative Layout Shift (CLS) 累积布局偏移
- Interaction to Next Paint (INP) 下次绘制交互
TTFB
Time to First Byte 第一字节时间。
是指从浏览器请求页面到接收来自服务器发送的信息的第一个字节的时间。这包括 DNS 查询和使用 TCP 握手建立连接的时间。如果请求是通过 HTTPS 发出的，则还包括 TLS 握手建立连接的时间。
如果网络环境没问题，TTFB 一般在 100ms 左右。所以它可以反映出一个 web 系统网络环境的快慢。
例如现在 划水AI 是部署在海外服务器的，在国内访问因为距离太远，网络环境比较差，所以 TTFB 时间较多，需要 2.3s —— 这是目前的性能瓶颈 —— 但这是网络原因，不是我们代码的问题。
后面如果把服务部署到国内，就不会有这个问题了。网络是优化的第一要素，其次再是资源压缩、I/O 瓶颈等。
FCP
First Contentful Paint 首次内容绘制。
是指浏览器渲染 DOM 中的第一部分内容，向用户提供页面正在加载的第一次反馈的时间。
首次内容绘制时间戳是指浏览器首次渲染任何文本、图像（包括背景图像）、视频、已绘制的画布或非空 SVG 的时间。这不包括任何 iframe 的内容，但包括待加载 Web 字体的文本。这是用户可以开始查看页面内容的时间。
FCP 一般控制在 1s 之内是比较合理的。从上图看，划水AI 的 FCP 因为 TTFB 的原因而成绩是 2.68s 。如果 TTFB 优化好了，那 FCP 肯定会小于 1s 的。
LCP
Largest Content Paint 最大内容绘制
报告视口中可见的最大图片、文本块或视频的渲染时间（相对于用户首次导航到网页的时间）。
为了提供良好的用户体验，网站应尽量将 Largest Contentful Paint 控制在 2.5 秒或更短的时间内。为确保大多数用户都能达到此目标值，一个合适的衡量阈值是网页加载时间的第 75 个百分位数，并按移动设备和桌面设备进行细分。
从 FCP 到 LCP 的渲染过程，两个例子
划水AI 的 LCP 成绩是 3s ，即便有 TTFB 如此拉后腿（网络原因），都可以达到 3s 这样一个可接受的成绩，也是不容易。
FID
First Input Delay 首次输入延迟。
用于衡量从用户首次与网页互动（即点击链接、点按按钮或使用由 JavaScript 提供支持的自定义控件）到浏览器实际能够开始处理事件处理脚本以响应该互动的时间。
为了提供良好的用户体验，网站应尽量将首次输入延迟时间控制在 100 毫秒以内。为确保大多数用户都能达到此目标值，一个合适的衡量阈值是网页加载时间的第 75 个百分位数，并按移动设备和桌面设备进行细分。
CLS
Cumulative Layout Shift 累积布局偏移。
意外的布局偏移可能会以多种方式干扰用户体验，例如，如果文本突然移动，会导致用户在阅读时迷失位置，或者导致用户点击错误的链接或按钮。在某些情况下，这可能会造成严重损害。
当资源异步加载或 DOM 元素在现有内容之前动态添加到网页时，网页内容通常会意外移动。布局偏移的原因可能是尺寸未知的图片或视频、比初始后备字体大或小的呈现字体，或者会自行调整大小的第三方广告或 widget。
划水AI 页面非常简洁，也没有第三方的插件和广告，所以 CLS 成绩非常好 Good 100 分。
INP
Interaction to Next Paint 下次绘制交互。
即网页的响应速度。良好的响应能力意味着网页对互动做出快速响应。当网页响应互动时，浏览器会在其绘制的下一帧中提供视觉反馈。例如，视觉反馈会告诉您是否确实添加了您添加到在线购物车中的商品、移动导航菜单是否打开、服务器是否正在对登录表单的内容进行身份验证等。
有些互动的用时自然要比其他互动长，但对于特别复杂的互动，必须快速显示一些初始视觉反馈，让用户知道正在发生某件事。浏览器要绘制的下一帧是最早执行此操作的机会。
划水AI 基于 React 开发，我们也做了大量的体验优化，因此 INP 成绩是 64ms ，Good 99 分。
如何测试 Web Vitals
Sentry
Sentry 查看 Web Vitals 是需要付费的，每月 20-30 美元。当然你也可以自己弄服务器部署一个私有的 Sentry 服务，网上也有教程，就是麻烦一些。
这是 划水AI 项目的性能测试报告（不同时间截图的，数据会有点差异），测试结果非常清晰
可以看到目前的性能瓶颈在于 TTFB Time to First Byte ，这是因为 划水AI 目前用的是海外服务器，所以国内访问网络连接会比较慢。除了 TTFB 其他的性能数据都是 OK 的。
所以，前端性能优化更多的还是在于网络环境，前端那些压缩资源、懒加载都是次要的，只要你的资源不是特别大，其实压缩不压缩的响应不了太多。
Lighthouse
可以在 Chrome 安装 Lighthouse 插件 chromewebstore.google.com/detail/ligh…
但 Lighthouse 只是我自己本地的性能测试，和自己的网络情况有很大关系，其他人的性能体验是看不到的。
然后启动 Lighthouse 检测 划水AI 网站，结果如下
由于海外服务器的原因，TTFB 比较耗时，这和 Sentry 展示的一样。
我再次重新分析，测试结果就比较好了，可能是有本地缓存的原因。
JS 插件
可以使用 web-vitals JS 插件，来获取 web vitals ，它也有相应的 npm 包 www.npmjs.com/package/web…
Nextjs 框架内部集成了 web vitals 功能，文档参考 nextjs.org/docs/app/bu…
这是我自己本地的测试数据，本地不涉及线上网络问题，所以性能都非常好。
总结
我在给很多同学评审简历的时候，一问性能优化如何统计、如何量化？都答不好。其实本文就是一个参考答案。
项目的性能可以有好有坏，因为有不同的线上环境。但你作为技术人员必须要知道如何统计和监控，如何发现性能瓶颈，如何去解决这个问题。
有兴趣的同学可以加入 划水AI 项目，亲身体验真实项目的统计和监控经验。
