【问题标题】:Lighthouse Field data is not updated for a very long time, what should I do?Lighthouse Field数据很长时间没有更新,我该怎么办?
【发布时间】:2020-12-16 04:37:01
【问题描述】:

由于错误的用户体验设计,我的 CLS 分数非常低。但是,我在一个多月前已经修复了这个错误。

但字段数据仍未更新。

我应该怎么做才能强制更新字段数据?

【问题讨论】:

  • 为您添加了 pagespeed-insights 标签,因为它使用相同的引擎(Lighthouse),增加了您获得所需答案的机会。

标签: performance lighthouse pagespeed-insights


【解决方案1】:

我应该怎么做才能强制更新字段数据?

我不确定您是否可以更改这些数据,因为这些数据是根据 Chrome 用户体验报告收集的,正如 here 所述:

Chrome 用户体验报告由真实用户测量提供支持 公共网络上的关键用户体验指标,汇总自 选择同步浏览历史记录的用户没有 设置同步密码,并启用使用情况统计报告

关于您的问题,为什么它没有被更新并且在您的实验室数据中它有 0 cls 但在现场数据中它不一样,这又取决于各种因素。实验室数据基本上是在受控环境(主要是您的机器)中运行报告,而现场数据是来自具有各种网络和设备的各种用户的汇总数据的结果,并且很可能它们不会相同除非您的目标受众使用与运行实验室报告的网络和设备类似的网络和设备。

searching webmasters forum你可以找到几个类似的帖子。

【讨论】:

  • 感谢您的信息。但是,我在几台不同的机器上测试过,结果是一样的。
  • @AGamePlayer 你也尝试过限制网络吗?
【解决方案2】:

我应该怎么做才能强制更新字段数据?

你不能害怕。

但是,如果您想实时查看累积布局转换数据(以发现任何问题/及早确认修复),您可以使用“web Vitals 库” - 请查看最终的第 3 级标题(“使用 JavaScript 跟踪实时数据”)在这个答案的末尾。

这里到底发生了什么?

字段数据是按 28 天滚动计算的,因此如果您在一个月前进行了更改问题仍然存在。

仅仅因为实验室测试产生 0 的累积布局偏移并不意味着在现场就是这种情况。

在字段数据中,计算(并累积)累积布局偏移 (CLS),直到页面卸载。 (See this answer from Addy Osmani,他在 Google 的 Lighthouse 工作,这是 Page Speed Insights 背后的引擎)。

因此,您可能会在页面下方遇到问题,或者在一段时间后出现问题,从而导致布局发生变化,而自动化测试无法识别。

这意味着如果在滚动页面后布局发生变化(例如由于延迟加载无法有效工作),它将开始影响 CLS 字段数据。

还要记住,现场数据是在所有设备上收集的。

可能的原因

以下是几个可能的原因:

屏幕尺寸

仅仅因为网站没有在 Page Speed Insights 使用的移动设备和桌面设备尺寸上显示 CLS,并不意味着 CLS 不会以不同的尺寸出现。可能是平板电脑或某些移动设备屏幕宽度导致项目在屏幕上“跳跃”。

JavaScript 布局引擎

另一个可能的原因是使用 JavaScript 进行布局。查看您的“交互时间”和“总阻塞时间”,我猜您的网站正在使用 JavaScript 进行布局/模板(因为它们都很高,表明 JavaScript 负载很大)。

请记住,如果您的最终用户使用的是速度较慢的机器(台式机和移动设备),那么巨大的 JavaScript 负载也可能会对页面绘制时的布局变化产生严重影响。

字体

字体交换会导致很多 CLS 问题,因为在其中交换新字体会导致自动换行发生变化,从而改变容器的高度(如果宽度不固定/流动,则改变宽度)。

如果由于某种原因您的字体加载缓慢或加载顺序很晚,这可能会导致较大的 CLS。

这很可能是在较慢的连接(例如 4G)上,其中网络延迟可能会导致问题。自动化测试可能无法解决这个问题,因为它们基于模拟(通过算法)限制负载,而不是对每个请求应用限制(实际上是应用延迟和吞吐量降低)。

此外,如果您使用字体图标(例如 font-awesome),那么这很可能是导致 CLS 的原因。如果这是原因,请改用内联 SVG。

确定问题

Here is a question(并在没有人回答我的情况下回答)我创建了关于如何识别 CLS 的问题。我对自己的问题给出的答案是识别我能找到的问题的最有效方法,但是我仍然希望随着更多人习惯于纠正 CLS 问题,有人会改进我的答案。同样的原则也适用于查找字体自动换行问题。

如果问题与我怀疑的 JavaScript 相关,那么更改开发者工具中的 CPU 减速将使您发现这一点。

  1. 转到开发人员工具 -> 性能 -> 如果需要,单击右上角的“齿轮”图标 -> “CPU”。将其设置为 6 倍减速。

  1. 然后转到“渲染”选项卡并打开“油漆闪烁”、“布局移动区域”和“图层边框”。您可能需要使用下方面板菜单栏左侧的 3 个垂直点下拉菜单来启用“渲染”选项卡。

  1. 现在重新加载您的页面并在您开始浏览页面时查找任何问题。密切注意任何蓝色闪烁,因为它们突出显示已移动的项目。我发现,一旦发现潜在的变化,单独打开和关闭前两个选项并重复操作很有用,因为有时布局变化不像重绘那样明显,但两者一起可能会令人困惑。

那么我是否必须等待 28 天才能看到问题是否已解决?

不,如果您在修复后大约 7 天观察您的 CLS 分数,您会看到缓慢而稳定的改善,因为“红色”的人从滚动的 28 天平均值中消失了。

如果您在 7 天后处于红色状态的百分比从 22% 下降到 18% 以下,那么您很有可能已经解决了问题(对于“处于橙色状态”的人,您也会看到类似的下降)。

实际的 CLS 数字(屏幕截图中的 0.19)可能在 28 天后才会改变,因此请忽略这一点,除非它向上跳跃

使用 JavaScript 跟踪实时数据

您可能想查看web vitals library 并实施您自己的 CLS(和其他关键指标)跟踪,这样您就可以获得实时用户数据,而不是等待字段数据更新。

我自己才刚刚开始玩这个,但到目前为止它看起来很简单。我目前正在尝试实现自己的数据端点,而不是谷歌分析,这样我就可以控制实时数据。如果我在赏金用​​完之前得到排序,我会相应地更新答案。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2021-12-29
    • 2011-02-05
    • 2019-12-01
    • 2017-12-27
    • 1970-01-01
    • 2021-03-16
    • 1970-01-01
    • 2021-05-02
    相关资源
    最近更新 更多