【问题标题】:how to debug LCP as CLS with web vitals js sdk?如何使用 Web Vitals js sdk 将 LCP 调试为 CLS?
【发布时间】:2021-08-17 03:51:29
【问题描述】:

感谢web vitals js sdk,我已经解决了我所有的 CLS 问题。

我可以收集页面上影响 CLS 分数的所有元素。通过添加min-heightaspect-ratio 很容易修复。

但是,有没有类似的方法来调试LCP?我不知道我的 LCP 分数不好的根本原因是什么。

【问题讨论】:

    标签: core-web-vitals


    【解决方案1】:

    除了 LCP 值本身之外,您还应该将一些内容记录到分析中:有关对 LCP 有贡献的元素的信息、相关的 Web Vitals 和用户元数据。

    LCP 元素信息

    区分 LCP 元素类型会很有用:图像、标题、段落等。web-vitals.js 报告完整的 LCP 条目,因此您可以使用如下脚本提取类型:lcpEntry.element.tagName。另见Debugging LCP in the field

    查看分析数据时,您可以使用此调试信息来了解需要优化的内容。如果 20% 的页面浏览量具有基于图像的 LCP,而其余的页面浏览量基于 H1,这有助于您了解图像优化对整体故事的帮助程度。这也是验证您的实验室测试与您的用户测量相同事物的有用方法。

    相关的 Web Vitals

    LCP 直接受页面加载性能的影响。根据定义,LCP 发生在 FCP(第一次内容绘制)之后。 FCP 也发生在 TTFB(到第一个字节的时间)之后。 FCP 和 TTFB 都是库中可用的 Web Vitals,因此您也应该记录它们。

    TTFB 对于诊断缓慢的 LCP 时间是由后端还是前端问题引起的特别有用。当 TTFB 慢于 2.5 秒时,LCP 不可能“快”(

    用户元数据

    用户的视口大小将影响显示的内容以及有资格计为 LCP 的内容。您可以使用window.innerHeightwindow.innerWidth 来衡量这一点。

    同样,页面的初始滚动位置可能不会设置在顶部,例如当用户单击带有类似#example 的 URL 片段的链接时。视口的内容会有所不同,因此 LCP 元素也会有所不同。您可以在 DOM 准备好确定页面是否滚动时测量 window.pageYOffset 和/或您可以记录 location.hash

    Network Information API 可以告诉您用户的网络连接情况。大图像在慢速连接上加载速度较慢,因此了解用户访问您网站的速度是明智之举。例如:navigator.connection.effectiveType

    web.dev/lcp/

    一旦用户与页面交互(通过点击、滚动或按键),浏览器就会停止报告新条目,因为用户交互通常会改变用户可见的内容(滚动尤其如此)。

    因此,例如,如果用户在大型英雄图像完成加载之前滚动,则它不会是 LCP。您可以使用Element Timing API 跟踪英雄图像的加载时间。如果您希望成为 LCP 的元素在与报告的 LCP 值不同的时间加载,您就知道是用户交互之类的东西导致了它的变化。

    这些用户特定的访问和行为特征中的每一个都可以在实验室测试中进行模拟,以确保您在真实条件下测试您的网页。

    【讨论】:

    • 感谢您的提示。我有一个简单的问题:我是否必须在 <head> 部分中包含重要的 js sdk,还是可以像加载 Google Analytics 代码一样稍后动态加载它?
    • 对不起,再问一个问题,如果用户的网络状况会对我的网络生命造成负面影响,是否会被一些控制大量不良网络设备的黑客用来攻击网站并降低他们的网络?生命值?
    • 对不起,最后一个问题,我发现有些用户确实滚动到了页面的一半。这个地方有很多图像,如果我使用延迟加载(我强制图像在用户滚动屏幕之前不加载),我的 LCP 会很糟糕吗?比如用户停留5秒然后滚动,再加载图片,LCP会大于5吗?
    • 我已设置现场检查并插入我的 GA。我看到一个元素得到了一个平均值。 5,697 的值 - 这是否意味着 LCP=5.697s
    【解决方案2】:

    LCP 通常与加载顺序直接相关。因此,它通常使用测试工具进行相当准确的测量 - 与 CLS 不同,CLS 可能会受到用户交互和稍后出现的元素的影响,因此更难以综合,因此最好使用真实用户监控 (RUM) 进行测量,如 web Vitals 脚本.

    我发现WebPageTest 是衡量和了解 LCP 的最佳工具之一。插入您的网站,它会创建一个瀑布图 - 还会告诉您您的 LCP/CLS 编号,以及测试编号是否与 Google 从真实用户那里收集的相符,或者测试设置是否关闭。

    然后您可以查看瀑布图,看看为什么 LCP 元素的加载时间比您想要的要晚:

    • 是大图吗,下载时间长?如果可以,您可以优化它吗?
    • 它是一个较晚发现的资源(例如 CSS 中的图像,或依赖于运行的 JavaScript),那么您可以在这里使用资源提示(预加载或预连接)来提供帮助吗?
    • 加载 LCP 内容是否存在争用,您能否延迟加载屏幕内容以减少这种争用?
    • 是否是需要自定义字体的文本并且需要一段时间才能下载?在优化字体下载方面有很多很好的资源。
    • 是否有太多 JavaScript 阻塞了初始渲染?
    • …等

    PageSpeed Insights 是另一个有用的工具(由 Google 提供),它比 WebPageTest 简单一点,它在页面上运行性能审计(使用流行的 Lighthouse 工具)并为您提供分数、各种统计数据和建议的改进。他们再次提供 RUM 数字,以便您可以查看测试是否代表您的用户所看到的内容。他们最近还添加了过滤 Core Web Vitals 的功能,因此您可以查看可能会影响您的 LCP 分数的建议。

    使用上述任一工具,您仍应与您的 Web Vitals 脚本相关联,以确保它们具有代表性,并且您没有优化错误的内容或专注于错误的页面。正如我所说,这些工具确实会尝试向您显示他们拥有的 RUM 统计信息,但它们不会告诉您是否应该专注于另一个页面而不是这个页面,或者您的用户是否选择了不同于他们突出显示的 LCP 元素(例如,它们的屏幕尺寸不同,因此获得的内容与这些测试显示的内容不同)。

    【讨论】:

    • +1 从实验室调试的角度来看,这是一个很好的答案。我添加了一个从现场调试角度接近解决方案的答案。
    • @RickViscomi 很奇怪我的领域成绩很好。所有指标都很好(绿色)。但我的实验室数据和搜索控制台结果很差。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-08-01
    • 2021-03-31
    • 2022-11-20
    • 2022-05-31
    • 1970-01-01
    • 2021-08-12
    • 2016-07-31
    相关资源
    最近更新 更多