尝试衡量软导航

Barry Pollard

Yoav Weiss

2024 年 8 月更新：第二次软导航源试用已于 5 月 29 日结束。Chrome 团队正在花时间审核实验反馈，并考虑此 API 的后续步骤。我们希望解决一些准确性问题，并且认为在该功能准备就绪之前，需要进行另一次来源测试。在此期间，开发者仍然可以通过启用 chrome://flags/#enable-experimental-web-platform-features 来体验此功能。

自推出以来，Core Web Vitals 计划一直致力于衡量网站的实际用户体验，而不是网站创建或加载背后的技术细节。这三个 Core Web Vitals 指标是作为以用户为中心的指标创建的，是对现有技术指标（例如 DOMContentLoaded 或 load）的改进，后者衡量的时间往往与用户对网页性能的感知无关。因此，只要网站的表现良好，用于构建网站的技术不应影响评分。

现实情况总是比理想情况要复杂一些，而且核心网页指标从未完全支持广受欢迎的单页应用架构。这些 Web 应用不会在用户浏览网站时加载单独的网页，而是使用所谓的“软导航”，在这种导航中，网页内容由 JavaScript 更改。在这些应用中，通过更改网址并将之前的网址推送到浏览器历史记录中，从而使返回和前进按钮按用户预期运行，从而营造出传统网页架构的错觉。

许多 JavaScript 框架都使用这种模型，但各自的实现方式有所不同。由于这超出了浏览器传统意义上所理解的“网页”的范畴，因此衡量这一点一直很困难：在当前网页上的互动与将其视为新网页之间，该如何划分界限？

Chrome 团队一直在考虑这一挑战，他们希望对什么是“软导航”的定义进行标准化，并就如何衡量核心网页指标对此进行标准化 - 采用与在传统多页面架构 (MPA) 中实现的网站的衡量方式类似。虽然仍处于早期阶段，但该团队现已准备好让已实施的功能更广泛地供网站进行实验。这将允许网站就目前的方法提供反馈。

什么是软导航栏？

我们对软导航做出了以下定义：

• 导航由用户操作发起。
• 此导航会导致网址对用户可见，并且会更改历史记录。
• 导航会导致 DOM 更改。

对于某些网站，这些启发词语可能会导致假正例（用户实际上不会认为发生了“导航”）或假负例（用户认为发生了“导航”，但实际上不符合这些条件）。欢迎您在软导航规范代码库中针对这些启发词语提供反馈。

Chrome 如何实现软导航？

启用软导航启发式算法后（下一部分将对此进行详细介绍），Chrome 将更改其报告某些性能指标的方式：

• 系统会在每次检测到软导航后发出 soft-navigation PerformanceTiming 事件。
• Performance API 将提供对 soft-navigation 时间记录条目的访问权限，该时间记录条目由 soft-navigation PerformanceTiming 事件发出。
• 首次绘制 (FP)、首次内容绘制 (FCP) 和 Largest Contentful Paint (LCP) 指标将重置，并在下次适当出现时重新发送。（注意：FP 和 FCP 未实现。）
• 系统会向与事件相关联的导航条目对应的每个性能时间点（first-paint、first-contentful-paint、largest-contentful-paint、first-input-delay、event 和 layout-shift）添加 navigationId 属性，以便计算 Cumulative Layout Shift (CLS) 和 Interaction to Next Paint (INP)。

这些更改将允许系统按网页导航来衡量 Core Web Vitals 以及一些相关的诊断指标，但还存在一些需要考虑的细微差别。

在 Chrome 中启用软导航会有什么影响？

以下是网站所有者在启用此功能后需要考虑的一些更改：

• 系统可能会针对软导航重新发出其他 FP、FCP 和 LCP 事件。Chrome 用户体验报告 (CrUX) 会忽略这些额外的值，但这可能会影响您网站上的任何真实用户衡量 (RUM) 监控。如果您有任何疑虑，请咨询 RUM 提供商，了解这是否会影响这些衡量结果。请参阅有关衡量软导航的核心网页指标的部分。
• 在使用这些条目的应用代码中，您可能需要考虑性能条目上的新（可选）navigationID 属性。
• 只有基于 Chromium 的浏览器才支持这一新模式。虽然许多新指标仅适用于基于 Chromium 的浏览器，但有些指标（FCP、LCP）适用于其他浏览器，而且并非所有用户都可能已升级到基于 Chromium 的最新版浏览器。因此，请注意，部分用户可能不会报告软导航指标。
• 这是一项实验性的新功能，默认情况下不会启用，网站应测试此功能，以确保不会产生任何其他意外的副作用。

如需详细了解如何衡量软导航的指标，请参阅“衡量每次软导航的 Core Web Vitals”部分。

如何在 Chrome 中启用软导航？

Chrome 中默认不启用软导航栏，但您可以通过明确启用此功能来进行实验。

对于开发者，可通过以下方式启用此功能：在 chrome://flags/#enable-experimental-web-platform-features 中开启实验性网络平台功能标志，或在启动 Chrome 时使用 --enable-experimental-web-platform-features 命令行参数。

如何衡量软导航？

启用软导航实验后，系统会照常使用 PerformanceObserver API 报告指标。不过，对于这些指标，还需要考虑一些额外的注意事项。

注意：系统尚未针对软导航报告 FP 和 FCP。

报告软导航

您可以使用 PerformanceObserver 来观察软导航。以下示例代码段会将软导航条目记录到控制台，包括使用 buffered 选项在此页面上进行的之前的软导航：

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

这可用于最终确定上一次导航的完整生命周期页面指标。

针对相应网址报告指标

由于软导航只有在发生后才能看到，因此需要在发生此事件时最终确定一些指标，然后针对之前的网址生成报告，因为当前网址现在会反映新网页的更新网址。

您可以使用相应 PerformanceEntry 的 navigationId 属性将事件与正确的网址关联。可以使用 PerformanceEntry API 进行查询：

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

此 pageUrl 应该用于根据正确的网址（而不是过去可能使用过的当前网址）报告指标。

获取软导航栏的 startTime

您可以通过类似的方式获取导航开始时间：

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime 是发起软导航的初始互动（例如按钮点击）的时间。

所有性能计时（包括软导航的计时）均从最初的“困难”网页导航时间开始报告。因此，软导航开始时间需要作为软导航加载指标时间（例如 LCP）的基准（相对于此软导航时间）。

衡量每次软导航的核心网页指标

如需添加软导航指标条目，您需要在性能观察器的 observe 调用中添加 includeSoftNavigationObservations: true。

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

除了在 Chrome 中启用软导航功能之外，还需要在 observe 方法上设置额外的 includeSoftNavigationObservations 标志。在性能观察器级别明确选择启用此功能是为了确保现有性能观察器不会对这些额外的条目感到意外，因为在尝试衡量软导航的 Core Web Vitals 时，需要考虑一些额外的注意事项。

系统仍会根据原始的“硬性”导航开始时间返回时间。例如，若要计算软导航栏的 LCP，您需要取 LCP 时间，然后减去相应的软导航栏开始时间（如前面详述），以获取相对于软导航栏的时间。例如，对于 LCP：

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

传统上，某些指标是在网页的整个生命周期内衡量的：例如，在发生互动之前，LCP 可能会发生变化。在用户离开页面之前，CLS 和 INP 会一直更新。因此，每次发生新的软导航时，每个“导航”（包括原始导航）都可能需要最终确定上一个网页的指标。这意味着，初始的“硬性”导航指标可能会比平常提前确定。

同样，当开始衡量这些长时性指标的新软导航的指标时，需要“重置”或“重新初始化”指标，并将其视为新指标，不记得为之前的“网页”设置的值。

应如何处理在导航之间保持不变的内容？

软导航的 FP、FCP 和 LCP 将仅衡量新的绘制。这可能会导致 LCP 不同，例如，从该软导航的冷加载变为软加载。

例如，假设某个网页包含一幅作为 LCP 元素的大横幅图片，但该图片下方的文字会随着每次软导航而发生变化。初始网页加载将将横幅图片标记为 LCP 元素，并据此确定 LCP 时间。对于后续的软导航，其下方的文本将是软导航完成后绘制的最大元素，并且将成为新的 LCP 元素。不过，如果通过指向软导航栏网址的深层链接加载新页面，横幅图片将是新的绘制内容，因此可以被视为 LCP 元素。

如此示例所示，软导航栏的 LCP 元素的报告结果可能会因网页的加载方式而异，就像加载包含网页下方锚链接的网页可能会导致不同的 LCP 元素一样。

如何衡量 TTFB？

传统网页加载的首字节显示前的耗时 (TTFB) 表示返回原始请求的第一个字节所需的时间。

对于软导航，这个问题更难回答。我们是否应衡量针对新网页发出的第一个请求？如果应用中已经包含所有内容，并且没有其他请求，该怎么办？如果该请求是通过预提取提前发出的，该怎么办？如果请求与软导航无关（例如，它是分析请求），从用户角度来看，会发生什么情况？

更简单的方式是将软导航的 TTFB 报告为 0，这与我们为往返缓存恢复所建议采用的方式类似。这是 web-vitals 库用于软导航的方法。

未来，我们可能会支持更精确的方法来了解哪个请求是软导航的“导航请求”，并能够更精确地衡量 TTFB。但这不是当前实验的一部分。

如何同时衡量新旧版本？

在此实验期间，建议继续以当前方式衡量 Core Web Vitals，即根据“硬性”网页导航，与 CrUX 将作为 Core Web Vitals 计划的官方数据集进行衡量和报告的数据保持一致。

除了这些之外，您还应衡量软导航，以便了解未来如何衡量这些导航，并让您有机会向 Chrome 团队提供有关此实现在实践中运作方式的反馈。这有助于您和 Chrome 团队进一步完善该 API。

若要衡量这两者，您需要了解软导航模式下可能会发出的新事件（例如，多个 FCP 事件和额外的 LCP 事件），并在适当的时间最终确定这些指标，同时忽略将来仅适用于软导航的事件，从而妥善处理这些事件。

使用 web-vitals 库衡量软导航的 Core Web Vitals

要考虑所有细微之处，最简单的方法是使用 web-vitals JavaScript 库，该库在单独的 soft-navs branch（也适用于 npm 和 unpkg）中对软导航进行了实验性支持。您可以通过以下方式衡量此值（请根据需要替换 doTraditionalProcessing 和 doSoftNavProcessing）：

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

确保系统根据前面提到的正确网址报告指标。

web-vitals 库会针对软导航报告以下指标：

指标	详细信息
TTFB	报告为 0。
首次内容渲染 (FCP)	系统仅会报告网页的第一个 FCP。
LCP	下一个 largest contentful paint 的时间（相对于软导航的开始时间）。系统不会考虑上一个导航中存在的现有绘制。因此，LCP 将 >= 0。通常，系统会在发生互动或页面进入后台时报告此值，因为只有在那时才能最终确定 LCP。
CLS	导航时间之间最长的时间差。像往常一样，当网页在后台运行时，只有这样才能最终确定 CLS。如果没有偏移，系统会报告 0 值。
INP	导航时间之间的 INP。通常，系统会在发生互动时或页面进入后台时报告此值，因为只有在那时才能最终确定 INP。如果没有互动，系统不会报告值 0。

警告：web-vitals 实现正在积极开发中，随着新更改发布到该分支，可能会发生变化。它不支持对软导航使用 FCP，因为这需要 Chrome 中执行更多底层工作。 使用 web-vitals JavaScript 库的用户如果希望在生产网站上使用此库，应注意这一点，并应获取本地副本并测试该版本，同时监控分支是否有更改。

这些更改是否会纳入 Core Web Vitals 衡量范围？

这项软导航实验就是一个实验。我们希望先评估这些启发词语，看看它们能否更准确地反映用户体验，然后再决定是否将其纳入 Core Web Vitals 计划。我们非常期待开展这项实验，但无法保证这项实验是否会取代当前的衡量方法，也无法保证何时会取代。

我们非常重视 Web 开发者对实验、所用启发词语以及您认为这些启发词语能否更准确地反映体验的反馈。软导航 GitHub 代码库是提供此类反馈的最佳位置，不过，如果 Chrome 的实现存在个别 bug，则应在 Chrome 问题跟踪器中提出。

CrUX 中如何报告软导航？

如果此实验取得成功，CrUX 中将如何精确报告软导航功能，目前仍未确定。这并不一定意味着它们会像当前的“硬”导航一样被处理。

在某些网页中，对于用户而言，软导航与整个网页加载几乎没有区别，而使用单页应用技术只是实现细节。在某些情况下，它们可能更像是部分加载的额外内容。

因此，我们可能会决定在 CrUX 中单独报告这些软导航，或者在计算给定网页或网页组的 Core Web Vitals 时对其进行加权。随着启发式算法的改进，我们还可以完全排除部分加载软导航。

该团队目前正专注于启发词语和技术实现，以便我们判断此实验的成效，因此尚未就这些方面做出任何决定。

反馈

我们正在积极征求有关此实验的反馈，欢迎您通过以下方式提供反馈：

• 软导航启发词语和标准化。
• 这些启发词语的 Chrome 实现问题。
• 如需提供有关网页指标的一般反馈，请发送电子邮件至 [e-mail]。

更新日志

由于此 API 处于实验阶段，因此会发生许多更改，比稳定版 API 更多。如需了解详情，请参阅软导航启发词语变更日志。

总结

软导航实验是一种令人兴奋的方法，可帮助我们了解核心 Web 指标计划如何演变，以衡量我们的指标中缺少的现代网络上的常见模式。虽然这项实验才刚刚起步，我们还有许多工作要做，但将目前取得的进展提供给更广泛的 Web 社区进行实验，是迈向成功的重要一步。收集此次实验的反馈是实验的另一个关键环节，因此我们强烈建议对此开发感兴趣的用户利用此次机会帮助完善该 API，确保其能够代表我们希望通过该 API 衡量的内容。

致谢

缩略图图片：Unsplash 用户 Jordan Madrid