neounix
2020 年11 月 23 日 13:25
91
完全同意。我之前的快速搜索结果并非重点，也绝无意将其作为任何权威测试；我在发布时也没有做出此类声称。我只是基于我的搜索结果提出了一个问题。我本应在搜索前退出登录，因为当我退出登录后，也会得到同样的“缺乏”结果，哈哈。
我唯一提出的“具体技术观点”是：Google 已公开声明，他们将从 2021 年 5 月开始使用 LCP（以及其他核心网页指标）。
我还提出了一个商业观点：Google 不可能做出此类声明并欺骗大众。对于一家大型上市公司而言，这将是一个巨大的错误。我推测他们不会犯这样的错误；当 Google 表示他们尚未将 LCP 作为排名信号时，我没有理由不相信他们。
如果那些出于好意、主张 LCP 正在影响 SEO、确信“自己的发现”并因此呼吁 Discourse 对其代码进行结构性修改的发帖人能够公开代码供审查（因为是开源的，所以每个人都可以检查），那么他们的“证据”在经过同行评审后可能会很有说服力。
这绝非针对个人，也毫无敌意。事实上，我们只看到了一些图表，却没有看到任何代码；而 Google 已公开声明，他们目前甚至尚未将 LCP 作为 SEO 信号。
本着“技术上的公平”原则，我们实际上并没有看到任何“证据”证明 Google 目前正在使用 LCP 作为信号。这仅仅是一种猜测，而且没有任何可供同行评审的代码来支持这一说法。
在座的各位都想知道需要进行哪些更改来优化 SEO 并增加收入。然而，我们需要确凿的事实和可供审查的代码，以让我们确信 Google 确实正在使用 LCP 作为信号。
Google 声称他们目前并未将 LCP 作为信号，并将于 2021 年 5 月开始将其作为 SEO 信号使用。到目前为止，我们没有任何理由怀疑 Google 的公开声明；也没有看到任何“经过同行评审的确凿证据”与之相悖。
希望这能有所帮助。
4 个赞
Mevo
2020 年11 月 23 日 13:37
92
所以，对于那些抱怨 2020 年 5 月的人来说，那与 2021 年 5 月可能到来的情况相比简直不值一提？
2 个赞
neounix
2020 年11 月 23 日 14:00
93
是的，我完全同意你的观点，也理解大家在这里对 LCP（最大内容绘制）以及 Google 核心网页指标（Core Web Vitals）将产生的影响所表达的担忧。
此外，我高度赞赏所有正全力以赴寻找应对这一迫在眉睫问题的答案和解决方案的人。
关于 2020 年 5 月的 SEO 崩溃事件，我们在使用 LAMP 服务器时也遭遇了同样的问题；因此，这绝非 Discourse 本身的问题。我们至今仍不清楚修复 2020 年 5 月问题的确切步骤，因为如果我们能高度确信地知道该修复什么，那么所有人都可以“修复”并“调整”。
多年来，我们都目睹了 Google AI 产生的一些非常奇怪的结果，以及 Google AI 如何对内容进行分类并操纵 SERP（搜索引擎结果页面）排名。
我之前的观点是，在这个话题中看到有人基于假设、猜测而非基于可审查代码的硬事实，就敦促 Discourse Meta 团队对其整个生态系统进行非常重大的结构性改变，这在我看来是缺乏依据的。
话虽如此，LCP 的重要性将在眨眼之间变得至关重要。
祝好。
4 个赞
Falco
2020 年11 月 23 日 17:06
94
Discourse 一直以来都是这样运作的：laughing:
新情况是，LCP 数据是从用户的安卓手机上采集的。安卓是我们运行的最慢平台，这对我们的影响尤为显著。
@sam 的建议是通过插件为部分匿名用户提供该视图，但这并非我们近期会实施的内容。
7 个赞
Mevo
2020 年11 月 23 日 19:10
95
好的。我对它的具体运作方式还缺乏了解（但看起来初始加载确实还存在一些延迟，而且本可以更快。这也是整个话题的由来）。这个讨论其实在 10 月 14 日就已经出现过了，就在上面。Jeff 本人其实提出了这个想法：
为什么不提取内容并创建一个完全预生成的静态网站呢？做到尽可能快 。然后将它提交给搜索引擎，而不是实际的论坛？这个想法是：这里最重要的是内容，而不是体验。专注于交付速度，因为这似乎是搜索引擎看重的。
无限滚动最近没有被归咎，但你可以创建没有无限滚动的静态预生成页面 。并且你要像设计拉力赛车一样设计它 ：任何不是绝对必要的重量，都要把它去掉。没有汉堡菜单，没有标志，没有发帖者的头像。你只专注于内容和速度。
这就像一家不错的餐厅（=Discourse 论坛），你在那里设立了一个得来速（drive-in）外卖窗口。同样的美食（=内容），但没有任何体验。你在入口处的扬声器处下单（=在搜索引擎上搜索），然后食物被预先包装好扔进你的车窗。整个理念是：这是被需求的东西，只有食物（=内容）和交付速度是重要的。如果人们喜欢这食物，也许他们会回来享受里面的完整体验。
之后，就由每个所有者（=管理员）做出选择：你认为得来速对你的品牌有害并拒绝这样做，还是为了吸引更多人而选择这条路线，即使知道许多人可能永远不会进来用餐（很多人已经这样做了，但情况可能会变得更糟。而且你的餐厅以这种方式呈现可能会显得没那么好）。但也许那个著名的推荐餐厅的网站会给你送来更多人（这还有待观察是否有效）。
所需要的只是一个插件或模块，用于在内容添加到论坛时生成这些静态页面 （我想这不应该过于复杂）。你只需要在适当的地方添加一些指向实际论坛的链接（该论坛对搜索引擎设置为“不抓取”）。是否使用这个解决方案将由每个管理员自行决定。
如果上述内容在原则上是正确的，并且这个问题在未来可能会变得更糟，那么这似乎是一个我可以接受的解决方案。或者也许我没理解清楚。（注意： 所有这一切当然是只读 的）
1 个赞
Falco
2020 年11 月 23 日 19:15
96
Mevo:
然后向搜索引擎提交这个，而不是实际的论坛？
我们早已为爬虫提供纯 HTML、无 JavaScript 的版本了🙃
正如我上面所说，问题在于新的 LCP 评分是从用户的浏览器中捕获的，而不是从爬虫那里。
7 个赞
Mevo
2020 年11 月 23 日 19:19
97
好的，但我不明白的是，在这种情况下，难道没有人表现得更好吗？这为什么会影响搜索结果呢？如果 Discourse 网站的表现和其他网站一样（“一样好”或“一样差” ;)）。其他网站不也在 Android 上打开吗？
2 个赞
Falco
2020 年11 月 23 日 19:25
98
Android 的单核性能低于平均水平，这影响了 Discourse 等重量级单页应用的运行。我们在《2015 年 Android 上的 JavaScript 现状……不容乐观》一文中对此进行了深入探讨：The State of JavaScript on Android in 2015 is… poor
在渲染 Discourse 时，顶级 iPhone 的速度比上一代 Pixel 快 10 倍。Google 并未将 iPhone 的渲染纳入 LCP（最大内容绘制）的考量，原因在于 iOS 上并没有真正的 Chrome 浏览器。
9 个赞
Mevo
2020 年11 月 23 日 19:33
99
Falco:
会影响重量级单页应用
因此，确实可能在生成“小页面”网站并提交给搜索引擎方面具有优势。这样做不值得吗？（也许不值得）。或者管理员需要向用户提供全新的高端手机？
感谢你的解释，Falco！
1 个赞
快速浏览一下 Overview of CrUX | Chrome UX Report | Chrome for Developers 可以发现，Google 似乎是通过（经用户许可的）监控用户来获取信息的。所以，你得说服很多人来使用你这个“穷人的 Discourse”才行
4 个赞
eviltrout
2020 年11 月 23 日 20:06
103
看来您可能混淆了 Ember 和 Ember CLI。Ember 是我们一直在使用的框架（已使用了 8 年以上）。Ember CLI 是我们正在迁移使用的命令行工具，以替代 Rails 的资源管道（asset pipeline）。我提到这一点是因为您说的一些内容（例如“3.0 之前版本需要重写”）对于 Ember CLI 来说并不成立，但对于 Ember 框架本身可能是成立的。
再次强调，Ember CLI 并不负责渲染。负责渲染的是 Ember，而它有时确实存在性能问题。请注意，这并非 Ember 独有的问题——所有主流框架都有需要警惕的性能陷阱。在多年使用 Ember 的过程中，我们识别出两个关键路径（头部和主题视图）需要更好的性能，因此转向了基于虚拟 DOM 的方法。
我们未必总是需要这样做，这取决于 Glimmer/Ember Octane 的最终表现。不过，目前的代码非常稳定，即使在旧款移动设备上也能快速运行。
Ember Octane 于 3.15 版本引入，此后已发布了两个 LTS 版本（3.16 和 3.21）。我们将分阶段升级至该版本。幸运的是，Ember 团队允许您选择采用哪种格式（甚至支持按文件单独选择）。
话虽如此，Ember 确实有不少值得批评的地方。在性能曾是 Discourse 更大挑战的时期，曾有几次承诺的发布最终反而给我们带来了麻烦而非帮助。那是一段艰难的时期。为了满足我们的需求，我们不得不长时间密切关注其动态。
如今，Ember 的流行度也只有像 React 这样较新框架的一小部分。不过，React 在 8 年前还不存在呢！当时我们的选择只有 Angular、Ember 和 Knockout。如果您认为升级 Ember 很困难，不妨看看 Angular 从 1 版到 2 版经历了什么（更别提他们尝试 Dart 的那些旁支项目了！）。
多年来升级 Ember 确实耗费了大量精力，但至少它提供了一个可行的升级路径！其他框架都没有提供类似的机会。
至于用 Vue/Next/React 重写，我认为人们严重低估了我们现有代码库的规模及其运行良好的程度。那将是一项难以想象的浩大工程。
19 个赞
是的，没错。当您的用户群体主要使用旧设备时，您的网站评分通常会较低。
6 个赞
我正在考虑 @justin 和 @awesomerobot 的建议，但我希望 Robin 先就 Ember CLI 的具体细节发表意见。
从根本上说，这里存在一个“不可阻挡的力量遇到不可移动的物体时会发生什么？”的悖论……我们非常明确地定位为 JavaScript 应用（或单页应用 SPA），这涉及我们在 2012/2013 年基于对 2022/2023 年未来形态的最佳预测所做出的权衡。虽然我显然带有偏见，但我会说，我们预测“移动设备浏览器的性能将与桌面浏览器性能无异”这一判断完全准确。
甚至超出了预期，因为最近的苹果手机实际上比笔记本电脑和台式机还要快。
虽然我们将继续尽可能提升首屏加载速度以及整体性能，但我认为我们在这方面的记录值得称赞。一方面，我们在 2015 年获得了大量关注，促使 Google 内部针对 V8、Chrome 和 Android 进行了一系列改进，以解决在 JavaScript 性能测试中暴露出的高通 SoC 性能不足问题。
我们的阿喀琉斯之踵一直是……高通 。遗憾的是，高通在性能方面迄今为止表现不佳，目前“最佳”性能的 Android 设备仅相当于 iPhone 7 的水平。老旧的 Android 设备退出市场需要很长时间，但骁龙 855 和 865 的表现都相当不错，大致相当于 iPhone 7 的水平：
我需要向下滚动更多才能找到性能与最快 Android 设备相当的苹果设备，但如果我这样做，最接近的匹配是 iPhone X / iPhone 8，其 Geekbench 分数约为 910。不幸的是，出于我尚未完全理解的原因，骁龙 865 在 Web 性能方面表现略逊一筹，因此在 Speedometer 测试中，我们仍处于 iPhone 7 的性能水平：
我真希望我们生活在一个有多种 SoC 来自不同公司的 Android 设备并存的世界，这些公司都在竞争打造最快、最强大的 SoC……iPhone 7 的性能对于 Discourse 来说已经足够扎实 ，我很高兴看到_最终_所有 Android 设备，即使是旧款，也能达到“至少与 iPhone 7 一样快”的水平。我也对即将发布的骁龙 875 充满期待，未来几个月应该会有更多详细信息。
根据 Geekbench 5 的结果，我们可以看到小米 Mi 11 由 5nm 骁龙 875 驱动（正如小米高管卢伟冰所暗示的那样）。即将发布的小米 Mi 11 在单核基准测试中获得了 1,102 分，在多核测试中获得了 4,113 分。
如果属实，这将使其达到 A12 的水平，希望这在 Web 端也能体现出来！
无论如何，Discourse 在此有一个核心架构决策，即_成为 JavaScript 应用_……我们在可预见的未来将完全致力于这一道路。
23 个赞
可不能忘了最近发布的 Apple Silicon Mac 啊！
codinghorror:
我们在 2015 年获得了大量关注
出于好奇，那些关注来自哪里？
A10 芯片仍在勉强支撑。
codinghorror:
如果属实，那它的水平就达到了 A12
以防万一，我把预期调低。苹果一直 都领先。
话虽如此，安卓智能手机仍在努力追赶。这简直太离谱了。苹果已经推出了 A14 芯片，他们很可能现在正在为明年研发 A15 芯片。
2 个赞
justin
2020 年12 月 8 日 21:40
111
感谢分享。以下是从文章中提取的与本次讨论相关的几点内容：
如果您受到冲击该怎么办 。谷歌过去曾就“如果您受到核心更新负面影响应考虑哪些事项”提供过建议。目前并没有具体的恢复措施，事实上，排名下降并不一定意味着您的页面存在问题。不过，谷歌提供了一份在您的网站受到核心更新冲击时应考虑的问题清单 。谷歌也表示，您可能会在两次核心更新之间看到一定的恢复迹象 ，但最显著的变化通常会在下一次核心更新后出现。
这一点也很有帮助。
https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184
7 个赞
neounix
2020 年12 月 9 日 00:13
112
在我看来，当谈论 SEO（即与其他网站相比优化搜索引擎结果）时，讨论用户硬件大多是不相关的。
为什么？
其实很简单。
考虑一个人及其在手持设备上的搜索结果。
无论设备速度如何，或芯片组如何，在所有网站上的表现都将相似，因为单个终端用户设备在网络上的最终用户体验（性能）对于所有性能相似的网站来说大体上是相同的。更快的网站会更快，更慢的网站会更慢，这与终端用户设备的芯片组等无关。水涨船高，水落船低。在 SEO 中，与“SEO”所优化的服务应用程序相比，终端用户设备只是一个“噪声”信号。
因此，如果一部手机是整个宇宙中最快的手机，所有网站都会快（或慢），这取决于网络速度和网站设计。SEO 的重点在于优化 Web 应用程序及其交付，而不是终端用户设备。如果一个 Web 应用在某个芯片组上表现“极其出色”，那么所有设计相似的其他网站也会如此。SEO 的重点不是终端用户设备，而是 Web 应用程序的优化、内容、基于服务器的加载时间，而不是客户端设备。理论上，客户端设备会访问所有网站，因此在 SEO 的信噪比中，这一切都是“噪声”。
从网站 SEO 的角度来看，基于用户体验的搜索引擎优化对于同一类别（性能特征）的所有终端用户移动设备的所有用户来说，在网络上是相同的。唯一能让一个网站相对于另一个网站获得 SEO 优势的是网站（及其网络）的性能，而不是终端用户设备。
为什么？
因为一般来说，终端用户设备在所有网站上的表现是相同的。如果用户的手机因内存或芯片组问题而缓慢，那么它在整个网络中的所有网站上都会缓慢。换句话说，关于终端用户设备如何影响 SEO 的讨论是多余的。搜索引擎优化是服务器端操作，而不是客户端操作。
重要的是内容、呈现和性能；以及 Google 的 AI 如何对整个网络中的这些因素进行评分。例如，如果全世界每个人都升级到量子计算手机，SEO 结果将保持不变，因为所有终端用户都将拥有相同的“终端用户设备性能曲线”。优化发生在提供者（即网站）端。同样，如果整个网络退化为使用缓慢芯片组的手机，搜索引擎排名将基本保持不变；因为需要进行的优化是由提供 Web 内容的服务器完成的。
当然，作为基于 JavaScript 的单页应用（SPA），Discourse 在加载后如果移动设备更快，性能会更好。其他所有网站也是如此！一般来说，就 SEO 而言，重要的是网络性能以及服务器性能，而不是终端用户设备。这不是我的个人观点，而是一个科学和工程事实。我对 JavaScript 或 EmberJS 的个人意见或情感联系不会改变 SEO 的工作原理。对 SEO 起作用的是内容和 Web 应用程序的性能。
最后，Google 使用先进的人工智能（主要是人工神经网络）来确定其如何对 Web 内容进行排名和索引。搜索引擎优化基于 Google 的 AI 如何对网站进行排名、网站的性能以及网站对 Google 的 AI 的“吸引力”。我们多么喜爱 JavaScript、Ruby 或 Python，或者我们多么喜欢或崇拜我们提供给终端用户的任何 Web 应用程序的优雅和机制，都是不相关的；除非我们对应用程序的热情能吸引 Google 的 AI，并且我们正在创建独特的内容，这些内容以良好的方式呈现给 Google 的 AI，并且符合 Google 的 AI 对性能的感知，而不是我们对性能和内容的感知。
我们不会对自己的网站进行排名。Google 的 AI 负责排名。
正如 Google 公开声明的那样：
“理解核心更新运作方式的一种方法是想象你在 2015 年列出了前 100 部电影。几年后的 2019 年，你刷新了这份榜单。它自然会发生变化。一些以前不存在的全新且精彩的电影现在将成为入选的候选者。你也可能会重新评估一些电影，意识到它们值得排在比之前更高的位置。榜单会发生变化，之前排名较高但随后下降的电影并不是糟糕的，只是有更多值得入选的电影排在它们前面，”Google 写道。
该公司提供了以下问题列表，供您在评估内容时参考：
内容是否提供了原创信息、报道、研究或分析？
内容是否对该主题提供了实质性的、完整的或全面的描述？
内容是否提供了超越显而易见的深刻分析或有趣信息？
如果内容引用了其他来源，它是否避免了简单地复制或重写这些来源，而是提供了实质性的附加价值和原创性？
标题和/或页面标题是否提供了对内容的描述性、有帮助的总结？
标题和/或页面标题是否避免了夸张或耸人听闻的性质？
这是您想要加入书签、与朋友分享或推荐的页面吗？
您是否期望在印刷杂志、百科全书或书籍中看到此内容或引用此内容？
这就是 SEO，而 Google 的核心业务是创建算法，以便机器能够对网站进行评分和分类。
https://searchengineland.com/google-advice-on-improving-your-sites-ranking-for-future-core-ranking-update-320184
2 个赞
riking
2020 年12 月 9 日 00:43
113
这与记录不符——我们知道 Google 正在从 Android 设备收集真实世界的页面加载时间，并将其用于页面排名。
4 个赞
neounix
2020 年12 月 9 日 01:06
114
是的，但所有同类型的 Android 设备在访问同类型的网站时，表现基本一致。换句话说，如果你优化一个基于 JavaScript 并使用 webpacker 和 bundler 的网站，从 SEO 的角度来看，你实际上是在与所有其他使用 webpacker 和 bundler 的 JavaScript SPA 网站竞争。
我并没有说 Google 没有收集这些信息。我想说明的是，仅仅关注客户端设备并不能解决 SPA 的 SEO 性能问题。“水涨船高”，一台能高效处理压缩 JavaScript 的更快 CPU（快速、优化良好等），会在所有类似的网站上表现良好。
换言之，SEO 的关键在于服务器端（正如我之前花了很多篇幅所写的那样），而不在于客户端。
顺便提一下，这一点已有充分文档记录。
算了 :)。我宁愿不在 meta 版块就此展开争论。谢谢。
Google 一直非常明确地说明了他们认为重要的 SEO 信号，无论是现在还是到 2021 年。他们将根据网络空间中的事件和情况，持续重新设计其 AI。
2 个赞
michaeld
2020 年12 月 9 日 07:03
115
从 SEO 的角度来看，你确实是在与那些技术相似的网站竞争。
但从商业角度来看，你是在与同一市场中的其他网站竞争，无论它们使用何种技术。这可能会促使人们考虑转向一种在 SEO 方面被认为“更好”的技术。这正是某些人所处的困境。
5 个赞
我的意思是，你也在说 Discourse 社区明年的搜索结果可能会受到影响（我们到时候再看会发生什么）。
这一点……我完全没料到！
但有利的一面是，iPhone 7 的性能对于 Discourse 来说已经足够扎实，我很高兴看到_最终_所有 Android 设备，即使是旧款，也能达到“至少与 iPhone 7 一样快”的水平。我也对即将发布的骁龙 875 充满期待，未来几个月应该会有更多详细信息。
