游戏谷歌 — 完美的灯塔分数

我一直对分享我的代码犹豫不决。并不是说我相信它低于标准水平，也不是说我没有受到冒名顶替者综合症的困扰。只是共享代码让人们瞥见了我脑海中的疯狂，这对其他所有人来说都有些残酷。请允许我引导你踏上差点把我推向理智边缘的旅程。这一切都始于谷歌的 Lighthouse 更新。

对于SEO初学者来说，谷歌的Lighthouse更新代表了搜索排名的重大变化，这取决于网站的表现和对最佳实践的遵守。如果您想测试自己的网站，只需在 Chrome 桌面上将其打开，按 F12 打开 Chrome 开发者工具，然后单击 “Lighthouse” 选项卡。选择桌面版或移动版，然后单击 “分析”。大约一分钟后，你将获得性能、可访问性、最佳实践、SEO 和 Progressive Web App (PWA) 方面的五个分数，每个分数从 0 到 100 不等。

在深入研究技术细节之前，让我自我介绍一下。我叫乔纳森·格兰瑟姆，我很自豪地拥有一家小型的B2B SaaS公司Nexoid，该公司专门从事ERP和ITSM软件。我在这篇文章中讨论的网站是 www.nexoid.com. 随意看看，打开源代码。你也可以在领英上关注我。我的个人资料是 www.linkedin.com/in/jonathongrantham/

谷歌 Chrome Lighthouse 更新发布后，我做了任何尽职尽责的企业主都会做的事情：我查看了我的网站。令我沮丧的是，结果远非令人满意。性能得分为21/100，可访问性为30/100，最佳实践得分为45/100，SEO的分数为11/100，PWA的失败，我感到震惊。我亲自搭建了这个网站，这是一个使用 React.js 的相当标准的单页架构。比分是一个沉重的打击。

我没有被最初的挫折吓倒，我启动了 MS Code 并开始逐一解决问题，性能是我的第一个目标。事实证明，Lighthouse 工具中提供的指南非常有用。我将 JPEG 和 PNG 中的所有图像转换为现代 WebP 文件，并确保每个 img 标签都配备了宽度和长度属性以防止布局偏移。光是这些修改就将我的分数从21/100提高到60/100。这是一项重大改进，但远非完美。剩下的唯一建议是 “减少未使用的 JavaScript”，这并不是特别有用。唯一存在的 JavaScript 是 React.js 框架，因为其他所有内容都被淘汰了。

借助 Nexoid，AM Digital 还能够将统一 ITSM 解决方案的优势扩展到面向客户的运营中。与 Azure 集成的客户端门户为其客户提供了更紧密的互联、动态和无缝体验，从而提高了客户满意度和参与度。该门户网站允许与客户数据进行实时同步，确保所有信息都得到更新和准确，从而改善他们的服务交付并加强客户与公司的关系。

尽管我坚持不懈地努力纠正这个问题，但我经常遇到障碍。我尝试删除 React.js 的部分内容，探索了 “延迟加载”，并测试了各种优化器和压缩。但是，问题源于 React.js 本身，它的大小约为半兆字节。

我几乎能听到经验丰富的网络开发人员大喊：“不要用 React 做网站！它本来是用来构建 Web 应用程序的！”我现在很清楚这一点。

最初只是一项看似简单的任务，那就是转换几张图片，现在已经演变为使用新框架的全面网站大修。我沮丧地屏住呼吸说了几个精选词，开始寻找合适的替代品。我首先考虑了 Vue，后来考虑了 Angular，可以说是 React.js 的最大竞争对手。但是，他们都提出了同样的问题。

为了简化事情，我决定研究较旧的技术，并试一试 jQuery。但是，我遇到了同样的问题。很明显，没有现成的单页架构框架可以安抚谷歌的神灵。

看来我唯一剩下的选择就是诉诸普通的 JavaScript。

我的一系列实验始于一个没有任何 JavaScript 的基本 HTML 页面。然后，我尝试了一个带有div的HTML页面，其内容可以替换。我很快意识到，通过JavaScript同时对页面进行多次更改会受到Lighthouse的处罚。解决方案是将 body 标签的内容作为字符串进行操作，然后将其重新集成，从而只创建单个可见的 DOM 更改。

我现在有一个极简主义的 HTML 页面，里面有一个空的正文标签，另外还有一个小的 onload 函数。此函数检查 URL 并执行 HTML GET 请求，以检索包含页面正文 HTML 的相应文本文件。人们会认为这是一个合适的解决方案。不幸的是，当我尝试动态加载 JavaScript 功能时，它没有达到目标。

与其他标签不同，如果您在正文内容字符串中添加带有简单警报（“是的，这已触发”）的脚本标签，则它将无法执行。尽管不理想，但一种解决方法是解析正文字符串，识别所有脚本标签内容，然后将它们放入 JavaScript eval 函数中。这种方法有些有效，但在处理命名空间时却跌跌撞撞，开发者控制台充斥着难看的警告。解决方案是从 HTML 中提取脚本标签，然后在 DOM 呈现后将其添加为脚本元素。出于某种原因，谷歌没有对这一行为进行处罚。

正在取得进展，我有了基本的单页架构解决方案。但没那么快。虽然谷歌在索引单页架构页面方面效率很高（他们通过在浏览器中将其打开，允许所有JavaScript运行，然后扫描DOM来做到这一点），但必应、雅虎和其他主要搜索引擎使用类似的、更简单的方法。但是，大多数其他平台，例如Facebook、Reddit、LinkedIn和WhatsApp，只能获取 HTML 文件，检索一个正文为空白的小型 HTML 文件。我的解决方案不可行。现在，我必须为网站上的每个页面复制这个概念，并在用户点击链接时包含 JavaScript 才能切换到单页架构模式。

根据我的解决方案，我需要一个能够为每个页面生成 HTML 的工具。我想到我有完美的资源可供使用：我自己的ERP系统，Nexoid。我创建了一个包含网站和网页数据对象的 Nexoid 模型。网站记录促进了通用模板网页的创建，而网页记录则包含每个单独页面的内容。最后一个难题是工作流程函数或脚本，它可以读取网站记录和所有相关的网页记录以生成 HTML 文件。几天后，它就开始运行了。我创建了一个基本的内容管理系统 (CMS)。到目前为止，开发 CMS 并不过于复杂；真正的挑战在于集成其他 CMS 工作流程、批准、本地化、预览等。

新网站的一项关键要求是本地化；我们的目标是推出11种语言版本。作为一家 IT 公司，我自然倾向于技术解决方案。我没有为每个页面雇用翻译人员，而是选择了 AWS Translate。虽然人工智能翻译器不错，但它们并不完美，而且错误足够明显，足以揭示非人类起源。一位讲法语的工作人员对人工智能翻译进行了评估，并给出了6/10的评分，称其为 “可以理解，但法语不正确”。

但是，我们偶然发现了一个有价值的技巧。我们发现，首先通过 ChatGPT 输入英文文本，让它 “整理一下”，然后粘贴进去，它会以一种仍然是英语但与语言模型更兼容的方式重写文本。使用 Chatgpt 重写的英语作为翻译基础可以显著提高翻译质量，将其提升到十分之九甚至完美的十分之一。

在为创建网站奠定了坚实的技术基础之后，我正在取得进展。但是，当我们开始构建更复杂的页面时，出现了一个新的挑战。根据新的 Lighthouse 指南，有必要将所有 JavaScript、CSS 和 HTML 整合到一个文件中。这也适用于单页架构版本。

我们采用了将所有 JavaScript 和 CSS 文件作为内联标签插入。单页架构版本需要类似的策略。我们创建了一个 JSON 文件，其中包含所有脚本、样式和 HTML。

Lighthouse 发现下一个问题是资产的大小；HTML 和 JSON 页面文件过大。我使用 “minify” 解决了这个问题，这是一个专门为压缩 HTML、CSS 和 JavaScript 文件而设计的 Node.js 库。该解决方案使文本文件的大小减少了40％以上。此外，minify 还提供了模糊处理的额外好处，使原始代码更难阅读，从而提高了安全性。

让我们深入探讨一下托管这个话题。传统上，内容管理系统 (CMS) 通过处理用户的 HTML 请求的应用程序服务器运行。它解释来自 URL 的页面请求，在数据库中找到相应的资产，检索数据库记录（可能与其他记录一起检索），处理信息以组装页面，最后将其作为平面 HTML 文档交付给最终用户。尽管我知道AJAX和其他类似技术，但此描述主要涉及用户访问新网站时的初始HTML请求。

但是，在新的灯塔世界中，这种传统模型存在某些缺点。首先，应用程序服务器和数据库服务器之间的来回通信以及页面编译会带来延迟。其次，在最简单的形式中，应用程序服务器和数据库服务器只能在单个位置实际使用。如果你在同一个建筑物或城市里，这种设置非常好，但是如果你尝试从世界的另一端访问该站点，则效率要低得多。例如，澳大利亚和英国之间的平均 ping 延迟约为 250 毫秒。

我们应对这些挑战的解决方案包括利用 AWS S3 托管由前面提到的发布脚本生成的静态文件，并利用 AWS CloudFront 进行全球内容分发。在撰写本文时，AWS CloudFront 正在向 47 个国家/地区的 90 多个城市分发内容。对于在澳大利亚墨尔本访问英国网站的个人，AWS CloudFront 将 ping 延迟从 250 毫秒减少到仅 13 毫秒（这是墨尔本和悉尼的 AWS 边缘服务器之间的时差）。

现在我们来看看 Lighthouse 测试的 Progressive Web 应用程序 (PWA) 组件，我之前没有考虑过这个问题。对于那些不熟悉的人，PWA 涉及一个 JavaScript 服务工作者，他将网站作为 Web 应用程序进行管理。如果这有点复杂，可以这样考虑：它本质上是一个自动下载和缓存工具。当用户访问您的网站时，目标是尽可能快速、无缝地提出后续请求。PWA 服务工作线程允许您已经将下一个资产下载到用户的本地计算机上，从而无需再次请求互联网 GET。

在撰写本文时，Nexoid网站相对较小，仅包含19页。但是，这 19 页被翻译成 11 种不同的语言，总共有 209 页。最初，我尝试将所有资产下载到服务工作线程中，总量约为5MB。这个尺寸对于初始加载来说太大了，Lighthouse 因此惩罚了我。我决定只下载英文页面 JSON 文件，其中包含显示每个页面所需的 CSS、HTML 和 JavaScript。

最终结构如下：S3 存储桶存放已编译的 HTML 文件，这些文件命名时不带.html 扩展名。例如，www.nexoid.com/en 代表英文主页 HTML，www.nexoid.com/de 代表德语主页 HTML，www.nexoid.com/en/platform 代表英语平台 HTML，依此类推。此外，还有一些包含在页面之间导航时会发生变化的身体和头部部位的 JSON 文件，例如 https://www.nexoid.com/en.json、https://www.nexoid.com/de.json 和 https://www.nexoid.com/en/platform.json 等。

总之，理解 Lighthouse 是一项重大挑战。我对传统的、开箱即用的CMS产品能否有效完成这项任务持怀疑态度。回顾我在WordPress和Drupal等平台上的经验，我发现很难相信它们可以经过优化以获得完美的Lighthouse分数。总的来说，我认为这项努力是值得的，谷歌有理由更加重视性能。但是，对于网页设计师和代理商来说，这种转变现在是并将继续是一个相当大的痛点。

如果您有兴趣了解有关Lighthouse的更多信息，或者想讨论Nexoid的产品和服务，请随时与我们联系。您可以通过 LinkedIn 或通过我们网站上的 “联系我们” 页面联系我们。