本文深入探讨了前端性能优化，涵盖了网页生命周期、性能优化思路、优化方案以及Web性能关键指标，如FCP、LCP、FID、CLS等。同时，讲解了Core Web Vitals的重要性，并推荐了性能测试工具，如Lighthouse。
目录
5、Core Web Vitals 与 Web Vitals
1. 了解网页的生命周期
网站页面的生命周期，通俗地讲就是从我们在浏览器的地址栏中输入一个 URL 后，到整个页面渲染出来的过程。整个过程包括域名解析，建立 TCP 连接，前后端通过 HTTP 进行会话，压缩与解压缩，以及前端的关键渲染路径等，把这些阶段拆解开来看，不仅能容易地获得优化性能的启发，而且也能为今后的前端工程师之路构建出完整的知识框架，网站页面加载的生命周期如下图所示。
2. 如何进行web性能优化思路
（1）首先需要了解性能指标 - 多快才算快？
（2）使用专业的工具可量化地评估出网站或应用的性能表现；
（3）然后立足于网站页面响应的生命周期，分析出造成较差性能表现的原因；
（4）最后进行技术改造、可行性分析等具体的优化实施。
（5）迭代优化
3. 优化方案思路
- 从发出请求到收到响应的优化，比如 DNS 查询、HTTP 长连接、HTTP 2、HTTP 压缩、HTTP 缓存等。
- 关键渲染路径优化，比如是否存在不必要的重绘和回流。
- 加载过程的优化，比如延迟加载，是否有不需要在首屏展示的非关键信息，占用了页面加载的时间。
- 资源优化，比如图片、视频等，不同的格式类型会有不同的使用场景，在使用的过程中是否恰当。
- 构建优化，比如压缩合并、基于 webpack 构建优化方案等。
4. Web 性能指标（基于用户体验）
（1）First Contentful Paint（FCP）
FCP（First Contentful Paint）首次内容绘制，浏览器首次绘制来自 DOM 的内容的时间，内容必须是文本、图片（包含背景图）、非白色的 canvas 或 SVG，也包括带有正在加载中的 Web 字体的文本。
这是用户第一次开始看到页面内容，但仅仅有内容，并不意味着它是有用的内容（例如 Header、导航栏等），也不意味着有用户要消费的内容。
速度指标
优化方案
https://web.dev/fcp/#how-to-improve-fcp
（2）Largest Contentful Paint（LCP）
LCP（Largest Contentful Paint）最大内容绘制，可视区域中最大的内容元素呈现 到屏幕上的时间，用以估算页面的主要内容对用户可见时间。
LCP考虑哪些元素
<img>元素<image>元素内的<svg>元素<video>元素- 通过
url()函数加载背景图片的元素 - 包含文本节点或其他内联文本元素子级的块级元素。
为了提供良好的用户体验，网站应力争使用 2.5 秒或更短的“最大内容绘画” 。为确保您达到大多数用户的这一目标，衡量移动设备和台式机设备的页面加载量的第75个百分位数是一个很好的衡量标准。
示例
在以上两个时间轴中，最大的元素随内容加载而变化。在第一个示例中，新内容被添加到DOM中，并且更改了最大的元素。在第二个示例中，布局发生更改，以前最大的内容从视口中删除。
通常情况下，延迟加载的内容要比页面上已有的内容大，但不一定是这种情况。接下来的两个示例显示了在页面完全加载之前发生的最大内容绘画。
在第一个示例中，Instagram 徽标相对较早地加载，即使逐渐显示其他内容，它仍然是最大的元素。在 Google 搜索结果页面示例中，最大的元素是一段文本，该文本在任何图像或徽标加载完成之前显示。由于所有单个图像均小于此段，因此在整个加载过程中，它始终是最大的元素。
在 Instagram 时间轴的第一帧中，您可能会注意到相机徽标周围没有绿色框。那是因为它是一个<svg>元素，并且元素当前不被视为 LCP 候选对象。
速度指标
LCP较差的最常见原因是：
- 服务器响应时间慢
- 阻断渲染的
Javascript和CSS - 资源加载时间慢
- 客户端渲染
所以我们从上面的角度去考虑改善 LCP：
A、优化服务器
这个很好理解，浏览器从服务器接收内容所需的时间越长，则在屏幕上呈现任何内容所花费的时间就越长。更快的服务器响应时间可以直接改善包括 LCP 在内的所有页面加载指标。
衡量服务器相应时间有一个专门的指标：首字节相应时间（TTFB）是最初的网络请求被发起到从服务器接收到第一个字节这段时间，它包含了 TCP 连接时间，发送 HTTP 请求时间和获得响应消息第一个字节的时间。你可以尝试在下面几个方便优化 TTFB ：
- 缓存
HTML离线页面，缓存页面资源，减少浏览器对资源的请求。 - 尽量减小资源阻断渲染：
CSS和JavaScript压缩、合并、级联、内联等等 - 对图片进行优化。转化图片的格式为
JPG或者WEBP等等的格式，降低图片的大小，以加快请求的速度。 - 对
HTML重写、压缩空格、去除注释等。减少HTML大小，加快速度。 - 使用
preconnect尽快与服务器建立链接、使用dns-prefetch尽快进行DNS查找。 - 使用
CDN加快请求速度
B、优化阻断渲染的资源
JavaScript和CSS都是会阻断页面渲染的资源，需要尽可能的对CSS和JavaScript文件进行压缩、延迟加载首屏无需使用的JavaScript、内联关键的CSS等来减小阻断时间。
C、优化资源加载时间
刚才我们上面提到的这些资源，如果在首屏进行渲染，则加载这些元素所花费的时间将直接影响 LCP 。
<img>元素<image>元素内的<svg>元素<video>元素- 通过
url()函数加载背景图片的元素 - 包含文本节点或其他内联文本元素子级的块级元素。
你可以使用下面的手段进行优化：
- 对图片进行优化。转化图片的格式为
JPG或者WEBP等等的格式，降低图片的大小。 - 对重要的资源进行预加载，比如为
style标签添加rel="preload"属性 - 使用
Gzip和Brotli压缩页面资源，降低传输时间 - 使用
service worker缓存资源
D、服务端渲染
- 使用服务端渲染可以确保首先在服务器上呈现页面内容，可以有效改善
LCP，但是相比客户端渲染的缺点是会加大页面从而影响TTFB、服务端渲染需要等待所有 js 执行完毕后才能相应用户输入，这会使交互体验变差。
优化方案
参考网址：https://web.dev/optimize-lcp/
（3）First Input Delay（FID）
FID（First Input Delay）首次输入延迟，从用户第一次与页面交互（例如单击链接、点击按钮等）到浏览器实际能够响应该交互的时间。
输入延迟是因为浏览器的主线程正忙于做其他事情，所以不能响应用户。发生这种情况的一个常见原因是浏览器正忙于解析和执行应用程序加载的大量计算的 JavaScript。
第一次输入延迟通常发生在第一次内容绘制（FCP）和可持续交互时间（TTI）之间，因为页面已经呈现了一些内容，但还不能可靠地交互。
如上图所示，浏览器接收到用户输入操作时，主线程正在忙于执行一个耗时比较长的任务，只有当这个任务执行完成后，浏览器才能响应用户的输入操作。它必须等待的时间就此页面上该用户的 FID 值。
例如，以下所有 HTML 元素都需要在响应用户交互之前等待主线程上正在进行的任务完成：
- 文本输入框，复选框和单选按钮 （<input ><textarea>）
- 选择下拉菜单（<select>）
- 链接（<a>）
速度指标
优化方案
参考链接：
https://web.dev/fid/#how-to-improve-fid
（4）Time to Interactive（TTI）
表示网页第一次完全达到可交互状态的时间点，浏览器已经可以持续性的响应用户的输入。完全达到可交互状态的时间点是在最后一个长任务（Long Task）完成的时间, 并且在随后的 5 秒内网络和主线程是空闲的。
速度指标
优化方案
参考链接：https://web.dev/tti/#how-to-improve-tti
（5）Total Block Time（TBT）
Total Block Time（TBT）总阻塞时间，度量了 FCP 和 TTI 之间的总时间，在该时间范围内，主线程被阻塞足够长的时间以防止输入响应。
只要存在长任务，该主线程就会被视为“阻塞”，该任务在主线程上运行超过50毫秒（ms）。我们说主线程“被阻止”是因为浏览器无法中断正在进行的任务。因此，如果用户确实在较长的任务中间与页面进行交互，则浏览器必须等待任务完成才能响应。
如果任务足够长（例如，超过50毫秒的任何时间），则用户很可能会注意到延迟并感觉页面缓慢或过时。
给定的长任务的阻止时间是其持续时间超过50毫秒。页面的总阻塞时间是FCP和TTI之间发生的每个长任务的阻塞时间的总和。
例如，考虑页面加载期间浏览器主线程的下图：
上面的时间轴有五个任务，其中三个是长任务，因为它们的持续时间超过50毫秒。下图显示了每个长任务的阻塞时间：
因此，虽然在主线程上运行任务花费的总时间为560毫秒，但只有345毫秒的时间被视为阻塞时间。
速度指标
优化方案：
https://web.dev/tbt/#how-to-improve-tbt
（7）Cumulative Layout Shift（CLS）
Cumulative Layout Shift（CLS）累计布局偏移，CLS 会测量在页面整个生命周期中发生的每个意外的布局移位的所有单独布局移位分数的总和，它是一种保证页面的视觉稳定性从而提升用户体验的指标方案。
您是否曾经在页面上突然发生变化时在没有警告的情况下，文字移动了，并且您失去了位置。甚至更糟：您将要点击一个链接或一个按钮，但是在手指落下的瞬间，链接移动了，您最终单击了其他东西！
页面内容的意外移动通常是由于异步加载资源或将 DOM 元素动态添加到现有内容上方的页面而发生的。罪魁祸首可能是尺寸未知的图像或视频，呈现比其后备更大或更小的字体，或者是动态调整自身大小的第三方广告或小部件。
速度指标
优化方案
https://web.dev/cls/#how-to-improve-cls
（8）Speed Index
Speed Index（速度指数）是一个表示页面可视区域中内容的填充速度的指标，可以通过计算页面可见区域内容显示的平均时间来衡量。
测量方式
捕获浏览器加载页面过程的视频，然后对每 100ms 间隔的页面截图计算页面内容填充的百分比，可以得到这样一个曲线。
图中的 Example 1 和 Example 2 都是在 10s 时页面填充完成，但 Example 1 在 2s 时就已经填充了 80% 的内容，而 Example 2 在 8s 时才填充 80%。
图中阴影部分的面积（即时间-内容填充百分比曲线以上部分）的大小即可表示可视区域内页面内容的填充速度，面积越小，填充速度越快。
速度指标
优化方案
https://web.dev/speed-index/#how-to-improve-your-speed-index-score
5、Core Web Vitals 与 Web Vitals
什么是 Web Vitals，Google 给出的定义是 一个良好网站的基本指标（Essential metrics for a healthy site），过去要衡量一个网站的好坏，需要使用的指标太多了，Web Vitals 可以简化指标的学习曲线，只需聚焦于 Web Vitals 指标的表现即可。
在这些 Web Vitals 中，Google 确定了三个主要衡量指标，即在所有类型的网站中通用的 Core Web Vitals：
Core Web Vitals 是应用于所有 Web 页面的 Web Vitals 的子集，是其最重要的核心。
- 加载性能（LCP） — 显示最大内容元素所需时间
- 交互性（FID） — 首次输入延迟时间
- 视觉稳定性（CLS） — 累积布局配置偏移
测量 Web Vitals
- 性能测试工具，比如 Lighthouse
- 使用 web-vitals 库
- 使用浏览器插件 Web Vitals（https://www.extfans.com/web-development/ahfhijdlegdabablpippeagghigmibma/）
6、性能测试工具
性能检测的认知
性能检测作为性能优化过程中的一环，它的目的通常是给后续优化工作提供指导方向、参考基线及前后对比的依据。性能检测并不是一次性执行结束后就完成的工作，它会在检测、记录和改进的迭代过程中不断重复，来协助网站的性能优化不断接近期望的效果。
在展开介绍性能检测的方法和工具之前，我们首先需要破除有关性能的一些错误认知与理解偏差。
（1）不要通过单一指标就能衡量网站的性能体验。这是完全站在用户感知的角度上产生的认知，它只会有主观上的好与差，很难给出切实可行的优化建议。因此我们建议应当从更多维度、更多具体的指标角度来考量网站应用的性能表现，比如页面的首屏渲染时间，不同类型资源的加载次数与速度，缓存的命中率等。
（2）不要一次检测就能得到网站性能表现的客观结果。网站应用的实际性能表现通常是高度可变的，因为它会受到许多因素的影响，比如用户使用的设备状况、当前网络的连接速度等，因此若想通过性能检测来得到较为客观的优化指导，就不能仅依赖一次检测的数据，而需要在不同环境下收集尽量多的数据，然后以此来进行性能分析。
（3）不要仅在开发环境中模拟进行性能检测。在开发环境中模拟进行的性能检测具有许多优势：比如可以很方便地制定当前检测的设备状况与网络速度，可以对检测结果进行重复调试，但因其所能覆盖的场景有限，会很容易陷入“幸存者偏差”，即所发现的问题可能并非实际的性能瓶颈。
据此可知，我们若想通过检测来进行有效的性能优化改进，就需要从尽可能多的角度对网站性能表现进行考量，同时保证检测环境的客观多样，能够让分析得出的结果更加贴近真实的性能瓶颈，这无疑会花费大量的时间与精力，所以在进行性能优化之前我们还需要考虑所能投入的优化成本。
常见的检测工具
- Lighthouse
- WebPageTest
- 浏览器 DevTools
- 浏览器任务管理器
- Network 面板
- Coverage 面板
- Memory 面板
- Performance 面板
- Performance monitor 面板
- 性能监控 API
- 持续的性能监控方案
下一篇博客介绍：前端性能测试工具之【Lighthouse】
扫一扫
3038
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
