当然可以做出这一更改（让所有匿名用户看到 HTML 视图），但这会严重影响匿名用户的可用性。是的，他们确实能更快地看到内容，但大量原本对匿名用户有效的功能将失效，而且网站对匿名用户来说也会显得“不正常”。
我们或许可以将此作为某种站点设置，以便您进行实验，但像“无限加载”这样的功能将不再对匿名用户生效，这里存在非常高的代价。此外，我们还需要投入至少部分工程资源，为 /login 路由设置绕过机制，以便用户能够实际注册或登录。
9 个赞
是否有可能让匿名用户首次访问时看到的是 HTML 视图，但如果他们继续浏览，则提供完整功能？这似乎是一个不错的解决方案（不过我不确定搜索引擎是否认可这种做法）。
这听起来确实不太理想。有没有办法先提供静态版本，然后再“注入”动态内容？这可能涉及大规模架构调整，所以或许不太现实。目前，我们网站从 5 月开始出现了 49,000 个 LCP 错误，搜索流量也同时受到影响。我们当前的 LCP 得分平均为 5.3 秒。我正在寻找降低这一数值的方法。
也许是添加或移除一些插件？增加或减少分类数量？将静态资源放到 CDN 上？我们去年冬天曾尝试配置 Cloudflare，但未成功，不过可以再次尝试。我对 Discourse 的架构不太熟悉，所以希望能得到一些指引。
3 个赞
这正是我们发现的情况：我们正在尝试移除所有插件，甚至广告（现在我们的网站没有广告，图片已优化等），我们成功将 LCP 降低到了黄色区域边缘。现在这不再是一个错误，而更像是一个警告，但仍会影响我们的网站。我们注意到此后有轻微上升，但需要更多时间来确认……
说实话，我真的很想启动一个基于 Nuxt+Vue.js 的 Discourse 开源克隆版，或者在其基础上构建一个封装层，这似乎是当前唯一合理的选择！
2 个赞
是的，除非进行一些重大的工程优化，否则无法减少初始加载时间，因为你需要下载整个 Discourse 应用。
更令人头疼的是，Android 上的 JavaScript 性能通常比 iPhone 差……而且据称，谷歌在“真实世界”移动指标中只统计 Android 设备。而在 Meta 平台上，iOS 约占移动流量的 40%。
12 个赞
在此我只能说，我们已注意到 FCP 和 LCP 加载速度较慢的问题，并制定了长期的改进计划。
具体来说，@eviltrout 正在将我们升级到 Ember CLI。完成后，我们就可以开始考虑并可能尝试代码分割及其他优化技巧。
这里没有简单的捷径：我们使用了 CDN，对资源加载方式进行了非常审慎的设计，并为此投入了无数小时进行优化。但根本上，我们使用 JavaScript 来渲染页面，而在首次加载时，JavaScript 的传输、解析和执行都需要时间。
26 个赞
抱歉再次提起这个旧话题，但经过过去几个月的测试，我获得了一些新的数据……
以下是我一直在测试的两个网站：第一个是从 Discourse（EmberJs）迁移到使用 Vue 和 Nuxt 自定义构建的前端网站；第二个是 Discourse 网站，去除了广告、自定义字体以及所有可以移除的内容，以使其尽可能轻量化（这确实帮助我们将 LCP 错误从“错误”级别降到了“警告”级别）。
1. Discourse 论坛（移除了自定义字体、广告、插件等）
如您所见，5 月份更新后我们的关键词排名下降了 50%。10 月我们开始实施这些改动，这曾短暂带来了一些提升，但随后又回落了！就好像存在某种阻力（换句话说，受到了 Google 的惩罚）。
如上图中所示，我所做的改动（移除所有额外内容）帮助 URL 从“较差 URL"提升到了“需要改进的 URL"，但即便如此也未能带来实质帮助！
2. 自定义 Vue/Nuxt 前端 + Discourse 后端
在这个网站上，正如一个多月前所观察到的那样，其表现已逐渐回升至 5 月 4 日之前的水平。
结论：
是的，Google 确实关注 LCP！
希望 Discourse 团队现在能更加重视这一点。或许放弃 Ember 是值得的。我在一个大型项目中不得不这样做，虽然迁移成本很高，但确实非常值得。
11 个赞
我也同意 LCP 是一项相关的惩罚措施。我一直在关注这个讨论帖。目前针对该问题尚无具体的建议。
3 个赞
感谢反馈！我认为以下情况仍然适用：
ember CLI 的升级工作仍在进行中，并已取得进展。但如果您在等待我们完全脱离 Ember，或许可以考虑其他平台，并可在一年后再次关注我们的 LCP 进展。
14 个赞
我不确定 Discourse 升级到 Ember CLI 是否值得，但谁说得准呢？我们在另一个项目中有过类似的经历，最终不得不完全弃用它。升级到 Ember CLI 所付出的努力几乎与升级到 Vue 或其他框架相当。
无论如何，我的研究只是为了指出这个问题，并得出一个结论：在早期阶段，几乎所有人都否认 LCP 与排名有任何关系。
6 个赞
我们大约已经完成了 90%，这本来就在我们的长期路线图之中，因为它能带来大量的开发便利，并让我们跟上 Ember 的最新进展。@eviltrout 可以就具体细节提供建议，因为他负责这项工作。
是的，但这并不意味着每个网站都会转而采用静态 HTML 渲染，以便凭借神奇的 SEO 快速页面加载“超能力”主宰网络。事实证明，页面上的实际内容对于排名同样至关重要 
你可以查阅 Google AMP 的历史，看看这种对 单一 指标的过度关注如何导致大量的创伤和错误的工程工作。
15 个赞
这正是我试图在我的帖子中反驳的观点。Google 已经拥有大量质量尚可的内容，因此如果它们要基于用户满意度来做决定，我相信 LCP（最大内容绘制）将是它们判断的最低标准。毕竟，Google 在更新发布前几个月就已经对此发出过警告。
说实话，我在 Ember CLI 上积累了很多经验，它的糟糕程度和以前一样。加上升级的投入，我不确定是否值得。但我们会拭目以待，希望 @eviltrout 能提供一些意见，看看他们是否观察到任何速度提升。
遗憾的是，根据我上面的研究！Google 实际上非常关注用户体验和 LCP。我们尝试过其他所有方法。而且，正如你在第二个网站上所见，我们除了消除 LCP 错误外什么都没做，但这让我们得以恢复所有排名（事实上，截至目前我们已经做到了）。
希望这有所帮助，
5 个赞
你能具体说说你不喜欢 Ember CLI 的哪些方面吗？请提供示例。
3 个赞
我们在创业初期开始使用 Ember CLI，原因之一是看到 Discourse 也在用它（这引起了我们的注意）。我们进行了测试，发现它上手容易、开发便捷，但它过于臃肿（此外还有其他原因）。
Ember CLI 近期推出了一项更新，要求所有基于 3.0 之前版本编写的应用都必须重写。正是这一点促使我们决定彻底弃用它。
是的，Ember CLI 支持懒加载，但效率极低（至少在我们进行的测试中如此）。而且，市面上大多数为 Ember CLI 编写的库要么已过时，要么漏洞百出，迫使我们不得不自己实现大部分功能，或者克隆旧仓库并自行维护。
无论是否使用 Ember CLI，其渲染性能一直表现不佳（这无助于我们在此讨论的 LCP 问题）。
除此之外，Ember 的工作方式也容易导致应用变得臃肿。
真希望我还保留着当初决定换船之前所做的旧数据分析。我们刚在几个月前完成了从 Ember 到 Vue 的迁移，现在我对应用的性能和开发速度感到非常满意。
附注：我还没来得及查看 Discourse 的代码库，但升级到 Ember CLI 可能会带来更多麻烦，因为你们之后还得再次升级到 Ember Octane（该版本甚至尚未稳定），而且其语法完全不同……总之，坦白说，这简直是一团糟。我不确定当初选择 Ember 的那些理由现在是否仍然成立 @Jeff。
希望以上说明清楚。
4 个赞
“重视”具体指什么？是烧毁整个生态系统并从头开始吗？
Discourse 是一个不断发展的项目，我们非常清楚这一问题，正在考虑采取缓解措施，例如 fastboot、更激进的代码分割等。所有这些都在等待我们的 Ember CLI 升级完成后进行。
我很想看看这个替代前端方案。能否私信发我一个链接？从根本上来说，实现一个不可自定义的纯 HTML 视图是轻而易举的。我们提供纯 HTML 视图，你可以在 samsaffron.com 上看到其 LCP 表现非常出色，这仅仅是一个渲染 HTML 的 Discourse 插件。
7 个赞
亲爱的 Yassine，
总的来说，我同意您关于 LCP 和谷歌 SEO 的观点，也非常感谢您的分析和见解。
能否请您解释一下，如果谷歌真的像您倡导的那样广泛使用 LCP，为什么我在我们的 Discourse 论坛上发布的两个主题（根据谷歌的标准，它们的 LCP 非常差）却在 3,580,000 个条目中分别排名第 1 和第 2？
请参见：
在我看来，如果 Discourse 单页应用（SPA）的 LCP 问题真的像您倡导的那样严重（我绝无挑衅之意，只是基于您的专业知识感到好奇），为什么像我们这样不使用任何 CDN 且 LCP 极差的慢速网站，能够在发布仅 11 天和 13 天的主题中占据前两名？这两个主题在将近 350 万篇其他帖子中分别位列第 1 和第 2。
我真的很想知道，如果谷歌的 LCP 指标如您所呈现的那样具有如此大的影响力，为什么我们 LCP 表现极差的网站却能获得如此出色的搜索结果页面（SERP）结果。
谢谢！
4 个赞
根据你的例子，答案似乎非常明显：你搜索的是相当具体的术语，在这些术语下，几乎没有 LCP 表现更好的竞争对手。当你是唯一的存在时，成为“最佳”就很简单。正如上述帖子所述，内容仍然是最重要的因素，但当有大量内容可供搜索时，其他因素就会变得重要。你甚至可能是在证明他的观点，而非相反。
我知道上面已经提到过这一点，但能否生成一个快速的、仅静态 HTML 版本的论坛，并将其提供给搜索引擎使用？（禁止它们爬取注册用户实际浏览和发帖的真实论坛）。
你说有一个插件可以生成静态视图？这个插件是否对所有人开放使用？
2 个赞
这似乎仍然是一种“猜测”，尚未被证实为事实，对吗？
根据谷歌和其他来源的说法，LCP 目前还不是排名因素，并且直到 2021 年 5 月之前都不会被用作排名信号，是这样吗？
在我看来，基于少数声称 LCP 现在已影响 SEO 的人所提供的分析和图表，就推动 Discourse 团队对其生态系统进行重大调整，似乎有些过头了，毕竟谷歌声称该信号尚未启用。
LCP 信号目前是否已启用？
谷歌表示，LCP 目前尚未被用作 SEO 信号。
顺便提一下，我绝对不是 EmberJS 的粉丝，也同意 LCP 很重要。我只是在寻求基于确凿证据的事实。
我唯一的“观点”是，当我阅读这个帖子时，感觉大家正极力向 Discourse 元讨论区施压，要求基于某些目前根据谷歌及其他 SEO 专家的说法尚未作为 SEO 信号使用的因素，进行重大的结构性调整。
你们是在说谷歌对公众不诚实吗？
顺便一提，谷歌作为一家上市公司，欺骗公众的可能性极低。这将使谷歌面临巨大的潜在财务责任。
5 个赞
说得对。我自己对 LCP 了解不多，我承认这一点。我只是基于这个主题中提到的内容，你是对的，我不确定它是否准确（除了这里提供的证据）。所以，请阅读我的帖子，将其视为“如果 LCP 的说法是正确的”。
2 个赞
你的结论（我认为是指 Google 并未将 LCP 用于确定搜索排名）可能没错，但你得出该结论的路径并不成立。
-
这是一个非常独特的搜索词，以至于 Google 提供了拼写修正建议。可选结果并不多。
-
你需要进行大量搜索才能得出任何结论。如果我搜索“+discourse +gon”，你的网站根本不会出现在结果中，排名第一的是 The Discourse Encouragement Fund
-
此外，我认为 Google 会个性化搜索结果。对你而言，你最常访问的网站可能排在首位，但对其他人未必如此。对我来说，排名第一的是 https://meta.discourse.org/c/plugin/22。我通常使用 DuckDuckGo，所以也许这个结果根本没有经过个性化处理。
以上这些内容既未说明也未证明任何关于 LCP 的事情。这是一个很有趣的话题，我期待它继续深入探讨。就我个人而言，我对 Discourse 的速度感到满意。
3 个赞