什么是web性能

Web 性能就是让网站变得更快，以及让缓慢过程看起来更快。网站加载速度是否很快，是否允许用户快速开始与之交互，是否在某些东西需要时间加载时提供可靠的反馈（例如，一个“加载中”的旋转指示器）。减少网站的下载和渲染时间可以提高转化率和用户留存。可能你的网站没有办法变得更快，但至少也应该让用户能有快速的交互感知。

Web 性能是对网站或应用程序的客观度量和用户的体验。这包括以下主要方面：

• 减少整体加载时间：减小文件体积、减少HTTP请求、使用预加载
• 使网站尽快可用：仅加载首屏内容，其他内容根据需要再进行懒加载
• 流畅性和交互性：使用css代替JS动画、减少UI重绘
• 感知表现：你的页面可能无法做的更快，但你可以让用户感觉更快。耗时操作要给用户反馈，比如加载动画、进度条、骨架屏等提示信息。
• 性能测试：性能指标、性能测试、性能监控持续优化。Web 性能包括测量应用程序的实际速度和感知速度，在可能的情况下进行优化，然后监视性能，以确保已经优化过的内容保持优化状态。

检验网站性能的手段

RAIL 模型衡量性能

RAIL 是一种以用户为中心的性能模型，它提供了一种考虑性能的结构。该模型将用户体验分解到按键操作（例如，点击、滚动、加载）中，帮助您为每个操作定义性能目标。

将用户作为性能工作的关键点。下表介绍了用户如何感知性能延迟的关键指标：

用户对性能延迟的看法

0 至 16 毫秒	用户非常关注轨迹运动，他们不喜欢不流畅的动画。如果每秒渲染 60 个新帧，他们就认为动画很流畅。也就是说，每一帧只有 16 毫秒时间，这包括浏览器将新帧绘制到屏幕所需的时间，因而应用约有 10 毫秒的时间来生成一个帧。
0 到 100 毫秒	在此时间窗口内响应用户操作会让用户觉得结果是即时呈现的。如果时间更长，操作与用户反应之间的联系就会中断。
100 到 1000 毫秒	在此时间窗口内，用户会觉得任务进展基本上是自然连续的。对 Web 上的大多数用户来说，加载页面或更改视图是一项任务。
1000 毫秒或更长	超过 1000 毫秒（1 秒），用户的注意力就会从正在执行的任务上转移。
10000 毫秒或更长	超过 10000 毫秒（10 秒），用户会感到失望，并且可能放弃任务。他们以后可能会回来，也可能不会再回来。

了解性能关键指标

FCP – 首次内容绘制

首次内容绘制(FCP)是英文 First Contentful Paint 简写。
该指标测量页面从开始加载到页面内容的任何部分在屏幕上完成渲染的时间。对于该指标，”内容”指的是文本、图像（包括背景图像）、<svg>元素或非白色的<canvas>元素。

在上方的加载时间轴中，FCP 发生在第二帧，因为那是首批文本和图像元素在屏幕上完成渲染的时间点。
您会注意到，虽然部分内容已完成渲染，但并非所有内容都已经完成渲染。这是首次内容绘制 (FCP) 与*Largest Contentful Paint 最大内容绘制 (LCP)*（旨在测量页面的主要内容何时完成加载）之间的重要区别。

怎样算是良好的 FCP 分数？

为了提供良好的用户体验，网站应该努力将首次内容绘制控制在1.8 秒或以内。为了确保您能够在大部分用户的访问期间达成建议目标值，一个良好的测量阈值为页面加载的第 75 个百分位数，且该阈值同时适用于移动和桌面设备。

如何改进 FCP 

要了解如何改进某个特定网站的 FCP，您可以运行一次灯塔性能审计，并留心查看审计建议的具体信息。

要了解改进 FCP 的常见方式（针对任何网站），请参阅以下性能指南：

• 消除阻塞渲染的资源
• 缩小 CSS
• 移除未使用的 CSS
• 预连接到所需的来源
• 减少服务器响应时间 (TTFB)
• 避免多个页面重定向
• 预加载关键请求
• 避免巨大的网络负载
• 使用高效的缓存策略服务静态资产
• 避免 DOM 过大
• 最小化关键请求深度
• 确保文本在网页字体加载期间保持可见
• 保持较低的请求数和较小的传输大小

LCP – 最大内容绘制

参考文章：web.dev/lcp/

最大内容绘制 (LCP)，英文Largest Contentful Paint 简写。指标会根据页面首次开始加载的时间点来报告可视区域内可见的最大图像或文本块完成渲染的相对时间。

怎样算是良好的 LCP 分数？

为了提供良好的用户体验，网站应该努力将最大内容绘制控制在2.5 秒或以内。为了确保您能够在大部分用户的访问期间达成建议目标值，一个良好的测量阈值为页面加载的第 75 个百分位数，且该阈值同时适用于移动和桌面设备。

哪些元素在考量范围内？

根据当前最大内容绘制 API中的规定，最大内容绘制考量的元素类型为：

• <img>元素
• 内嵌在<svg>元素内的<image>元素
• <video>元素（使用封面图像）
• 通过url()函数（而非使用CSS 渐变）加载的带有背景图像的元素
• 包含文本节点或其他行内级文本元素子元素的块级元素。

请注意，为了在初始阶段保持简洁，我们有意将元素限制在这几个有限的类型中。随着研究的深入，未来可能会添加其他元素（例如<svg> 、 <video>）。

如何确定一个元素的大小？

报告给最大内容绘制的元素大小通常是用户在可视区域内可见的大小。如果有元素延伸到可视区域之外，或者任何元素被剪裁或包含不可见的溢出，则这些部分不计入元素大小。

对于在原始尺寸之上经过调整的图像元素，报告给指标的元素大小为可见尺寸或原始尺寸，以尺寸较小者为准。例如，远小于其原始尺寸的缩小图像将仅报告图像的显示尺寸，而拉伸或放大成更大尺寸的图像将仅报告图像的原始尺寸。

对于文本元素，指标仅考量其文本节点的大小（包含所有文本节点的最小矩形）。

对于所有元素，通过 CSS 设置的任何边距、填充或边框都不在考量范围内。

如何改进 LCP

LCP 主要受四个因素影响：

• 缓慢的服务器响应速度
• JavaScript 和 CSS 渲染阻塞
• 资源加载时间
• 客户端渲染

如需深入了解如何改进 LCP，请参阅优化 LCP。有关其他能够改进 LCP 的单个性能技巧的进一步指导，请参阅：

• 使用 PRPL 模式做到即时加载
• 优化关键渲染路径
• 优化您的 CSS
• 优化您的图像
• 优化网页字体
• 优化您的 JavaScript（针对客户端渲染的网站）

FID – 首次输入延迟

参考文案：web.dev/fid/

FID（First Input Delay） 测量从用户第一次与页面交互（例如当他们单击链接、点按按钮或使用由 JavaScript 驱动的自定义控件）直到浏览器对交互作出响应，并实际能够开始处理事件处理程序所经过的时间。

怎样算是良好的 FID 分数？

为了提供良好的用户体验，网站应该努力将首次输入延迟设控制在100 毫秒或以内。为了确保您能够在大部分用户的访问期间达成建议目标值，一个良好的测量阈值为页面加载的第 75 个百分位数，且该阈值同时适用于移动和桌面设备。

如何改进 FID 

要了解如何改进某个特定网站的 FID，您可以运行一次灯塔性能审计，并留心查看审计建议的各种具体机会。

虽然 FID 是一项实际指标（而灯塔是一个实验室指标工具），但改进 FID 的指导方向与改进总阻塞时间 (TBT)这项实验室指标的指导方向相同。

如需深入了解如何改进 FID，请参阅优化 FID。有关其他能够改进 FID 的单个性能技巧的进一步指导，请参阅：

• 减少第三方代码的影响
• 减少 JavaScript 执行时间
• 最小化主线程工作
• 保持较低的请求数和较小的传输大小

TTI – 可交互时间

参考文案：web.dev/tti/

TTI(Time to Interactive) 指标测量页面从开始加载到主要子资源完成渲染，并能够快速、可靠地响应用户输入所需的时间。

怎样算是良好的 TTI 分数？

为了提供良好的用户体验，网站在普通移动硬件上进行测试时，应该努力将可交互时间控制在5 秒以内。

有关页面 TTI 对灯塔性能分数影响的详细信息，请参阅灯塔如何确定您的 TTI 分数。

如何改进 TTI

如需了解如何改进某个特定网站的 TTI，您可以运行一次灯塔性能审计，并留心查看审计建议的各种具体机会。

如需了解改进 TTI 的常见方式（针对任何网站），请参阅以下性能指南：

• 缩小 JavaScript
• 预连接到所需的来源
• 预加载关键请求
• 减少第三方代码的影响
• 最小化关键请求深度
• 减少 JavaScript 执行时间
• 最小化主线程工作
• 保持较低的请求数和较小的传输大小

TBT – 总阻塞时间

参考文案：web.dev/tbt/

TBT（Total Blocking Time）指标测量
First Contentful Paint 首次内容绘制 (FCP) 与 Time to Interactive 可交互时间 (TTI) 之间的总时间，这期间，主线程被阻塞的时间过长，无法作出输入响应。

每当出现长任务（在主线程上运行超过 50 毫秒的任务）时，主线程都被视作”阻塞状态”。我们说主线程处于”阻塞状态”是因为浏览器无法中断正在进行的任务。因此，如果用户在某个长任务运行期间与页面进行交互，那么浏览器必须等到任务完成后才能作出响应。

如果任务时长足够长（例如超过 50 毫秒），那么用户很可能会注意到延迟，并认为页面缓慢或卡顿。

某个给定长任务的阻塞时间是该任务持续时间超过 50 毫秒的部分。一个页面的总阻塞时间是在 FCP 和 TTI 之间发生的每个长任务的阻塞时间总和。

例如，请看以下这张页面加载期间浏览器主线程的图表：

上方的时间轴上有五个任务，其中三个是长任务，因为这些任务的持续时间超过 50 毫秒。下图显示了各个长任务的阻塞时间：

因此，虽然在主线程上运行任务的总时间为 560 毫秒，但其中只有 345 毫秒被视为阻塞时间。

	任务持续时间	任务阻塞时间
任务一	250 毫秒	200 毫秒
任务二	90 毫秒	40 毫秒
任务三	35 毫秒	0 毫秒
任务四	30 毫秒	0 毫秒
任务五	155 毫秒	105 毫秒
总阻塞时间	345 毫秒

怎样算是良好的 TBT 分数？ #

为了提供良好的用户体验，网站在普通移动硬件上进行测试时，应该努力将总阻塞时间控制在300 毫秒以内。

有关页面 TBT 对灯塔性能分数影响的详细信息，请参阅灯塔如何确定您的 TBT 分数

如何改进 TBT #

如需了解如何改进某个特定网站的 TBT，您可以运行一次灯塔性能审计，并留心查看审计建议的各种具体机会。

如需了解改进 TBT 的常见方式（针对任何网站），请参阅以下性能指南：

• 减少第三方代码的影响
• 减少 JavaScript 执行时间
• 最小化主线程工作
• 保持较低的请求数和较小的传输大小

CLS – 累计布局偏移

参考文案：web.dev/cls/

避免内容出现较大偏移，影响用户体验。

CLS（Cumulative Layout Shift）测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。

每当一个可见元素的位置从一个已渲染帧变更到下一个已渲染帧时，就发生了布局偏移 。（有关单次布局偏移分数计算方式的详细信息，请参阅下文。）

一连串的布局偏移，也叫*会话窗口*，是指一个或多个快速连续发生的单次布局偏移，每次偏移相隔的时间少于 1 秒，且整个窗口的最大持续时长为 5 秒。

最大的一连串是指窗口内所有布局偏移累计分数最大的会话窗口。

什么是 CLS？ #

CLS 测量整个页面生命周期内发生的所有意外布局偏移中最大一连串的布局偏移分数。

每当一个可见元素的位置从一个已渲染帧变更到下一个已渲染帧时，就发生了布局偏移 。（有关单次布局偏移分数计算方式的详细信息，请参阅下文。）

一连串的布局偏移，也叫*会话窗口*，是指一个或多个快速连续发生的单次布局偏移，每次偏移相隔的时间少于 1 秒，且整个窗口的最大持续时长为 5 秒。

最大的一连串是指窗口内所有布局偏移累计分数最大的会话窗口。

怎样算是良好的 CLS 分数？ #

为了提供良好的用户体验，网站应该努力将 CLS 分数控制在0.1 或以下。为了确保您能够在大部分用户的访问期间达成建议目标值，一个良好的测量阈值为页面加载的第 75 个百分位数，且该阈值同时适用于移动和桌面设备。

如何改进 CLS

对于大多数网站来说，您可以通过遵循一些指导原则来避免所有的意外布局偏移：

• **始终在您的图像和视频元素上包含尺寸属性，或者通过使用CSS 长宽比容器之类的方式预留所需的空间。**这种方法可以确保浏览器能够在加载图像期间在文档中分配正确的空间大小。请注意，您还可以使用unsized-media 功能策略在支持功能策略的浏览器中强制执行此行为。
• **除非是对用户交互做出响应，否则切勿在现有内容的上方插入内容。**这样能够确保发生的任何布局偏移都在预期之内。
• **首选转换动画，而不是触发布局偏移的属性动画。**动画过渡的目标是提供状态与状态之间的上下文连续性。

如需深入了解如何改进 CLS，请参阅优化 CLS和调试布局偏移。

了解 Web Vitals

上面我们介绍了很多性能检测指标，而web-vitals是Google发起的，旨在提供各种质量信号的统一指南，我们相信这些质量信号对提供出色的网络用户体验至关重要。多年来，Google 提供了许多性能测量和性能报告工具。一些开发者对这些工具的使用十分在行，而另一些开发者则发现大量的工具和指标令人应接不暇。

总之，Web Vitals则是希望提出一些标准，来帮助开发者去测量，优化页面，给到用户更好的体验。

Web Vitals 只要求重点关注LCP，FID，CLS这三个指标。而非上诉六大指标。

• Largest Contentful Paint (LCP)  ：最大内容绘制，测量加载性能。为了提供良好的用户体验，LCP 应在页面首次开始加载后的2.5 秒内发生。
• First Input Delay (FID)  ：首次输入延迟，测量交互性。为了提供良好的用户体验，页面的 FID 应为100 毫秒或更短。
• Cumulative Layout Shift (CLS)  ：累积布局偏移，测量视觉稳定性。为了提供良好的用户体验，页面的 CLS 应保持在 0.1.  或更少。

指标测量工具

Chrome DevTools – 测量工具

Lighthouse 灯塔 – 测量工具

Lighthouse 是一个由google开发并开源的web性能测试工具。
打开一个网址，即可进行测试，然后生成页面相关的性能报告。

• 使用方式1

在浏览器应用商店安装 Lighthouse，点击 Gennerate report 即可开始检测

• 方式2

F12 开发者工具中自带Lighthouse

• 方式3

npm安装cli

npm install -g lighthouse

• 执行命令，命令参数文档查看：github.com/GoogleChrom…

lighthouse https://www.example.com --view

查看报告

运行Lighthouse检测后，进入以下等待界面

报告中会显示以下指标数据，并提出一些优化建议：

• FCP-反映的是从页面开始加载到页面视口上最大的图片或者文本块渲染的时间。
• LCP-最大内容绘制，用于监控网页可视区内“绘制面积”最大的元素开始呈现在屏幕上的时间点。
• TBT-测量首次内容绘制 (FCP)首次内容绘制和 (TTI)之间的总时间，这期间，主线程被阻塞的时间过长，无法作出输入响应。
• CLS-反映网页布局在加载期间的偏移量。得分范围是 0–1，其中 0 表示没有偏移，1 表示最大偏移。
• Speed Index-页面内容可见填充的速度。
• TTI-反映从页面加载开始到页面处于完全可交互状态所花费的时间。
  

WebPageTest 网页性能测试工具

www.webpagetest.org/

开始检测

输入要测试的网址，选择桌面端，点击开始，即可检查网站

检测报告

查看更多

还能选择非常多的报告

PageSpeed Insights 网页性能测试工具

pagespeed.web.dev/

• 网站性能指标信息
  

• 网站优化建议
  

• 无障碍阅读体验

优化手段

整理中…

参考文案

• RAIL 模型衡量性能
• 衡量性能与用户体验指标