John Mueller：所以从实际出发，你如何保证快速实现网站的所有发布呢？比如，你一直在更新内容，营销部门添加了很多新的博客文章或者稍微更改了模板，对于网站来讲有哪些实用技巧可以遵循呢？
Annie Sullivan：我认为很多东西都可以通过实验室测试得到，思考你每次提交运行时候得到的东西。所以我们谈到我们有很棒的用户体验数据，这是你作为衡量的目标。但是实验室测试的更大价值在于能够给你海量的细节内容。所以或许你也知道在你网站上，如果有大量的js文件，或者图像未压缩，又或者发生了一些特定的问题，你可以提交测试一下。这样如果有人试图添加一个未压缩的图像，要么自动压缩，要么阻止提交，添加大型js库或其他东西也是以同样的方式。所以就像一种检测监控问题的糟糕类型的自动化测试一样，比如Lighthouse。Lighthouse就可以设置为添加到持续集成中，我认为这是一个非常有用的解决办法。
除了实验室，我们也能够在真实环境中检测用户数据。在谷歌有很多工具可以做到这一点，但如果你的网站足够大，可以实现真实用户的每天更新数据的监测，甚至我认为重要准则是每当你发布新版本，你能分离出真实用户数据监测中的老版本数据和新版本数据。或者如果你有关于网站变化的想法，分离出变化对真实用户数据监测的影响，这会帮助你更好地理解真实用户。
John Mueller：好的。我刚才听到你说了一件事，就是JS文件是不利的，对吗？
Martin Splitt：哇哦，让我们开始聊聊这个。
Annie Sullivan：不，我完全同意你的观点。我想说的是之所以选择这些指标来监测用户体验，是因为我们想要在某种程度上量化真实的用户体验。
Vivek Sekhar：我们更倾向于说JavaScript文件是具有挑战性的。
Annie Sullivan：对于一些网站来说，更多的JavaScript文件意味着更缓慢的页面加载；而对于另外的一些网站来说，他们以非常艰难地方式加载JavaScript文件，而这是完全不正确的方式。他们正在使用如整体响应这样的现代概念来说明JavaScript文件的调用，所以这种类型的事件不会发生。有请求空闲的时候回调API，可以使用不同的内容。所以我不想评价你使用了多少JavaScript文件，但是如果你知道你的网站差不多是这样：“好的，我修复了Lighthouse的问题，我的真实用户监测数据变好了。或许我又提交给Lighthouse，并且不会再犯这个错误了。”
John Mueller：好的。
Martin Splitt：这很有意义。JavaScript文件确实具有挑战性，并且实际上存在着很多问题。很多人的情况是：我有一个在服务器端渲染的网站，所有东西都是产生于服务器端。但是实际的HTML文件，需要一段时间才能把HTML文件从服务器端传给用户，然后可能再需要很长的时间去产生内容，因为几乎所有HTML文件都在那，整个DOM元素必须在那之后加载。对于用户体验来讲，这是比更快加载初始HTML文件更糟糕的事情，然后再逐步构建DOM内容等。核心网页指标有将此考虑在内吗，这是一个经常发生的问题。
Annie Sullivan：所以他们在多方面都考虑了这个问题。首先是最大内容绘制的监测是指当用户看到内容时，所以第一个问题：在服务器端渲染不是更好吗？或者也有人有别的问题：或许这使得服务器端加载花费了更长的时间，所以哪个更快呢？许多架构能够打开或关闭SSR，你可以根据你真实用户的监测数据来决定哪一个更适合你的用户。
第二个问题是：好的，我在服务器端渲染文件，有些JavaScript文件必须加载和提交的，这很慢吗？这可以真正地影响到你的首次输入延迟，但我认为使用hydration框架技术的人们应该监测他们hydration的时间，即用户与页面产生互动之间的时间。如果你不使用hydration技术，这可能与LCP很相近。但如果与LCP的数据很不一样，那你可能遇到了互动问题，也就是没有做好FID指标。我们曾经有一个很长的博文写了长期以来我们关于互动、反应的想法，也讨论了一些可能我们在未来做得更好的东西。
Martin Splitt：哇，这听起来很不错。
Vivek Sekhar：关于权衡的性质，有一个很重要的观点：有很多不同的方法构建页面，不同的框架、服务器以及客户端，这充满了选择性。对于开发人员来说有可能会不知所措，很多时候网站都只是继承了他们一直使用的东西，或者其他人建议他们使用的东西。但我认为在谷歌内部，我们在不断地评估我们所做选择的权衡，并试图找出作出不同选择的最佳时机。并且我认为，有一个共同语言来衡量我们想要的结果，这就是Core Web Vitals的价值所在，我们能够使用这些数据并且知道这些数据的定义在Crux上的呈现，同时也有助于提升你的搜索排名以及作为你的工具。这也确实有助于解锁所有类型的并且是作为良好项目实践必不可少的实验室测试，我的意思是项目是所有的权衡，并且我们在这么多案例的建议，仅仅是作测验并选择最适合你的方法，这就是我们所做的。
Martin Splitt：JavaScript尤其如此，就像任何 JavaScript 都需要在现实中进行测量和观察一样，因为不幸的是，答案往往取决于它本身。 所以我猜当你说像hydration技术时一样，我们可能必须解释什么是hydration技术。
Annie Sullivan：是的，假如你又一个动态站点，其中的JavaScript文件一定程度上可以挂钩到每个单个的DOM元素，所以基本上，这些站点的初始设计是服务器没有真正提供任何HTML；相反地，使用JavaScript脚本生成所有HTML，就像用DOM API一样，然后所有的HTML都会有事件处理程序，页面会同时准备就绪。当它对用户可见时，它也是可交互的。但如果你考虑一下web浏览器的工作方式，它会向服务器发出请求，然后它会返回一个HTML页面，并且加载脚本。所以，它向服务器请求脚本，然后加载脚本，脚本再制作DOM，或许在DOM中有图像。因此，当它获得构建页面的所需东西时，这个加载时间是真的慢。
所以人们会想，要是我在服务器端渲染，速度会不会更快。因此我们让服务器去理解JavaScript要做什么，产生所有HTML并且发送到第一个请求，以便你加载网页，发出请求，得到HTML。
问题在于我们首先在 JavaScript 中生成它的原因是所有这些 DOM 元素都将连接它们的事件钩子处理程序。 因此，只要您点击某个东西，比如菜单，它就会打开或发生别的什么事情。 因此，在服务器端渲染中，您基本上必须下载 HTML，然后将其渲染给用户。 同时，您正在下载处理它的所有 JavaScript，然后它会挂接到所有元素中。
因此，人们担心的是，将所有元素结合在一起称为水合作用。 那么发生水合作用需要多长时间？ 大多数框架都有一个可以使用的用户计时标记，你可以发送给你的真实用户监控，我认为监控和理解页面交互时间是非常重要的，重要性仅次于最大内容绘制。
Martin Splitt：太酷了，实际上我还有一个问题。我知道问出来可能有点蠢，你刚才有提到用户计时标记，那是什么？
Annie Sullivan：我们知道有很多 Web 性能 API。 有一些 JavaScript API 可为您提供有关页面如何执行的信息。 有一个用于 Largest Contentful Paint（最大内容回执），一个用于 First Input Delay（首次输入延迟），一个用于 Cumulative Layout Shift（页面布局移动），但这些都是非常高级的东西，对吧？ 这个用户体验指标是什么？ 开发人员显然需要了解更多有关其页面加载的信息才能理解，例如：“如果这些指标得不到我想要的东西怎么办？”
所以用户计时标记和测量，有一些 API 版本，无论是在所有浏览器中实现的一个还是两个或三个，你基本上可以说，性能标记这件事发生了。 你给它一个名字，然后你的分析脚本可以监听这些。 DevTools 也会将它们绘制在所有性能工具中，例如 WebPageTest 可以显示它们。 所以你可以制定你自己的指标，比如：“我用 JavaScript 实现这个事件需要多久？” 然后它将与您所有其他更高级别的用户体验指标叠加。 您可以使用它来了解页面上发生的事情，了解是什么导致用户体验指标需要很长时间。
Martin Splitt：这太酷了，令人赞叹。 我想我已经看到当您想要标记某些特定内容时，这些内容会出现在性能时间表中。
John Mueller：所以我遇到的一个问题是，如果您可以制定自己的指标，那么我们现在拥有的这些指标可能也会随着时间的推移而发展。 这是计划好的事情吗？ 或者您如何看待 Core Web Vitals （核心网页指标）不久的未来？
Annie Sullivan：是的，我的团队非常努力地研究新的用户体验指标以及更加全面地了解用户体验。我认为如果你有认真研究现在的Core Web Vitals（核心网页指标），你会发现它们非常专注于初始页面的加载。我们真正想要的是延伸至页面加载之后发生的全过程。所以你知道First Input Delay（首次输入延迟），那么剩余的输入呢？我怎么根据用户的每次输入响应来评价页面？对于不是真实用户输入的东西呢，比如动画？或者当你滚动页面时，页面是否卡住？我们正在研究如何衡量我们所说的平滑度，动画和滚动是否顺利进行？我们也在考虑改进现有的指标，更好地考虑单页应用程序之类的东西。然后我们正在研究如何长期扩展到用户体验的更多领域：可访问性、隐私、安全性等。
John Mueller：非常好。确实是这样需要不断有新的事物才能与时俱进，你有关于你一直在研究的这些想法的时间线吗？ 我不知道你是否期望，或许某个时候谷歌会突然说：“实际上，我们有关注的不同指标。” 你怎么看这种情况？
Annie Sullivan：所以老实讲，获得用户关于数据的反馈以及理解我们没有见过和分析过的特殊案例对我们非常重要，比如开发人员实际上如何与这个东西交互以及他们真正遇到了什么困难，所以我们做了表达我们想法的博客。比如我刚才说，我们写了一篇关于响应性的文章，我们还将写一篇关于单页应用程序的文章和一篇关于流畅性的文章。在写这些博客文章时，我们会受到初始反馈，然后我们考虑如何让开发人员更容易理解和应用，例如，他们会怎么处理这件事。然后我们尝试确保我们听取反馈。很难得到一个更严格的时间线，因为我们想确保我们已经在某种程度上整合了所有反馈并且我们真的在倾听开发者意见。我认为我们做了很多工作，比如开发人员的时间表如何排列，你想谈谈那部分吗？
Vivek Sekhar：耶，当然了。我认为这实际上回到了以用户为中心的观点。技术革新很快，人们每年都想采用一种新的框架或一种新的语言，但归根结底，用户不喜欢等待网页加载，他们不喜欢页面内容四处移动。自从网络诞生以来，这一直都是真理。因此，通过以用户为中心，我认为我们正在做一项合理的工作，将重点放在与 Web 体验有关的长久事物上，因为用户非常稳定，用户希望获得出色的体验，这一直都是真理。我们希望在一段时间内成为现实。所以我们的期望是这些指标将缓慢发展，指标集将保持相当稳定，开发人员可以真正支持它们，投资于工具并理解指标本身。随着技术发展，将会有一些改进，因为你知道没有人会第一次就做对。网络是一个如此庞大而充满活力的地方，因此我们绝对希望对网络的发展方式以及用户使用网络的方式的发展做出响应。但我们的目的是让这几年慢慢推出和完善真正针对用户偏好和用户体验的稳定性的指标。
John Mueller：是的，所以听起来像是你希望事情可以稳定一段时间。我们会让人们知道未来什么时候会发生变化。这很好，我们很多听众都非常关注SEO，这个核心网页指标也与我们宣告的排名因素有关，从SEO角度来讲，你觉得人们只需要关注速度指标吗？
Vivek Sekhar：我会说事情绝对不是这样的， 我们对 Google 和网络社区的速度感兴趣，还有很多其他方面的考虑。 我们知道，Web 是一种强大的媒介和平台，可以构建覆盖全球众多用户的应用程序。 当然，确保我还应该补充一点，排名信号很重要。 但还有很多其他因素影响着搜索排名，比如你的内容的相关性以及所有其他方面。 因此，虽然性能非常重要，并且排名肯定受到了多方面的影响，实际上我们的目标只是展示一个真正高性能的网站对网络业务的影响力。
John Mueller：你认为这对大公司来说更具操作性吗？ 因为听起来你必须有一个非常强大的开发团队来实际设置所有这些挂钩并利用好所有这些工具，确保指标运行良好。 这是否意味着小型网站在这里处于劣势？
Vivek Sekhar：我认为有两种方式来看待这个问题，我们观察到整个web生态以多种方式运行：一种是小网站通常有更垂直的业务并且有着更轻量级的网络体验，他们在努力把一些事情做好，这是他们真正优化的机会。随着公司的发展，他们也可能拥有更少的遗留代码或更少的旧框架，因为他们一直在使用。较小的站点和组织可能会更加灵活，他们可以采用新的措施，并且通常非常渴望采用新的技术实践，并且正在寻找下一件大事来发展他们的业务并取得成功。因此，我们看到小站点的开发人员对能够在他们的 ROM 分析提供商和他们的搜索控制台指标之间拥有一种共同语言的能力感到非常兴奋，并且将所有这些结合在一起并有意义，这确实可以提高小团队的能力。
但与此同时，即便是大型站点，我们看到的许多变化也不是特别复杂。我记得跟一个美国一级新闻出版商交流过，他们真的很关心插页式广告的问题，这会导致布局诱导动画，CLS分数会受到影响，但这种插页式广告是他们重要的收入来源，可以鼓励人们注册时事通讯或订阅他们的在线新闻内容，这对他们来讲非常重要。但是当我们查看他们的页面时，实际上他们可以采用类似 CSS 转换的东西，并实现几乎相同的体验，而没有必要大量布局诱导动画。这个例子说明其实并不需要多大的开发团队就能完成修改，我们希望这种事情会在网络上变得更容易和更普遍，因为这些最佳实践已经出现并且我们都专注于以这种特定方式优化用户体验。所以我认为对于大大小小的团队来说，这是一个创造真正极致体验的真正机会。
John Mueller：如果您使用的是 Shopify 或 Blogger 之类的平台，您是否在那里处于劣势？ 因为有些东西是你无法控制或者修改的， 你怎么看待这个问题？
Vivek Sekhar：这是一个很好的问题。 我们将平台看做平台组织的核心团队进行少量更改以加速数百或数千种不同的网络资产和网络业务的绝佳机会。因此，这是小型网站从其平台提供商正在进行的投资中受益的另一个机会。我们最近在 WordPress 上做了一些工作，在那里我们重新审视了他们的延迟加载策略，并提出了一种提高他们的 LCP 分数的方法，实际上违反了长期以来关于延迟加载图片的建议，也许首屏的图片不应该被延迟加载，这有助于提高你的 LCP 分数。
因此，一项更改可能会影响数千个站点和数百万用户。 因此，我们非常期待在这个生态中出现更多此类修复，至少对于某些开发人员而言，随着时间的推移，他们只会获得更好的性能，而无需过多担心。
John Mueller：非常酷。 我经常遇到的一个问题是，特别是对于一个小网站来讲，你不能自己做所有的事情。 因此，您最终会嵌入来自第三方的其他类型的工具和不同的特性的功能。 这对你有利还是不利？ 我的意思是，这是你无法真正控制自己的事情，对吧？
Vivek Sekhar：这是一项具有挑战性的工作，因为互联网的一大特点是它非常开放和可嵌入，我们可以以多种不同的方式组合和重新混合这些体验。 归根结底，我们衡量整个网站，衡量特定网站选择为其用户组合的体验， 这确实包括网站选择包含在该页面上的第三方功能或工具。 如果第三方的表现可能并不完全像我们希望的那样高或不高，这可能会带来挑战。
我认为这可以追溯到我们围绕整个生态所做的努力。 我们都在使这个生态系统快速发展并使互联网成为用户访问信息和服务的真正好地方方面发挥着作用。 当然，我们在 Google 非常重视这一点，我只想说我们还处于早期阶段。 我们推出了Core Web Vitals（核心网页指标），并将其作为排名信号包含在内，并且我们正在围绕它提供其他工具，但这是我们所有人都需要的社区对话。 我认为，当我们作为谷歌从生态系统获得反馈时，它真的很有帮助，类似于：“我喜欢这个特定小部件的一些控制，这个特定的添加元素能够优化我的 Core Web Vitals。” 我们非常认真地对待它并优先考虑它。 我们希望与这个生态合作，以鼓励 Web 开发人员使用的所有类型的不同第三方的东西。
John Mueller：所以基本上，试图嵌入这些的网站所有者应该去找提供它们的人，并推动和确保它们是以一种高性能的方式嵌入的。
Vivek Sekhar：当然是的。 他们应该知道我们也是盟友。 我的意思是，我认为我们有很多工作要做，以尝试了解当第三方嵌入到各种不同的环境中时，它们如何能够表现出色。 只是网络的多样性，理解这一点，衡量它，向第三方报告第三方的表现绝对是我们正在关注的事情。
John Mueller：人们有时使用的第三方设置之一是内容交付网络，这会是一个神奇的解决方案吗？
Vivek Sekhar：我认为 CDN 肯定有一席之地。任何加速内容交付的方法都会改善您的 Core Web Vitals 和整体页面体验。我不认为这是绝对必要的。我认为，这又回到了权衡。我认为有些事情我们可以在服务器上做，有些事情我们可以在客户端做，有些事情我们可以通过页面的内容和选择的 JavaScript 框架来做，因此很难一刀切地说，如果这是推动或反对 CDN，我认为这确实是针对特定站点的。如果您想接触全球观众，我们发现仅仅从纽约到伦敦，或从新加坡到悉尼获取比特币将具有挑战性。因此，绝对有机会将内容放在更靠近用户的地方。无论如何，这是当今全球网络资产的一种责任，当然这是谷歌很早就认识到并投入巨资的事情。
但我认为，如果您是为当地观众服务，那么要求会有所不同。 您实际上可能会发现，仔细查看您的图像是否经过优化，或者您是否加载了您最终不需要或使用的 JavaScript 框架，从而发现更多价值。 所以它真的是针对特定站点的，我不想说为了确保速度，每个人都需要使用CDN来绘制图片。
Martin Splitt：我在外面观察到了关于 CDN 的一件有趣的事情，我自己也做过。我并不为此感到自豪，但它确实有效。您可以使用 CDN 作为解决许多问题的方法。如果您没有开发团队可以帮助您实际重新部署具有优化图像的站点，那么某些 CDN 为您提供了机会，因为这是一个拐点，所有流量都进入 CDN，然后 CDN 在世界范围内重新平衡它，这是一个功能。但是另一个功能也是您的所有内容服务都通过 CDN。所以他们中的一些人有所谓的边缘工作者，而他们中的一些人则以不同的方式称呼他们。但基本上，您有机会作为 CDN 提供商的一部分运行优化。这是一个非常酷的解决方法，它可以快速解决您可能不一定会遇到的一些问题，而且我已经看到人们因此提高了他们的表现，这不一定是 CDN 的目的，但您可以将其用作类似的解决方法。这很酷。
Vivek Sekhar：是的，边缘计算的整个领域都非常引人注目，我认为在性能环境中真的很有帮助。
John Mueller：因此，从实际的角度退后一步，您将如何弄清楚从哪里开始？ 你会像Martin说的那样把所有东西都放在 CDN 上，然后等一个月看看会发生什么吗？ 或者你有什么建议给刚开始做这件事的人？
Annie Sullivan：所以我认为首先要做的最重要的事情是看看你的 LCP、CLS 和 FID 的实际分数是多少，使用谷歌站长工具看看你的数值是多少？ 这些页面来自哪些页面？ 然后看看这些并尝试找出最重要的事情。 像 Lighthouse 这样的工具有审计或重点，可以告诉你：“好吧，事实证明我的 LCP、我的 FID 很好，但我的 CLS 很糟糕。让我们在 Lighthouse 中关注它。让我们在开发人员工具中看看它。 ” 因此，请查看您的实际站点的值以及真实用户所看到的内容，然后将其用作深入研究的重点... 实验室数据太多了，我们谈到了有这么多可用数据是多么棒，但是还有比任何人都做的多。 用它作为一个突破点来研究你应该首先做什么。
John Mueller：所以你基本上会关注我的最差分数在哪里，然后尝试改进它？
Annie Sullivan：是这样的。
Vivek Sekhar：我认为这可以追溯到 Core Web Vitals 的名称。 我的意思是，这些是核心指标，对吧？ 这些是衡量用户体验的第一个指标，但它们绝不是 Web 开发人员应该达到的唯一有用指标。 还有大量额外的细节以及所有额外的诊断工具和建议。 所以是的，第一个字节的时间和服务器端的事情可能会说：“这是我的服务器有点慢”，或者需要很长时间......我的用户和我的服务器之间的连接延迟很高。 这些事情表明 CDN 可能会有所帮助，而如果这不是您的特定应用程序中的长期[pull]，那么还有其他领域需要关注。
John Mueller：哇！ 这么多东西！ 我们缺少什么？ 你有什么其他方面想给听众的建议吗？
Vivek Sekhar：我认为我们从合作伙伴、发行商和开发商那里听说的一件事是，需要关注的事情越来越多。 很长一段时间以来，无论是 SEO 代理机构、谷歌还是主要框架作者，我们都有一个很长且不断增加的最佳实践和潜在问题以及要阅读和研究的内容列表。 所以，我认为必须承认的是，其中一些东西可能让人不知所措，感觉有很多东西需要研究。
我认为我们对 Core Web Vitals （核心网页指标）的目标以及它帮助我了解整个网络性能生态系统的方式一直是，让我们首先从用户的角度来看它。他们看着自己的手机，它是一块玻璃，它向他们展示图像和文本，并让他们有机会与之互动。这实际上是一种非常深刻的简化，因为这样我就可以根据需要引入所有复杂性。因此，如果我点击一个按钮但它不起作用，这让用户感到沮丧，那么我知道哪些指标、技术和诊断可能有助于解决这个问题，我不必担心其他一切。所以我个人真的很喜欢这种努力为很多这些性能讨论带来的用户关注。这只是我认为我希望其他人看到其中价值的事情。我希望这成为我们看待创造真正伟大的网络体验的一种主导方式。
Annie Sullivan：不，我绝对同意这一点。 我认为专注于用户是你能做的最重要的事情。 这引导了我们得到的许多问题，例如：“我应该关心这个还是那个？” 进行用户研究或只是询问您的用户。 所有这些类型的问题，它确实可以帮助您缩小需要关注的范围并且知道什么是重要的。
John Mueller：哇，这里的信息量太多了。 很高兴能直接从源头了解，从你们所有人那里得到，感谢你们的加入。
Vivek Sekhar：感谢！这真的太好了。
Annie Sullivan：是的，非常感谢。
John Mueller：Cool！聊了这么多，我想我们可以结束这一集了。 感谢大家的加入。 总之，如果人们有任何问题或反馈，可以通过上面提到的邮箱地址进行提问。
Annie Sullivan：是的，所以对于问题，我们通过 Stack Overflow 提供支持标记带有 web-vitals 标签的问题。 然后，如果你想提供反馈，你并不真正喜欢某个指标的某些属性，你想改变它，或者你想让我们了解一个用例或更好的东西，那就来google.groups.com 上的 web-vitals-feedback。
John Mueller：太好了，我们也会在说明中提供这些链接。 因此，如果您一直在听，但没有完全听懂，也请查看说明链接。
好吧，我们一直在享受这些播客剧集的乐趣，我希望作为听众的你也发现它们是有用的、有趣的和有想法的。并且无论您喜欢这些内容的方式如何，请告诉我们是否有我们应该讨论的主题。 例如，请随时在 Twitter 上向我们发送便条，或者就我们将参加的下一个虚拟活动之一与我们聊天。当然，别忘了点赞和订阅。再一次谢谢大家，再见！