Lighthouse Field 数据很长时间没有更新，我该怎么办？

Question

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

但现场数据仍然没有更新。

我应该怎么做才能强制更新 Field 数据？

Answer 1

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

恐怕你不能。

但是，如果您想实时查看累积布局转变数据（以便尽早发现任何问题/确认修复），您可以使用“Web Vitals 库” - 请参阅最终的 3 级标题（“使用 JavaScript 跟踪实时数据”） ”）在这个答案的末尾。

现场数据按 28 天滚动计算，因此如果您在一个月前进行更改，问题仍然存在。

仅仅因为实验室测试产生 0 累积布局偏移并不意味着现场情况也是如此。

在字段数据中，计算（并累积）累积布局偏移 (CLS) ，直到页面达到 unload。（请参阅 Addy Osmani 的回答，他在 Google 从事 Lighthouse 工作，Lighthouse 是 Page Speed Insights 背后的引擎）。

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

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

另请记住，现场数据是通过所有设备收集的。

以下是几个可能的原因：

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

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

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

字体交换会导致很多 CLS 问题，因为交换新字体可能会导致自动换行发生变化，从而改变容器的高度（如果宽度不固定/不固定，则改变宽度）。

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

同样，这可能是在 4G 等速度较慢的连接上，网络延迟可能会导致问题。自动化测试可能不会发现这一点，因为它们基于模拟（通过算法）来限制负载，而不是对每个请求应用限制（实际上是应用延迟和吞吐量减慢）。

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

这是我创建的一个关于如何识别 CLS 问题的问题（并回答了，因为没有人回答我）。我对自己的问题给出的答案是识别我能找到的问题的最有效方法，但是我仍然希望随着越来越多的人习惯纠正 CLS 问题，有人会改进我的答案。同样的原理也适用于查找字体自动换行问题。

如果问题与 JavaScript 有关（正如我怀疑的那样），那么更改开发人员工具中的 CPU 减速将允许您发现此问题。

然后转到“渲染”选项卡并打开“Paint Flashing”、“Layout Shift Regions”和“Layer borders”。您可能需要使用下面板菜单栏左侧的 3 个垂直下拉点来启用“渲染”选项卡。

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

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

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

实际的 CLS 数字（屏幕截图中的 0.19）可能要到 28 天后才会改变，因此请忽略该数字，除非它向上跳跃。

您可能想要查看Web Vitals 库并实施您自己的 CLS（和其他关键指标）跟踪，这样您就可以获得实时用户数据，而不必等待现场数据更新。

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