海外投放必须知了解：谷歌搜索&Core Web Vitals

叶知秋水
330 阅读24分钟

本文主要协助理解您的应用在Google页面体验排名和Lighthouse评分。

核心网页指标（Core Web Vitals）影响您的应用在Google搜索中的排名。在这里，我们将深入探讨这些指标是什么，它们如何被测量，以及它们如何影响您的用户和搜索排名。

谷歌的排名规则

您的网站在Google搜索中的排名受到页面体验排名系统的影响，该系统根据核心网页指标评估网站性能。Google通过观察真实用户与您网站的互动来收集核心网页指标数据，并将其报告给服务器。

我们称这种类型的数据为现场数据，因为它是从真实用户浏览您的网站时收集的。这与实验室数据不同，后者是通过在“实验室环境”中运行的测试结果来确定您的网站性能的好坏。Google的Lighthouse就是一个实验室测试的例子。

也许本文最重要的一点是：

Google在排名您的网站时只考虑核心网页指标的现场数据。Google不会考虑您的Lighthouse得分。

搜索排名因素的背景

页面体验是Google搜索中的一个排名因素，利用核心网页指标来确定您网站相对于其他网站的表现。页面体验只是Google搜索中的众多排名因素之一，所有这些因素综合在一起决定了您网站在搜索结果页面上的排名。

与查询的相关性和内容质量相比，页面体验是更重要的因素。然而，在您和竞争对手相关性相似的情况下，页面体验可能决定谁排名更高。

页面体验和核心网页指标的独特之处在于：

  • 您可以通过自己的努力改善这些指标。
  • Google对您的表现透明。

核心网页指标比其他排名因素更少有不确定性。优化它们涉及的“猜测”较少，比提高相关性更容易测量。

此外，改善核心网页指标可以改善用户体验，从而提高转化率。

如何查看应用的核心网页指标

Google搜索控制台是查看整个应用页面体验排名表现的权威数据来源。

Screenshot-2024-01-18-at-7.png

此外，也可以通过这个工具PageSpeed Insights去测试：pagespeed.web.dev/

iShot_2024-07-02_10.04.10.png

iShot_2024-07-02_10.03.56.png

现场数据：核心网页指标

在PageSpeed Insights的顶部部分，标有“了解您的真实用户体验”的区域，Google收集了来自Chrome浏览器（桌面和安卓设备）用户的全球现场数据。这些数据包括最大内容绘制（LCP）、下一次绘制交互（INP）和累计布局偏移（CLS），这些指标直接影响您的应用排名。

请注意，从2024年3月12日起，INP取代了首次输入延迟（FID）。

这三个核心网页指标是Google用来根据网页性能影响您的应用排名的唯一数据，Google使用的正是这些分数，尽管它们是与您应用上性能相似的页面平均得出的。

您还会注意到，有桌面和移动设备的标签。这是因为Google根据移动和桌面版本分别对您的应用进行排名。

核心网页指标现场数据包含哪些用户？

Chrome用户体验报告（CrUX）是Google核心网页指标计划的官方数据集，其收集方法是公开记录的。需要注意的是，要被包含在报告中：

  • 页面必须“足够受欢迎”和“公开可发现”。您可以通过搜索控制台中的CWV报告确定您的页面是否符合受欢迎程度的阈值。
  • 用户必须启用使用统计报告、同步浏览器历史记录（登录到Chrome），并且不设置同步密码短语。
  • 用户必须在桌面或安卓设备上使用Chrome。

最后一点意味着您的iPhone用户不会被计算在内。这在某些市场可能很重要，因为安卓手机的速度通常比iPhone慢，因此可能会有更多较慢的访问被计算在内。

如果您的应用没有足够的真实用户数据，那么您的核心网页指标将无法被测量，也不会在排名中被考虑。

用户来自哪里重要吗？

另一个常见问题是：用户来自哪里重要吗？如果我的用户主要来自互联网连接较慢的国家，我会被惩罚吗？

用户来自哪里确实重要。现场数据反映了您的真实用户，所有全球地区的用户都被平等计入。

好消息是，全球互联网连接和设备性能都在改善，通过像Vercel这样的边缘网络，您可以为全球每个用户提供出色的性能。

28天滑动窗口

Google在一个28天滑动窗口内收集核心网页指标数据。您的分数基本上是过去28天的平均分。如果您做了改进或恶化，可能需要一个月才能了解这一行动的全部影响。

下面介绍Vercel的Speed Insight如何帮助您更快地访问更新的核心网页指标数据，以便您实时响应变化并防止排名倒退。

实验室数据：Lighthouse

在PageSpeed Insights的第二部分，标有“诊断性能问题”的区域，Google通过Lighthouse模拟您的应用性能，这与Chrome DevTools中的工具相同。

这部分数据与排名无关，但提供了改进建议。

再次强调，Lighthouse中的任何内容都不会计入您的网站搜索排名。它提供的指导意见可以帮助您避免Web应用开发中的常见问题。

解读Lighthouse分数

尽管实验室数据存在挑战，Lighthouse仍能提供有用的信息，特别是在确定哪些部分可能导致用户体验问题时。例如：

  • 性能：如果您的核心网页指标不在可接受范围内，Lighthouse会指出可能的问题，如阻塞主线程时间过长的脚本。
  • 可访问性：Lighthouse会发现常见错误，如未命名的链接或没有标签的表单字段。
  • 最佳实践：这一类别包含一些提高应用安全性和可用性的建议。
  • SEO：Lighthouse提供有关SEO技术部分的建议，帮助搜索引擎爬取您的网站。

更快迭代核心网页指标：Vercel Speed Insights

Google的数据是权威来源，但其数据使用28天滑动窗口，这意味着如果您做了改进或退步，可能需要一个月才能看到全部影响。为了提高迭代速度，Vercel创建了Speed Insights。

Speed Insights包安装在您的网站上，报告实时数据，让您可以快速响应，发现并解决问题。

与Google的PageSpeed Insights不同，您可以将数据过滤到小于过去28天的窗口，查看更改的即时效果或衡量与大型代码库更改相关的任意时间跨度。

country-map-light.png

您还可以查看应用的各个路由，并按用户的75、90、95和99百分位查看数据。

关键要点

  • 改善核心网页指标是Google搜索中最透明的排名因素，因为您可以直接访问Google用于排名的数据。
  • 只有核心网页指标会影响Google的搜索排名。您的Lighthouse得分不会被考虑。
  • Google的数据使用28天滑动窗口。为了提高网站速度的迭代速度，Vercel的Speed Insights为您提供实时、可轻松过滤的核心网页指标数据。

如何优化可以提升Core Web Vitals

前面我们了解了Core Web Vitals是什么，以及如何影响我们的页面，那您可能会问，那如何优化？下面主要介绍一些优化的方式：

优化 Largest Contentful Paint

大多数网页加载通常都会包含大量网络请求，但为了找出提升 LCP 的机会，建议您先只查看以下两个请求：

  1. 初始 HTML 文档
  2. LCP 资源（如果适用）

虽然网页上的其他请求可能会影响 LCP，但这两个请求（特别是 LCP 资源开始和结束时间的时间）会显示您的网页是否针对 LCP 进行了优化。

要确定 LCP 资源，您可以使用开发者工具（例如上面讨论的 PageSpeed Insights、Chrome 开发者工具或 WebPageTest）确定 LCP 元素。在这里，您可以匹配由该网页加载的所有资源的广告网络广告瀑布流中该元素加载的网址（同样适用，如果适用）。确定好资源后，我们可以通过以下方式：

1.​ 消除资源加载延迟

确保 LCP 资源尽早开始加载

可以提前做好域名解析或者资源加载

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

优化为资源指定的优先级

主要是延迟加载非LCP资源，提高LCP资源优先级

<img fetchpriority="high" src="/path/to/hero-image.webp">

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

也可以在 <img> 元素上设置 loading="lazy"

2.​ 消除元素渲染延迟

减少或内嵌阻止呈现的样式表

  • 将该样式表内嵌到 HTML 中，以避免产生额外的网络请求；或者，
  • 减小样式表的大小。
  • 移除未使用的 CSS：使用 Chrome 开发者工具查找未使用的 CSS 规则，这些规则可能会被移除（或延迟）。
  • 推迟非关键 CSS：将您的样式表拆分为初始网页加载所需的样式，然后拆分为可延迟加载的样式。
  • 缩减 CSS 大小：对于关键的样式，请务必尽可能减小其传输大小。

延迟或内嵌阻止呈现的 JavaScript

几乎从来没有必要将同步脚本（不含 async 或 defer 属性的脚本）添加到网页的 <head> 中，而且这样做几乎总是会对性能产生负面影响。

如果 JavaScript 代码需要在网页加载时尽早运行，最好将其内嵌，以免在等待其他网络请求时延迟呈现。不过，与样式表一样，您应只内嵌非常小的脚本。

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

使用服务器端渲染

服务器端呈现 (SSR) 是在服务器上运行客户端应用逻辑，并使用完整 HTML 标记响应 HTML 文档请求的过程。

从优化 LCP 的角度来看，SSR 有两大优势：

  • 您的图片资源将可以从 HTML 源代码中找到（如前面的第 1 步中所述）。
  • 您的网页内容无需额外的 JavaScript 请求就能完成呈现。

SSR 的主要缺点是需要额外的服务器处理时间，这可能会降低 TTFB 的速度。不过，这种权衡通常还是值得的，因为服务器处理时间由您控制，而用户的网络和设备功能则不在话下。

拆分长任务

即使您遵循了前面的建议，并且 JavaScript 代码既不会阻止呈现，也不负责呈现元素，它仍可能会延迟 LCP。

出现此错误的最常见原因是网页加载了大型 JavaScript 文件，而这些文件需要在浏览器的主线程上解析和执行。这意味着，即使图片资源已完全下载，可能仍然需要等到不相关脚本执行完毕后才能渲染。

目前的所有浏览器都在主线程上渲染图片，这意味着阻塞主线程的任何因素也可能会导致不必要的元素渲染延迟。

3.缩短资源加载时长

此步骤旨在减少通过网络将资源的字节传输到用户设备所花费的时间。一般来说，有以下三种方法可以实现此目的：

  • 缩减资源大小。
  • 减少资源需要的行程。
  • 减少网络带宽争用。
  • 完全消除网络时间。

缩减资源大小

网页（如果有）的 LCP 资源可以是图片，也可以是网页字体。以下指南详细介绍了如何缩减这两者的大小：

减少资源需要的行程距离

除了缩减资源的大小之外，您还可以通过使服务器在地理位置上尽可能靠近用户来减少加载时间。最好的方法是使用内容分发网络 (CDN)。

图片 CDN 尤其有用，因为它们不仅会减少资源需要行进的距离，而且通常还会缩减资源的大小 - 系统会自动为您采纳之前提供的所有缩减大小建议。

减少网络带宽争用

即使您缩减了资源的大小并缩短了行程距离，但如果您同时加载许多其他资源，也可能需要很长时间才能加载资源。此问题称为网络争用。

如果您为 LCP 资源指定了高 fetchpriority 并尽快开始加载它，则浏览器会尽最大努力阻止优先级较低的资源与其竞争。不过，如果您加载许多具有较高 fetchpriority 的资源，或者通常只是加载大量资源，则可能会影响 LCP 资源的加载速度。

完全消除网络使用时间

缩短资源加载时长的最佳方法是从进程中完全消除网络。如果您采用高效的缓存控制政策来传送资源，那么第二次请求这些资源的访问者将从缓存提供这些资源，从而使资源加载时长基本上为零！

如果您的 LCP 资源是一种网页字体，那么除了缩减网页字体大小之外，您还应考虑是否需要在加载网页字体资源时阻止呈现。如果您将 font-display 值设为除 auto 或 block 以外的任何其他值，文本将始终在加载期间显示，并且系统不会在收到其他网络请求时屏蔽 LCP。

最后，如果 LCP 资源较小，可以将资源内嵌为数据网址，这样也可以省去额外的网络请求。不过，使用数据网址时需要注意，因为资源无法缓存，并且在某些情况下，还会因额外的解码成本而延长呈现延迟时间。

4.​ 缩短到第一个字节所用的时间

此步骤的目的是尽快提供初始 HTML。这一步排在最后，因为开发者通常对这个步骤的控制力最弱。不过，这也是最重要的步骤之一，因为它会直接影响它之后的每一个步骤。在后端传送第一字节内容之前，前端不会发生任何操作，因此您可以采取的方法来加快 TTFB 的加载速度，这也会提升所有其他负载指标。

对于速度较快的网站，TTFB 速度变慢的常见原因是访问者通过多次重定向（例如通过广告或短链接）进行访问。始终尽可能减少访问者必须等待的重定向次数。

另一个常见原因是无法从 CDN 边缘服务器使用缓存的内容，并且所有请求都必须直接定向回源服务器。如果访问者使用唯一网址参数进行分析，就可能会发生这种情况，即使这些参数没有返回不同的网页也是如此。

监控 JavaScript 中的 LCP 细分

您可以通过以下性能 API 组合，在 JavaScript 中查看前面讨论的所有 LCP 子部分的时间信息：

在 JavaScript 中计算这些时间值的好处是，您可以将它们发送给分析提供程序或将它们记录到开发者工具中，以帮助进行调试和优化。

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

这段代码使用 JavaScript 计算每个子部分占总 LCP 时间的百分比，可以方便我们调整优化策略。

优化 Cumulative Layout Shift

布局偏移可能会分散用户的注意力。假设您在开始阅读一篇文章时突然元素在网页内四处移动，导致您离开页面，需要重新找到相应位置。这种情况在网络上非常常见，包括在阅读新闻或尝试点击“搜索”或“添加到购物车”按钮时。此类体验会造成视觉冲击和失望。通常，由于可见元素因突然添加到页面中或调整大小而被迫移动，就会导致这些错误。

导致 CLS 不佳的最常见原因包括：

  • 没有尺寸的图片。
  • 广告、嵌入和没有尺寸的 iframe。
  • 动态注入的内容，例如广告、嵌入式内容和无尺寸的 iframe。
  • 网络字体。

开发者工具中的“Performance”面板也会在体验部分中突出显示布局偏移。Layout Shift 记录的 Summary 视图包含累计布局偏移得分，以及显示受影响区域的矩形叠加层。这对于获取关于加载 CLS 问题的更多详细信息尤为有用。

image.png

设置图片尺寸的新最佳实践

由于现代浏览器会根据图片的 width 和 height 属性设置图片的默认宽高比，因此您可以通过在图片上设置这些属性并在样式表中添加前面的 CSS 来防止布局偏移。

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

之后，所有浏览器都会根据元素的现有 width 和 height 属性来添加默认宽高比。

这将在图片加载前根据 width 和 height 属性计算宽高比。它会在布局计算开始时提供这些信息。一旦系统告知图片要达到特定宽度（例如 width: 100%），系统就会根据宽高比来计算高度。

此 aspect-ratio 值由主流浏览器在处理 HTML 时计算，而不是使用默认的用户代理样式表（请参阅这篇博文深入探究原因），因此该值的显示方式略有不同。例如，Chrome 会在“元素”面板的“样式”部分中按如下方式显示该元素：

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari 与此类似，使用 HTML 属性样式源。Firefox 根本不会在 Inspector 面板中显示这个计算出的 aspect-ratio，而是将其用于布局。

上述代码的 auto 部分非常重要，因为它会导致图片尺寸在图片下载后替换默认宽高比。如果图片尺寸不同，这仍然会导致图片加载后出现一些布局偏移，但这可确保图片宽高比可用时仍然使用，以防 HTML 不正确。即使实际宽高比与默认宽高比不同，与未提供尺寸的图片的 0x0 默认尺寸相比，它仍然会导致布局偏移更小。

提示： 如果您不太了解宽高比，可使用便捷的计算器。

如需深入探究宽高比，并进一步考虑自适应图片，请参阅利用媒体宽高比实现网页加载不卡顿。

如果图片位于容器中，可以使用 CSS 根据容器的宽度调整图片大小。我们设置 height: auto; 以避免使用固定的图片高度值。

img {
  height: auto;
  width: 100%;
}

自适应图片呢？

使用自适应图片时，srcset 会定义您允许浏览器选择的图片以及每张图片的大小。为确保可以设置 <img> 宽度和高度属性，每张图片应使用相同的宽高比。

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

图片的宽高比也可能因您的艺术指导而异。例如，您可能需要在较窄的视口中添加一张图片的剪裁画面，并在桌面设备上显示完整图片：

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Chrome、Firefox 和 Safari 现在支持对给定 <picture> 元素内的 <source> 元素设置 width 和 height：

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

为延迟加载的内容预留空间

在内容流中放置延迟加载的内容时，可以通过在初始布局中为它们预留空间来避免布局偏移。

一种方法是添加 min-height CSS 规则以预留空间，或者（例如，对于广告等自适应广告）使用 aspect-ratio CSS 属性，方法类似于浏览器为具有所提供尺寸的图片自动使用该属性的方式。

为广告预留空间可以避免布局偏移

您可能需要使用媒体查询，找出不同设备类型上广告或占位符尺寸的细微差异。

对于可能没有固定高度的内容（例如广告），您可能无法预留出完全避免布局偏移所需的确切空间。如果投放的广告尺寸较小，发布商可以设置较大容器的样式来避免布局偏移，或者根据历史数据选择最可能适合相应广告位的尺寸。这种方法的缺点是会增加页面上的空白空间。

您可以将初始尺寸设为要使用的最小尺寸，对于较大内容，可接受一定程度的偏移。如前所述，使用 min-height 可让父元素根据需要进行扩展，同时降低布局偏移的影响（与空元素的默认大小为 0 像素相比）。

例如，在未返回任何广告时，尽量通过显示占位符来避免填补预留空间。移除为元素预留的空间与插入内容产生的 CLS 一样多。

将延迟加载的内容放在视口中靠下的位置

与注入到视口较低处的内容相比，在靠近视口顶部进行动态注入的内容通常会导致较大的布局偏移。不过，在视口的任意位置注入内容仍会导致一些偏移。如果您无法为注入的内容预留空间，建议您将其放置在页面靠后的位置，以降低对其 CLS 的影响。

动画

更改 CSS 属性值可能会要求浏览器对这些更改做出反应。某些值（例如 box-shadow 和 box-sizing）会触发重新布局、绘制和合成。更改 top 和 left 属性也会导致布局偏移，即使要移动的元素位于自己的层上也是如此。避免使用这些属性添加动画效果。

其他 CSS 属性可以在不触发重新布局的情况下更改。其中包括使用 transform 动画来平移、缩放、旋转或倾斜元素。

使用 translate 的合成动画不会影响其他元素，因此不会计入 CLS。非合成动画也不会导致重新布局。如需详细了解哪些 CSS 属性会触发布局偏移，请参阅高性能动画。

网络字体

在下载网页字体之前，通常通过以下两种方式之一处理网页字体的下载和呈现：

  • 回退字体被网页字体交换，导致“无样式文本”(FOUT) 闪烁。
  • “不可见”文本使用后备字体显示，直到有可用的网络字体且该文本可见（FOIT，即不可见的文本闪烁）。

这两种方法都会导致布局偏移。即使文本不可见，它仍会使用后备字体进行布局，因此当网络字体加载时，文本块和周围内容会按照与可见字体相同的方式移动。

以下工具可以帮助您最大限度地减少文本移位：

  • font-display: optional 可以避免重新布局，因为网页字体在完成初始布局时可用。
  • 请务必使用适当的后备字体。例如，使用 font-family: "Google Sans", sans-serif; 可确保在加载 "Google Sans" 时使用浏览器的 sans-serif 后备字体。如果不仅使用 font-family: "Google Sans" 指定后备字体，系统将使用默认字体，这种字体在 Chrome 上称为“Times”（一种 Serif 字体，比默认 sans-serif 字体的匹配度更差）。
  • 使用新的 size-adjust、ascent-override、descent-override 和 line-gap-override API，最大限度地减小回退字体与网页字体之间的大小差异，如改进的字体回退博文中所述。
  • Font Loading API 可以缩短获取必要字体所需的时间。
  • 使用 <link rel=preload> 尽早加载关键网页字体。预加载的字体更有可能满足首次绘制要求，在这种情况下不会发生布局偏移。

如需了解其他字体方面的最佳实践，请参阅字体最佳实践。

优化 Interaction to Next Paint

为了提供良好的用户体验，网站应尽力将 Interaction to Next Paint 控制在 200 毫秒或更短的范围内。为确保大多数用户都能达到此目标值，建议将网页加载的第 75 个百分位作为阈值（按移动设备和桌面设备细分）。

良好的 INP 值不超过 200 毫秒，不佳的值大于 500 毫秒，介于两者之间的所有值都需要改进。

根据网站的不同，互动元素可能很少，甚至没有，例如网页主要是文字和图片，互动元素很少，甚至完全没有。或者，在文本编辑器或游戏等网站上，可能会发生数百次甚至数千次互动。无论是哪种情况，如果 INP 较高，用户体验就会面临风险。

在优化 Interaction to Next Paint (INP) 的过程中，有一个难点是找出导致 INP 不佳的原因。有很多潜在原因，例如第三方脚本在主线程上调度许多任务、DOM 大小较大、事件回调开销大以及其他问题。

改进 INP 并非易事。首先，您必须了解哪些互动往往导致网页的 INP。如果您不知道从实际用户的角度来看，您网站上的哪些互动最慢，请参阅查找现场缓慢的互动。获得实测数据作为指导后，您就可以在实验室工具中手动测试这些特定交互，从而找出这些交互速度缓慢的原因。

下一步就是对其进行优化。互动可分为三个阶段：

  1. 输入延迟，在用户发起与网页的互动时开始，在互动的事件回调开始运行时结束。****
  2. 处理时长，即事件回调完成运行所需的时间。****
  3. 呈现延迟，即浏览器呈现包含互动视觉结果的下一帧所用的时间。

这三个阶段的总和就是总互动延迟时间。互动的每个阶段都会带来一定程度的总互动延迟时间，因此请务必了解如何优化互动的各个部分，以便尽可能缩短互动时间。

avatar
文章
阅读
粉丝