揭秘 WordPress 的核心网络生命力

Core Web Vitals 现在代表了一组用于优化网站的强制性指标，尤其是在 SEO 和网站性能对您的数字策略很重要的情况下。 尽管如此，在尝试改进您网站上的 Core Web Vitals 时，可能很难确定哪些 WordPress 工具和策略最重要。

观看本次会议，深入了解用于理解和改进 WordPress 网站上的 Core Web Vitals 分数的最佳实践和工具。

演讲嘉宾：

• WP Engine 产品经理 Alex Zuniga
• Amsive Digital 网络开发总监 Mark Davoli
• Vital Design 开发总监 Matt Chase
• WP Engine 高级 Web 开发人员 Sanjucta Ghose
• XWP 前端工程总监 Mike Crantea

成绩单：

ALEX ZUNIGA：大家好，欢迎来到揭秘 WordPress 的 Core Web Vitals。 我是 Alex Zuniga，WP Engine 的产品经理。 今天，我们真的要讨论您的 WordPress 网站的核心网络生命力的来龙去脉。 如果您关心优化网站的 SEO 和网站性能，核心网络生命力是一个必须优化的指标。 但可能很难知道哪些 WordPress 工具和策略最有影响力。 因此，加入本次会议，深入了解最佳实践和工具如何帮助您提高 WordPress 的网络重要分数。

现在，事不宜迟，我们将介绍本次会议的小组成员。 首先，我会请 Mike 做一个简短的自我介绍。

迈克·克兰蒂亚： 大家好，我是迈克·克兰蒂亚。 我位于西班牙加那利群岛。 我是 XWP 的前端工程总监，过去 17 年我一直在那里工作。 主要在前端技术领域，我喜欢网络性能。 我很高兴来到这里。 嘿。

亚历克斯祖尼加： 谢谢迈克。 接下来，我们有马特蔡斯。

MATT CHASE：我是新罕布什尔州朴次茅斯 Vital Design 的开发总监。 我的工作重度关注前端。 所以我们做了很多 lighthouse 和 Core Web Vital 评分。

亚历克斯祖尼加：太棒了。 谢谢，马特。 还有马克。

MARK DAVOLI：大家好，我是 Amsive Digital 的 Web 开发总监 Mark Davoli。 一直专注于我们团队的 Core Web Vital 空间，因为 SEO 对我们公司非常重要。 因此，Core Web Vitals 也是如此。 很高兴来到这里。

ALEX ZUNIGA：很高兴有你，伙计。 最后但同样重要的是，Sanjucta。

SANJUCTA GHOSE： 大家好。 我也来自 WP Engine。 我是负责维护 WP Engine 网站的团队的一员。 这包括 WP Engine 收购 Delicious Brains 时出现的网站。 去年我花了很大一部分时间为 Core Web Vitals 优化 Delicious Brain 网站。 所以我认为这应该是一次非常有趣的对话。 很高兴来到这里。

亚历克斯·祖尼加： 谢谢。 谢谢。 那么，欢迎来到我们所有的小组成员。 我们迫不及待地想听听您的意见。 因此，当涉及到 Core Web Vitals 时，我们将通过衡量、管理、工具和客户期望来分解这些问题。 所以我们想问大家的第一个问题是，我为什么要首先关心 Core Web Vitals？ 我应该在多大程度上关注 Core Web Vital 优化？

MARK DAVOLI： 如果你愿意，我可以谈谈。 对我来说，确保您拥有快速的页面速度非常重要。 重要的原因在于最终结果的转换。 正确的？ 因此，当有人访问网站时，加载时间越长，他们离开的可能性就越大。 而且，如果您的页面速度不快，那么您将不走运并可能失去很多业务。 特别是在电子商务商店。

SANJUCTA GHOSE： 是的。 我有点同意您所说的，因为虽然它对 SEO 非常重要，但我们还需要记住，Core Web Vitals 是衡量您网站感知性能的指标。 用户如何看待您的网站。 而且我认为，让用户注意到您的网站具有响应性、交互性和稳定性，这一点非常重要。 哪些是 Core Web Vitals 衡量的指标。 所以我认为用户对你的表现的看法比 SEO 分数更重要。 这就是为什么我们应该关注 Core Web Vitals。

亚历克斯·祖尼加：当然。 马特，你有——

MATT CHASE：是的，基本上，这就是我要说的，是的，SEO 方面很棒。 但最终，我们为人们编写这些网站。 我们希望这些人拥有最快、最活泼的网站。 但这会影响两个世界。 正确的？ 所以我们有点——当我们针对这些 Core Web Vitals 进行调整时，我们正在做很棒的用户体验。 但以一种让 SEO 团队满意的方式，这有时并不总是一场容易获胜的战斗。 所以它适用于每个人。

ALEX ZUNIGA：综上所述，我们知道这很重要。 但是衡量我们分数的最佳方法是什么？

MARK DAVOLI：因此，除了使用之外，我们的衡量方式之一是 Google 的 Page Speed Insight Tool，这很重要，因为这是他们用来衡量它的工具。 是的，所以如果你想产生影响，使用这个工具是至关重要的。 在 Chrome DevTools 中还有浏览器内的 Lighthouse，这非常重要。 Search Console 有一个很棒的页面用户体验工具，可以监控过去 28 天的真实用户指标，这对于长时间监控至关重要。

SANJUCTA GHOSE： 是的。 所以我想说 Page Speed Insights 是一个非常好的工具，因为它可以为您提供实时数据，因为核心 Web Vitals 本身基于过去 28 天的真实用户数据。 但随后您还可以查看基于实验室数据的 Lighthouse 报告。 这就是您实际上可以立即改进的地方，因为您需要一些时间才能真正看到 Core Web Vitals 的改进，因为它是在一段时间内测量的。

所以如果你想提高你的分数，我认为 Lighthouse 是一个很好的工具，因为它为你提供——它告诉你有哪些机会可以提高。 因此，您可以立即尝试实施这些机会，看看它如何提高您的分数。

亚历克斯祖尼加：太棒了。 听起来像是对那里的 Lighthouse 大喊大叫。 出色的。 出色的。

MIKE CRANTEA：关于这个主题，我想补充一点，跟踪真实的用户指标性能数据更好，以便能够更快地对已经达到生产的性能下降做出反应。 当你在分期时，实验室测试确实有帮助。 就像说有一种我们不想传播的退化。 但是在生产中总会发生一些令人惊讶的事情。 无需等待数周时间让 Search Console 和 crux 数据库中的真实用户指标显示出来，通过使用 Web Vitals 库自行跟踪它们，您可以保持领先地位。

亚历克斯祖尼加：太棒了。 是的。 始终必须领先于有时会出现的生产意外。 好的。 好吧，感谢您回答有关测量的问题。 现在看看管理，你能做的一两件事对 Core Web Vitals 影响最大？

MATT CHASE：所以我想我突然想到的一件事是尽可能地延迟加载。 并尽可能推迟加载所有内容。 对我来说，这是一种交钥匙解决方案，你可以做到，并立即看到改进。 WP Rocket 有一堆非常简单的复选框，您可以打开它们来启用此类功能。

马克·达沃利：是的。 对我来说，重点是我们所说的折叠渲染上方。 因此，请确保尽快呈现。 如前所述，延迟和延迟加载屏幕外的任何其他内容，以确保您获得尽可能高的分数。 也就是说，WP Rocket 的延迟脚本功能非常出色。 但我们倾向于——就像我试图将其限制在 GTM、谷歌广告脚本或类似的东西上一样。 并真正专注于改进为网站提供动力的主题的实际核心架构，以确保尽可能优化。 所以你不依赖第三方插件来产生那种性能影响。

马特·蔡斯：哦，当然。 是的。 两端。

ALEX ZUNIGA：明白了。 知道了。 澄清一下，你说的是 WP Rocket。 这就是延迟脚本功能？

马克·达沃利：是的。

亚历克斯祖尼加：太棒了。

MIKE CRANTEA：没有得到足够关注的一件事是缓存。 但快速的服务器响应时间并不能保证快速的体验。 但是，如果您的服务器响应缓慢，那么您的体验肯定会很慢。 因此，利用所有可用的缓存层——浏览器缓存、对象缓存、页面缓存——并将它们打开并发挥作用是很好的第一步。 做你的基础知识。 然后你就可以开始工作——进行前端优化。 检查你的脑袋里有什么。 等等等等。

亚历克斯祖尼加：优秀

SANJUCTA GHOSE： 是的。 而且我认为我们也不应该忘记优化我们的图像。 我认为这非常重要，因为现在很多网站都倾向于使用大量图片。 所以我认为重要的是压缩图像，通过 CDN 提供它们，然后像​​您已经提到的那样延迟加载图像。 更重要的是，提供响应式图像。 因此，您可以使用图片标签或图像标签的源集属性来提供响应式图像。 我已经看到这确实带来了很大的改进，因为核心网络生命力是移动优先测量。 因此，提供响应式图像非常重要。 这是我们有时会忘记的事情。

所以我认为图像。 还有一些非常简单的事情，比如在构建步骤中最小化 CSS 中的 JavaScript。 我认为这也有很大帮助。 这很简单。

马特·蔡斯：是的。 关于这个主题，实际上，自从您提出这个问题以来，WordPress 分发了一种打包的 webpack 构建系统。 他们只是在 WordPress 脚本中调用它。 我们的代理机构为维护我们自己的 webpack 系统而苦苦挣扎了很长时间。 然后每隔八个月左右，一些节点依赖就会发生变化，并破坏我们的整个工具链。 但是 WordPress 为我们维护了这一点。 这是一个巨大的好处。

那里的 webpack 我们已经开始使用动态导入来构建我们的主要 JavaScript 包。 所以我们有点在运行时导入我们的节点依赖项，而不是将它们全部捆绑到一个主要的 JavaScript 包中，这让我们能够真正微调控制相同类型的延迟脚本加载。 仅在特定情况下。 就像我们的块在页面上一样。

马克·达沃利：是的。 此外，我发现确保您对网站上使用的插件非常有选择性非常重要。 安装第三方插件可能会导致很多意想不到的过时软件。 因此，请尝试将它们限制在信誉良好、构建良好的插件中。 并注意那些插件加载的内容。 它真的可以帮助控制站点的性能。 不幸的是，WordPress 仍然严重依赖 jQuery 进行后端使用等等。 但这对于前端来说并不是必需的。 因此，如果可能的话，放弃网站前端的 jQuery 支持，并坚持使用原生 JavaScript 确实有助于提高性能。

亚历克斯祖尼加：太棒了。 我认为我们已经开始涉足这一领域。 你提到了一些。 但是，让我们使用工具进一步了解它。 您喜欢将哪些首选工具用于 Core Web Vital 优化？ 它们最适合什么样的用例？ 或者在某些情况下它们不适合？

MATT CHASE：我的意思是，它以前出现过。 但实际上，浏览器内的 Lighthouse 工具是我真正喜欢的，因为它是立竿见影的结果。 正确的。 Core Web Vitals 很棒，但它的力量在于它是一个随着时间的推移而组合在一起的集合。 所以你不能真正改变一些东西并看到数字变化。 与 Lighthouse 相比，您在浏览器中进行更新。 您会看到本地开发环境并运行 Lighthouse 测试。 而且马上就可以看到，哦，我的成绩跳了15分。 凉爽的。 这是正确的做法。 将其推向生产。

亚历克斯祖尼加：太棒了。 您还喜欢使用其他工具吗？

MIKE CRANTEA： 我想对 Chrome 中的本地覆盖功能大声疾呼。 结合“性能”选项卡，您可以像外科手术一样改变网站中项目的加载顺序。 以及影响的大小。 它为您提供了必要的监督，让您了解为做出某种改变而付出的努力是否值得，或者您只是喜欢将其留在那里并专注于真正产生影响的其他事情。

MARK DAVOLI：我认为同样重要的一件事是服务器架构监控。 正确的。 因此，您可以拥有世界上最棒的 Core Web Vitals，但如果您的服务器承受异常沉重的负载而您没有意识到，您可能会突然发现您的第一个内容绘制急剧下降，然后影响几乎所有其他内容。 因此，请密切关注 New Relic 之类的工具或其他仅用于监控性能的工具。 密切关注以确保您拥有适当的基础设施来尽快呈现您的网站是至关重要的。

MIKE CRANTEA： 这就是启用缓存并做好准备的地方。

马克·达沃利：还有 CDN。

迈克·克兰蒂亚： 是的。 避免一些潜在的灾难。

亚历克斯·祖尼加：非常好。 好吧，我很欣赏那里的清晰度。 所以问题之一。 有许多优化插件可以优化 Core Web Vitals。 WordPress 插件的局限性是什么？ 还是他们真的在优化网站？ 或者他们只是在某种程度上可能会欺骗谷歌的测量结果？ 我想这可能是一个问题，我们是否提到过使用插件或完成工作而不是依赖插件更好？

SANJUCTA GHOSE： 所以我认为插件很棒。 例如，WP Rocket 就很棒。 我们经常使用 EWWW Image Optimizer。 我认为这也很棒。 但就像我认为已经说过的那样。 WP Rocket，你必须小心使用它，因为如果你打开延迟 JavaScript 功能，我已经看到它引入奇怪错误的情况。 一个错误。 所以我宁愿有时推出我自己的解决方案而不是使用插件。 前提是你有开发专业知识。

因此，我们为 Delicious Brain 网站所做的大部分优化都是我们自己推出的，而不是使用插件。 但话虽如此，我认为插件是一个很好的起点。 因此，当您刚开始时，您可能想要，例如，在您的暂存站点上部署 WP Rocket，然后试一试，看看它是否会破坏东西。 或者它是否带来了真正的改进。 所以我认为应该谨慎使用插件。 而且你必须知道后台发生了什么，插件在做什么。 以及它如何影响您的网站。

马特·蔡斯：是的。 值得庆幸的是，我认为 WP Rocket 在最近的版本中至少在非常清楚地标记他们拥有的危险开关方面做得很好。 因为我也曾多次被延迟的脚本所困扰——甚至是那些你不会想到的，比如 CSS 优化以某种方式破坏了模型，它没有得到说类名会使它们可见的东西. 所以那是令人兴奋的一天。

但是，是的。 WP Rocket 绝对是我的首选，除了明显的好代码，好代码。 正确的。 做这项工作永远是接近它的最佳方式。 插件可以自动化东西。 但是，没有什么可以替代让您的代码真正精简和精简。

MIKE CRANTEA：还有一个插件被标记为实验室类型的插件。 那是性能实验室。 它由 WordPress 性能核心团队完成。 尽管这听起来很可怕，但它在我目前的所有测试中都提供了完全的稳定性。 这对于它应该是什么以及最终在 Performance Lab 插件中的工作质量来说是非常令人印象深刻的。 所以值得一试。 几个复选框。 那里的一切都是安全的。 好吧，我不太确定数据库切换。 当我读到它时，这是更有争议的事情。 是的。 只是不要触摸那个按钮。 就像他们在插件中添加了 SQLite 支持或类似的东西一样，这绝对适用于一些较小的网站。

亚历克斯祖尼加：有趣。

马克·达沃利：是的。 对我来说，WP Rocket 太棒了。 我们确实限制了它在我们大多数网站上的使用，因为我们所做的大部分内容都是本地构建的。 但是 Core WordPress 中还有许多其他功能，如果使用得当，它们确实可以为您提供一个优化良好的网站。 就像使用块编辑器而不是像 Elementor 等第三方一样，会给网站增加很多膨胀。 因此，如果您像新的原生 Gutenberg 类型块系统一样构建，并真正根据需要加载文件，而不是例如在每个页面上一次加载所有内容。 WordPress 现在内置了延迟加载功能。 因此，监控它的使用方式并适当地使用它，等等。 然后添加一个像 WP Rocket 这样的工具来增强已有的东西。 但不能完全依赖它。

它可以帮助您到达那里，尤其是当您的网站运行不佳时。 但如前所述，就像关键的 CSS 生成一样，这些东西可能会有很多问题，因为它们会根据机器人在您的页面上看到的内容做出很多假设。 但它无法预测不会呈现初始视图的事物。 所以如果你有模型，如前所述，那些弹出，它不会知道这是一种可能性。 它不会为它生成 CSS，并正确地内联它。 所以就像做一些事情，比如预加载你的关键字体或在首屏上渲染它。 同样，这是关键。 真的是最重要的事情。

SANJUCTA GHOSE：关于关键 CSS 的话题，我只是想插话并提到 Addy Osmani 有一个很棒的工具，叫做 Critical。 您可以将其添加到您的构建过程中以生成您的关键 CSS。 这很棒。 而且非常可靠。 所以既然你提到了关键的 CSS，我想我会添加它。 抱歉打断你。

迈克·克兰蒂亚： 没关系。 关于关键 CSS 的同一主题，Jetpack 团队一直在努力使用 Jetpack Boost 插件做一些事情。 通过在 iframe 或类似的东西中呈现页面，这是一种非常非常有趣的生成关键 CSS 的方式。 当它工作时提供，这是一个很好的解决方案。 如果没有，它会告诉您，嘿，它在这里不起作用。 继续前进。 你需要别的东西。 获得关键的 CSS 并不总是那么容易。 另一方面，在 4 或 5 年前，关键 CSS 非常庞大。 它帮助了很多。

在过去的两三年里，随着 HTTP/3 的进步，拥有一个呈现阻塞的关键 CSS 对拥有 100 KB 或一些内联 CSS 的影响非常小。 使网站的运行速度与四五年前使用关键 CSS 的网站一样快。 所以不要害怕在您的站点中使用合适大小的 CSS。 你不必摆脱它。 我见过超级优化的网站。

我们拥有关键的 CSS，例如 100 KB 的内联 CSS。 以及渲染阻塞、jQuery 和其他两个未使用的脚本。 就像，耶。 你这样做是在破坏目的。 它可以帮助我们采用最后 5% 的方法。 但如果你从那里开始，请看第一个。

亚历克斯祖尼加：太棒了。 惊人的。 我认为所有这些工具。 很高兴听到那些喊叫声。 很高兴听到这些建议和建议。 很多这样的问题围绕着我们的下一个问题。 专门使用 Core Web Vitals 在 WordPress 上工作有哪些独特之处？ 是不是你必须通过插件来做到这一点，而不是通过任何其他技术堆栈来做到这一点？ 使用 WordPress 更容易吗？ 有更多可用的工具吗？ 正如我们刚刚提到的，你们都刚刚使用了很多工具。 使用 WordPress 更容易吗？ WordPress 更难吗？ 你们都拿什么？

MATT CHASE：我认为使用 WordPress 非常容易。 所以我们谈了一点——或者我提到了他们分发的 WordPress 脚本节点包，这是一种很棒的 webpack 构建系统。 他们还有 WordPress Create 块，这是为基于 WordPress 的网站引导自定义块的一种非常快速和简单的方法。 但它的构建方式使得很多胶水代码可以说是为您编写的。 所以它已经很聪明了——马克，你只在你应该提到的时候提到了这些脚本。 所以你知道你的街区是否正在做这件事。 你甚至不必考虑它。 所以 WordPress 使这类事情变得非常容易。

MARK DAVOLI： 是的，当然。 而且它是开源的。 正确的？ 所以你几乎可以改变任何东西。 因此，与 WordPress 相比，当您使用封闭系统来优化 Core Web Vitals 时要困难得多。 当 Core Web Vitals 首次宣布时，它还没有完全实现。 这更具挑战性。 他们在添加许多这些功能方面确实取得了长足的进步，尤其是块编辑器和基于块的构建等，以真正优化选择性加载资产、CSS 文件、字体文件等的能力。 嗯是的。 太棒了。

ALEX ZUNIGA：这可能是封闭系统与开放源代码的呼声。 去吧，Sanjucta。

SANJUCTA GHOSE： 是的。 是的。 我认为是因为有很多专门用于 WordPress 的托管服务提供商。 就像你说的。 WordPress 是开源的。 因此，围绕托管 WordPress 网站有很多优化。 因此，我认为如果您在 WordPress 之上构建，那里已经有很多可用的支持，这意味着您不必重新发明轮子。 所以我认为如果您在 WordPress 之上构建以优化您的 Core Web Vitals 肯定会更容易。

亚历克斯祖尼加：美丽。 所以我们已经讨论了我们如何衡量这些工具，我们用什么来实际增强我们的 Core Web Vitals，一些工具。 现在，当我们谈论客户期望时，您在新项目的哪个阶段开始考虑将 Core Web Vitals 作为构建或策略的一部分？ 当你像你的基本样板模板一样开始时，这是正确的吗？ 还是您在故事中进一步优化了一些东西？ 你们都做什么？

马特·蔡斯：是的。 我认为对我而言，它更像是一种构建事物的方式，而不是您对未优化的网站所做的事情。 这是从一开始。 它存在于您理想编写的每一行代码中。 我尽量不——我不想建立一个大的优化网站，然后再回去修复它。 我想从一开始就尽量写得干净利落。 然后通常，我发现这样做，在最后挤出最后一点优化汁液会更容易一些。

马克·达沃利：是的。 他是绝对正确的。 我们从一开始就开始构建它。 我的意思是，有些组件不会像接近尾声那样发生。 在临近发布之前，我们不会通过图像优化来运行图像。 但是你甚至不需要在构建本身，但有时甚至在设计过程中，如果你考虑到 Core Web Vitals，那么考虑网站的设计方式是很重要的。 因为在架构上，实现某些设计比其他设计更快更具挑战性。 因此，了解这一点并让设计人员了解什么可能会使实施变得更加困难，而不是什么可能会非常有帮助。

MIKE CRANTEA： 并规定限制。 嘿，你最多只能拥有 x 部手机。 您不应该将 25 及其所有变体带到桌面上。 这有助于设计阶段。 此外，如果在项目期间没有发生一些接触点，有时很容易完成一些事情。 就像一个 sprint 的七个请求，要求将测验插件添加到组合中。 如果不加以检查，您会在最后发现它。 所以我的建议是每隔几个冲刺就处理一次。 我们确实检查了我们对事物如何演变的阶段的自动测量。 最后被推动的事情发生了什么事情变慢了吗？ 我们是否需要提前采取任何纠正措施，而不是在项目结束时做出反应。

SANJUCTA GHOSE： 是的。 我同意。 从设计阶段开始非常重要，因为喜欢简单的事情，比如是否应该有弹出窗口、广告横幅或类似的东西。 有时，它可能会对您的累积布局分数产生巨大影响。 所以提前知道会发生什么是件好事。 无论您是弹出窗口还是横幅。您不希望在项目结束时出现意外。 因此，我认为从设计阶段就让客户或利益相关者参与进来非常重要，并告诉他们这可能会对您的 Core Web Vitals 产生影响，以便他们做出明智的决定。

MARK DAVOLI：这在发布后也非常有帮助，因为一旦您的网站上线，有时它可能就像，让我们在以后添加一个聊天小部件或类似的东西。 然后突然间，有一个扭结。 然后你必须考虑我们如何进行整合和优化。 因此，延迟脚本功能可以推送大多数广告像素，众所周知，这些像素会破坏您的 Core Web Vitals 分数。 但有时你不能拖延一些事情，因为这对客户真正想要的东西很重要。 所以尽可能地平衡它，并确保传达潜在的影响。 最终的结果就是尽可能快地获得它。 有时您必须为功能做出牺牲。 有时你不知道。 但是尽可能快地获取它以增加这些转化。

亚历克斯·祖尼加：非常好。 出色的。 所以我听到了这样的说法，比如更好的成分从一开始就可以打造更好的网站。 并不是说我们只是要在最后加入一些 Core Web Vitals。 如果您想首先以这种方式考虑，这确实是一种生活方式。 好吧，太棒了。 所以这是我们的最后一个问题。 在向客户传达您花在 Core Web Vitals 上的时间价值时，您是否遇到过任何问题？ 这是他们曾经推回的任何事情吗？ 他们不明白你为什么要做那项工作吗？

MATT CHASE：我认为我实际上从未遇到过任何形式的阻力。 如果有的话，这有点相反。 通常，这是我们想要的性能。 我们想要 Core Web Vitals。 一起让它成为现实。 我会说我们并不总是反思 - 我们谈到了跟踪像素以及它们如何因降低分数而臭名昭着。 但没人在乎。 我们就像像素、像素、像素、像素。 因此，人们在添加跟踪功能时需要考虑实际权衡成本收益，因为这并不像仅仅投入使用并获得结果那么简单。 因为有成本。

亚历克斯祖尼加：太棒了。

MIKE CRANTEA：我认为表演缺乏耐心。 所以如果你在想，哦，让我们在第一个冲刺之后做一些持续几个冲刺的性能工作。 我什么时候看到它？ 我什么时候看到它？ 计划以迭代方式发布它，例如增加一项功能，一项功能，一项功能增加了对这项工作所产生影响的信心。 你越多地看到这转化为转化和变化，就会越快地认识到价值，而无需花费大量时间进行教育工作。

马克·达沃利：是的。 我认为客户可能难以理解的一件事是真实用户指标与实验室数据之间的差异。 因为他们中的很多人可能会运行自己的测试等等。 并没有完全理解。 因此，帮助他们了解页面的原始摘要部分是见解，实际上是谷歌用来影响 SEO 排名和类似事情的部分。 因为他们中的很多人都在寻找那个分数并对其进行优化。 并帮助他们了解在全面了解您的变更对事物的影响之前，需要 28 天的时间来衡量生产中所做的任何变更。

ALEX ZUNIGA： 非常好。 大声喊出来。

MIKE CRANTEA： 我应该指出最令人困惑的指标之一。 交互性指标。 这些都是出了名的不稳定。 对于某些更害怕分数变化的人来说，我们构建的新功能是否显着降低了网站速度？ 然后就像再次进行测试一样，上升 10 点，然后下降 10 点。 解释这种变化非常耗时。 为什么不是只有一个数字是一致的？ 好吧，这与命名事物和缓存一样困难。

ALEX ZUNIGA：嗯，太棒了。 听起来我们真的很感谢你们所有的投入，你们对 Core Web Vitals 的所有反馈。 如何使用它们，用什么来衡量它们，如何为所有这些设定客户期望。 这真是一个学习的教训。 我们希望我们的小组成员在这里过得愉快。 我们非常高兴听到您的所有反馈。 我们希望这里的与会者也能得到一些很好的反馈。

所以你们所有人，非常感谢你们的时间。 好吧，那是我们的小组。 我们真的很想对我们所有的小组成员说声谢谢。 我们要感谢您参加这个小组。 我们希望您在 DE{CODE} 观看我们剩余的会议时玩得开心。