您好，首先我想说我不是那种会追逐 SEO 或不遗余力地迎合 Google 对我的网站外观和工作方式的“要求”偏好的人。但值得注意的是，Google 刚刚给我发了一封关于我的网站需要改进其新的“核心网页指标”的电子邮件，该指标很快将成为其排名的重要因素：
这是 Discourse Meta 上的报告，其中 INP 比我的网站稍差（372 毫秒 vs 208 毫秒）：
考虑到 Discoursebasically 是一个 Javascript Web 应用，我认为要改进这些指标并不容易。但话又说回来，Google 似乎是基于其网络爬虫看到的无 Javascript 版本来确定其排名，尽管它声称正在模仿 Moto G Power 手机……
……所以我并不真正相信或太在意它们的算法和排名决定。但对于开发人员和网站管理员来说，了解这一点是值得的。
您好 @rahim123 - 改进 INP 是将 Discourse 的页面导航动画从完整的页面“加载指示器”切换为滑块的动机之一。我们上周才将此更改部署到 Meta，因此 Google 的网页核心指标调查数据中显示此更改还需要一些时间。
但请放心，我们会密切关注数据，并在需要时进行进一步调整。
非常感谢您的回复。很高兴得知您正在处理此事。
我使用了 Google 的实时网址测试工具 https://pagespeed.web.dev，这难道不应该已经包含在排名中了？而且由于 Google 看到的是无 JavaScript 版本，我不确定它是如何考虑加载指示器与滑块的？INP 是否与在同一网站内从一个页面导航到另一个页面有关？如果是这样，我不太明白它是如何针对单个网址衡量该指标的。抱歉我的无知，我远非精通页面架构和 Google 最新怪癖的专家。
是的，“PageSpeed Insights”和 Google 的搜索爬虫会抓取 Discourse 的基本 HTML 版本。因此，不幸的是，这些按需工具对我们帮助不大。
对于搜索排名，Google 使用从桌面版和 Android 版 Chrome 用户那里收集的真实用户数据。他们会在 Overview of CrUX | Chrome UX Report | Chrome for Developers 公开这些数据。不幸的是，数据收集和发布之间有 1-2 个月的延迟，这就是为什么我们需要等待一段时间才能看到这个新的加载滑块的实际影响。
要查看您自己网站（或 Meta）的 Google 数据，请访问此处并输入域名：https://developer.chrome.com/docs/crux/dashboard/。加载报告后，左侧有一个“INP”选项卡。据我所知，Google 在搜索排名中主要关注“移动设备”数据，因此您需要使用设备过滤器来深入了解。
Meta 的移动设备数据：
目标是至少达到 75% 的“良好”——这意味着 Google 用于搜索排名的 P75 INP 值小于 200 毫秒。
哇，我之前都没听说过。非常感谢你的解释！
作为一个数据点，自从我的网站上线以来，我一直专门使用 discourse-loading-slider 主题组件。我仍然处于“有待改进”区域
特别是，似乎主要由匿名用户通过 Google 访问的页面表现最差。可能仅限于我的论坛，但我觉得值得分享。
大卫，这确实是一个巨大的改进，尽管我还是喜欢旧的旋转器 
你能提醒我一下，这次改进背后的高层技术方法改变是什么吗？这有记录在案的地方吗？
对 INP 的改进？
使用旧的加载动画时，序列是这样的：
使用滑块时，我们跳过了第 2 步。滑块会立即渲染，无需等待昂贵的拆除过程。
我应该在这里澄清一下：我们切换默认设置的主要动机是改进用户体验。INP 指标的改进也很好，但并不是改变的主要原因。
是的，最重要的是观念，而不是过早删除内容，这很贴心。做得好！
需要特别注意的是，INP 将在 2024 年 3 月才会影响网站排名，因此我们今天正在进行的改进有时间在它开始影响 Google 之前进行迭代。
我也很喜欢旧的。我们是否可以为旧的旋转器提供一个主题组件（或者也许是一个用户设置）？
有一个系统范围的设置可以切换回来：“page loading indicator”（页面加载指示器）
没错，但有些人确实喜欢新的设置，我也不想去更改他们的设置。
另外，据我回忆，那个切换选项计划很快就会被移除。
哦，我以为他们是最近才添加的？
没错，但请看这个：
对于您自己的域名数据，例如 meta.discourse.org，在 Google Search Console 中始终有一个最近的报告，隐藏在“体验”–>“核心网页指标”–>“移动设备（打开报告）”中，然后向下滚动到“INP 问题：移动设备长于 200 毫秒”。
INP 可能受到 Matomo 核心或插件的发布后“处理”（= 加载时的 JS 功能增强）过程的影响，这些过程执行一些“繁重”的 JS 任务，具有较长的“渲染阻塞时间”。
特别是当用户切换到另一个帖子时，会有大约 10-20 个帖子同时被“处理”。
在这里，最好将单个帖子的任务拆分到单独的 setTimeout() 中，以便浏览器可以在各个任务之间进行绘制，而不是等待整个过程完成。
例如，类似这样的东西：
var initializeSliderSlickItem = function (item) {
/* 在此处执行实际初始化 */
var $this = $(item);
[…];
};
$('.slider-slick').each(function () {
var item = this;
setTimeout(initializeSliderSlickItem, 0, item);
});
你确定吗？当从一个主题切换到另一个主题时，下一次绘制将是页面顶部的加载器，它会立即开始。
…然后开始渲染。如果用户在 Discourse 渲染任务运行时点击了某个东西，Google 会将 INP 衡量为直到下一次绘制的时间。下一次绘制最早可能在正在运行的渲染任务完成时出现。
“交互的生命周期。输入延迟发生在事件处理程序开始运行之前，这可能由主线程上的长任务引起（例如“渲染”）。然后运行交互的事件处理程序，并在呈现下一帧之前发生延迟。”
如果“在整个页面的生命周期中”存在多个阻塞事件，Google 会将最长的绘制阻塞时间计入 INP。生命周期如下：
另请参阅 web.dev: INP：什么是交互
“当用户离开页面时计算 INP，从而得出一个单一值，该值代表了页面在整个生命周期中整体的响应能力。”
好在使用了该指标的 p75，意味着没有人需要真正担心你描绘的这种情况，而且这显然不能代表与 Discourse 的正常交互。
