Lighthouse是一款开源的自动化工具，它能够帮助改善你的web应用程序的性能、质量和正确性。你可以在任何网页上运行它，无论是公开的还是需要认证的。

Lighthouse有一款Chrome扩展插件，也可以在Chrome DevTools中使用，或者作为Node模块来运行。输入你要审计的URL，Lighthouse将对页面运行一系列的审计。目前，Lighthouse除了在Chrome浏览器中有扩展插件外，还有火狐浏览器的扩展插件可供下载。

网页性能指标（Web Performance Metrics）是一种理解和改进网站体验的关键工具，这些体验直接影响真实用户。下面是一些重要的性能测量指标：

1. 最大内容绘制（Largest Contentful Paint，LCP）：这个指标量化了用户在页面初始加载时看到最大图像或文本块的时间。

良好的 LCP 得分是多少：
为了提供良好的用户体验，网站应努力将 Largest Contentful Paint 控制在 2.5 秒以内。为确保您的大多数用户都达到此目标，最好衡量一下网页加载的第 75 个百分位（按移动设备和桌面设备细分）。
根据 Largest Contentful Paint API 中当前的规定，Largest Contentful Paint 考虑的元素类型包括：
一个元素，带有使用 url() 函数（而不是 CSS 渐变）加载的背景图片
包含文本节点或其他内嵌级文本元素子元素的块级元素。
请注意，将元素限制在这一有限集合内是我们有意为之，目的是在开始时尽量简单。随着开展更多研究，未来可能会添加其他元素

除了仅考虑部分元素之外，LCP 衡量功能还会使用启发法来排除用户可能会认为“无内容”的特定元素。对于基于 Chromium 的浏览器，其中包括：

不透明度为 0 的元素，用户看不到这些元素
覆盖整个视口的元素可能被视为背景而非内容
占位符图片或其他低熵图片，可能无法反映网页的实际内容
浏览器可能会继续改进这些启发词语，以确保达到用户对最大的内容元素是什么的预期。

这些“内容性”启发式算法可能与 First Contentful Paint (FCP) 使用的启发法不同，后者可能会考虑其中部分元素（例如占位符图片或完整视口图片），即使它们不符合 LCP 候选条件也是如此。尽管两者的名称中都使用了“contentful”，但这两个指标的目的却不同。FCP 衡量的是任何内容绘制到屏幕上的时间，LCP 用于绘制主要内容，以便 LCP 更有选择性。

如何确定元素的大小？
针对 LCP 报告的元素尺寸通常是用户在视口内可见的尺寸。如果该元素延伸至视口之外，或者有任何元素被剪裁或存在不可见“溢出”，这些部分就不会计入元素的尺寸。overflow

对于根据固有尺寸调整过大小的图片元素，报告的尺寸为可见尺寸或固有尺寸（以较小者为准）。

对于文本元素，LCP 只会考虑能够包含所有文本节点的最小矩形。

对于所有元素，LCP 都不会考虑使用 CSS 应用的外边距、内边距或边

3. 累计布局偏移（Cumulative Layout Shift，CLS）：这个指标量化了页面在加载期间的所有意外的布局偏移。此指标可帮助开发人员理解用户对页面稳定性的感知。
良好的 CLS 得分是什么：
为了提供良好的用户体验，网站应努力使 CLS 得分不超过 0.1。为确保您的大多数用户都达到此目标，最好衡量一下网页加载的第 75 个百分位（按移动设备和桌面设备细分）。
布局偏移详情
布局偏移由 Layout Instability API 定义。只要视口内可见的元素在两帧之间更改起始位置（例如，写入模式中的顶部位置和左侧位置），该 API 就会报告 layout-shift 条目。此类元素被视为不稳定元素。

请注意，仅当现有元素更改其起始位置时，才会发生布局偏移。如果将新元素添加到 DOM 或现有元素更改了大小，只要此类更改不会导致其他可见元素更改其起始位置，系统便不会将其视为布局偏移。

布局偏移得分
为了计算“布局偏移得分”，浏览器会查看视口大小，以及视口中不稳定元素在两个渲染帧之间的移动情况。布局偏移分数是该移动两种衡量方式的乘积：影响分数和距离分数（两者的定义见下文）。

layout shift score = impact fraction * distance fraction
4. 交互至下一次绘制（Interaction to Next Paint，INP）：这个指标衡量的是用户与页面交互后，页面多久能绘制出一些反馈。
INP 得分是多少：
很难在响应能力指标上固定“良好”或“差”等标签。一方面，您需要鼓励优先考虑良好响应能力的开发实践。另一方面，您必须考虑这样一个事实，即人们用来设定实现预期开发期望的设备的功能有很大的差异。

为确保提供良好的响应速度的用户体验，最好衡量一下实际记录的网页加载的第 75 个百分位（按移动设备和桌面设备细分）：

INP 低于或等于 200 毫秒表示网页响应良好。
INP 高于 200 毫秒且低于或等于 500 毫秒表示网页的响应能力需要改进。
INP 高于 500 毫秒表示网页响应速度很差。

5. 首字节时间（Time to First Byte，TTFB）：这个指标衡量的是从请求发送到从服务器接收到第一个字节所花费的时间，这是一个网络响应期限的关键指标。
TTFB 得分是多少：
由于 TTFB 发生在以用户为中心的指标（例如首次内容绘制 (FCP) 和 Largest Contentful Paint (LCP)）之前，因此我们建议您的服务器足够快速地响应导航请求，以便第 75 百分位的用户遇到“良好”阈值内的 FCP。一般来说，大多数网站都应尽量将 TTFB 控制在 0.8 秒以内。

良好的 TTFB 值为 0.8 秒或更短，不良值大于 1.8 秒，两者之间的任何值都需要改进
良好的 TTFB 值为 0.8 秒或更短，不良值大于 1.8 秒。
要点：由于 TTFB 不是核心网页指标指标，因此网站并不是绝对必须具有出色的 TTFB，只要较长的 TTFB 不会使您的网站更难在重要指标上获得较高的得分。在优化加载时间时，请考虑您的网站传送内容的方式。如果某个网站快速提供初始标记，然后不得不等待脚本填充有意义的内容（如单页应用 [SPA] 通常就是这种情况），那么较低的 TTFB 尤为重要。另一方面，对于由服务器渲染的网站，不需要太多客户端工作，即使其 TTFB 更高，FCP 和 LCP 值也会比客户端渲染的网站更高。

6. 首次内容绘制（First Contentful Paint，FCP）：这个指标报告的是浏览器第一次渲染来自DOM的任何文本、图像、非白色canvas或SVG的时间。

FCP 得分良好是多少：
为了提供良好的用户体验，网站的 FCP 不得超过 1.8 秒。为确保您的大多数用户都能达到此目标，建议您衡量第 75 个百分位的网页加载情况（按移动设备和桌面设备细分）。
衡量 JavaScript 中的 FCP
如需在 JavaScript 中测量 FCP，请使用 Paint Timing API。以下示例展示了如何创建一个 PerformanceObserver，用于监听名为 first-contentful-paint 的 paint 条目并将其记录到控制台中。

new PerformanceObserver((entryList) => {for (const entry of entryList.getEntriesByName('first-contentful-paint')) {console.log('FCP candidate:', entry.startTime, entry);}}).observe({type: 'paint', buffered: true});

警告 ：此代码展示了如何将 first-contentful-paint 条目记录到控制台中。在 JavaScript 中衡量 FCP 则更为复杂。
在此示例中，记录的 first-contentful-paint 条目会告诉您第一个内容元素的绘制时间。不过，在某些情况下，此条目对衡量 FCP 无效。

以下部分列出了 API 报告的内容与指标计算方式之间的差异。

指标与 API 的区别
API 会为后台标签页中加载的网页分派 first-contentful-paint 条目，但在计算 FCP 时应忽略这些网页。只有当网页始终在前台运行时，系统才会考虑首次渲染时间。
从往返缓存中恢复网页时，API 不会报告 first-contentful-paint 条目，但在这些情况下，应衡量 FCP，因为用户将它们视为不同的网页访问。
API 可能不会报告跨源 iframe 的绘制时间，但为了正确衡量 FCP，您必须考虑所有帧。子帧可以使用该 API 将其绘制时间报告给父帧以进行汇总。
API 从导航启动时开始测量 FCP，但对于预渲染的网页，应通过 activationStart 测量 FCP，因为 FCP 对应于用户经历的 FCP 时间。
开发者可以使用 web-vitals JavaScript 库来衡量 FCP，而无需记住所有这些细微差异，该库会尽可能为您处理这些差异（iframe 中除外）：

import {onFCP} from 'web-vitals';// Measure and log FCP as soon as it's available.
onFCP(console.log);				

7. 总阻塞时间（Total Blocking Time，TBT）：这个是一个实验性的指标，它量化了在首次内容绘制（First Contentful Paint）和时刻可交互（Time to Interactive）之间，页面主线程被阻塞了多长时间。

TBT 得分是多少：
为了提供良好的用户体验，在普通移动硬件上测试网站时，网站的 TBT 应低于 200 毫秒。

如果您还想详细了解可以去https://web.dev/articles 搜索相关内容。

以上就是文章全部内容了，如果喜欢这篇文章的话，还希望三连支持一下，感谢！