我如何通过使用合适的工具大幅提升我的网站性能

卓越的网站性能和一流的核心Web 指标是确保您的网站快速、可访问并在搜索引擎中取得良好排名的关键。从 JavaScript 框架到静态网站生成器，再到轻量级构建工具，总有一款工具适合您！选择合适的工具至关重要，它可以最大限度地提高网站的性能、可访问性以及开发者和最终用户的体验。

在我们了解我在博客第三次迭代中所做的性能改进之前，让我们回顾一下我在 Jamstack 上构建我的第一个和第二个博客网站的时候。

要直接获取数据 — —请点击这里。

2020：Svelte + Sapper

2020 年，我使用Svelte 和 Sapper搭建了我的第一个简单的博客网站。博客文章由存储在仓库中的 Markdown 文件驱动，这是一个很好的起点。

浏览 Svelte 网站，享受乐趣！

2021 年：Next.js + Contentful

2021 年 1 月，我加入Contentful担任开发倡导者，主要负责帮助开发者将 Contentful 与流行的前端 JavaScript 框架结合使用。2021 年 3 月，我使用 Contentful 和Next.js重建了我的博客网站。Next.js 是一个 React 前端框架，结合了静态预渲染、服务器端渲染和内置的无服务器函数。

这一年，我持续撰写博文、不断迭代，并不断添加网站功能，以帮助开发者更好地结合使用 Next.js 和 Contentful。但考虑到我添加到网站的功能数量，这个版本的博客开始显得有些过度设计。对网站进行小规模的更新变得越来越困难，而我这种以原子化的方式管理内容的方式，似乎更适合由多名开发者和内容编辑组成的大型产品团队。

查看该网站以供稍后参考。

2022年：Eleventy + Contentful

时间快进到 2022 年 1 月，我加入了Netlify的开发者体验团队。这让我更加深入地思考 Jamstack 的核心价值主张：提供高度优化的静态页面和构建过程中创建的资源。此外，我在 2021 年发表的演讲——“如何通过构建无障碍网络来防止社会崩溃”——强调向浏览器传递大量 JavaScript 文件会影响性能、可访问性和用户体验，这让我想要挑战自己，构建一个尽可能少向浏览器传递 JavaScript 的网站。

于是我转向了Eleventy——一个用 JavaScript 构建的静态网站生成器——它默认不向浏览器发送 JavaScript。与其说它是一个前端框架，不如说它是一个构建工具，它让开发者完全控制构建并通过 CDN 提供给浏览器的文件和资源。这次迁移的一大优点是，我可以继续使用 Contentful 来管理我的内容。

完整免责声明：所有工具均为有效工具！

在介绍我从 Next.js 迁移到 Eleventy 所带来的性能提升之前，我想先明确一点：所有工具都是有效的，我从 Next.js 迁移过来并不意味着我认为它很糟糕！我认为它是一款非常棒的工具——尤其是对于那些没有时间从头开始构建自己的软件设计模式和可扩展架构的大型开发团队来说。使用 Next.js 总是可以非常快速地发布一个大规模的、可用于生产环境的应用程序！

选择你的工具

为新项目选择静态站点生成器或前端框架应取决于许多因素，包括：

• 该项目是什么以及它将如何发展（这也可能会改变！）
• 你的开发团队有多大
• 是否需要满足编辑内容团队的需求
• 您的最终用户是谁、他们使用什么设备以及他们在世界的哪个地方！

这些问题的答案促使我朝着使用比 Next.js 更轻量级的解决方案进行构建的方向发展。此外，这也是一个学习如何使用另一个静态站点生成器的绝佳机会。

此外，过去几个月我联系的开发者越来越多，他们正在使用 Eleventy 构建精简、高效的网站。我觉得这是一个向他人学习的好机会，同时也能帮助到其他人。

现在，让我们看一下数据！

衡量绩效

在本研究中，衡量成功的标准是以下四个目标：

• 向浏览器发送更少的 JavaScript
• 减少网络请求
• 改善所有核心网络指标
• 提高 Lighthouse 性能分数

我们使用三款免费工具比较了 Next.js 网站和 Eleventy 网站的性能：Google Lighthouse、web.dev/measure和Web Page Test。Lighthouse测试在 Brave 浏览器开发工具中运行，Web Page Test 测试通过位于英国伦敦 EC2 服务器的 Web 应用进行，web.dev 测试则在浏览器中进行。鉴于我提倡移动优先的开发理念——由于移动数据速度不可预测，移动端的性能最容易受到影响——所有测试均在模拟移动环境中使用中等 3G 网络速度，在 iPhone 6/7/8 上进行。

向浏览器发送更少的 JavaScript

使用网页测试，我查看了两个网站主页的 MIME 类型细分情况。

前

Next.js 网站向浏览器传送了33 个JavaScript 文件，总计2.94MB。

后

Eleventy 网站仅向浏览器提供1 个JavaScript 文件，总计仅20.5kb。

比较Next.js 网站和Eleventy 网站的视觉设计时，您可能会认为这两个主页差异巨大，因此必然存在差异。但这是由于 Next.js 和 Eleventy 在构建和打包生产环境文件的方式上存在差异。

Next.js 默认将分块 JavaScript 文件发送到浏览器，以便预渲染来自 Next.js 服务器的动态内容，并通过 React 在客户端进行交互。相比之下，Eleventy 默认不提供 JavaScript，而是在构建过程中输出静态 HTML 文件。

同样需要注意的是，设计就是性能。在迁移过程中，我做出了许多设计决策，以性能为中心，并减少对第三方的依赖。这些决策包括：

• 从主页中删除“最新的 YouTube 视频”
• 从整个网站删除 Google Analytics
• 自托管字体，而不是从 Google Fonts CDN 请求字体

此外，Eleventy 网站在主页上提供的唯一 JavaScript 文件是为“最新 Twitch 流”详细信息提供时间本地化支持 —— 这是我特意添加的。

✅ 向浏览器发送更少的 JavaScript —成功！

减少网络请求

如上图所示，Next.js 主页对 HTML、CSS、JavaScript、字体、图像和其他文件（JSON 等）发出了 75 个网络请求。这些网络请求总计 3.98MB。

Eleventy 主页仅发出 9 个网络请求，总计仅 325.5kb。

这使得新主页的大小仅为旧主页的 8%！ Eleventy 网站上最大的负载来自字体文件——我可以在未来进一步优化它。

✅ 减少网络请求 —成功！

改善核心网络生命力

目前，核心 Web 指标会根据用户体验的三个方面进行评分——加载、交互性和视觉稳定性。这些测试均使用web.dev/measure在两个网站的主页上进行。

加载中

加载性能以最大内容绘制 (LCP)来衡量。为了提供良好的用户体验，LCP 应该在页面首次加载后的 2.5 秒内完成。

结果如下：

• Next.js 网站 — LCP = 9.9 秒
• 十一点——LCP = 1s

✅ 改进 LCP —成功！

交互性

交互性由首次输入延迟 (FID)衡量，它衡量的是 Web 应用对用户输入（例如点击按钮、选择文本以及在表单字段中输入内容）的响应速度。由于需要使用真实用户进行测试，因此准确测量 FID 比较困难，因此我们可以使用可交互时间 (TTI)指标来计算页面完全可交互所需的时间。

结果如下：

• Next.js 网站 — TTI = 11 秒
• Eleventy 站点 — TTI = 2.5 秒

✅ 提高 TTI —成功！

视觉稳定性

视觉稳定性通过累积布局偏移 (CLS)来衡量。您是否有过这样的经历：点击了网页的某个部分，却发现在某个异常元素或图片最终加载完成后，意外点击了其他内容？CLS 是指内容在加载完成后突然弹出，通常会将内容向下或向侧面推，这非常令人沮丧！良好的用户体验应将 CLS 分数保持在 0.1 或更低。

结果如下：

• Next.js 网站 — TTI = 0.002
• Eleventy 站点 — TTI = 0.032

😬 提高 CLS —— 没那么简单！它仍然远低于 0.1，这很好！但我真的不确定是什么提高了 Eleventy 网站的 CLS！这需要进一步调查。

以下是 web.dev/measure 单次运行的测试结果，以供比较。全是绿色数字！

前

后

提高 Lighthouse 性能分数

鉴于我在之前的测试中只关注主页，我还测试了具有不同特征的各种博客文章的 Google Lighthouse 性能得分，以确保我对整个网站做出了改进。

主页

这是我们的基线，显示出从 73 到 100 的巨大进步！

一篇包含大量代码示例的长博客文章

Lighthouse 的性能得分通常会受到“DOM 大小过大”的影响，就我的博客文章而言，这通常是由于代码示例过大以及代码片段使用大量<span>标签突出显示造成的。这篇博文的性能得分从 89 大幅提升到了 100。

一篇包含大量图片的长博客文章

我在 Next.js 博客上做了大量工作，针对不同的浏览器优化图片格式，并在支持的情况下实现图片的延迟加载。不过，分数还是从 98 提高到了 99！阅读下方链接的博客文章，了解更多关于如何使用 HTML 标签加载 AVIF 和 WebP 格式的响应式图片的信息！

嵌入 YouTube 视频的博客文章

Eleventy 拥有蓬勃发展的社区插件生态系统，我使用了eleventy-plugin-youtube-embed来优化我的 YouTube 视频嵌入。使用此插件，第三方 YouTube 脚本仅在有人与视频互动时才会加载，而不是在页面加载后立即加载 JavaScript。这极大地提升了性能得分，从 60 分提升到了 98 分！

✅ 提高 Lighthouse 性能分数 —成功！

定性学习

我花了一段时间才将我的思维从 Next.js 转移到 Eleventy。Next.js 构建前端应用程序的方式固然有其独到之处——这本身也无可厚非——但在转向 Eleventy 的过程中，我发现我可能过于依赖 Next.js 的模式了。通过 Eleventy 回归 Web 基础，并专注于将纯 HTML、CSS 和 JavaScript 移植到浏览器，我感觉自己对 Web 原生工作原理的理解得到了更新和提升。这让我能够以一种全新的、更明智的思维方式来处理我的下一个 Next.js 项目。

第二个系统效应

回顾我博客迭代的历程，让我想起了“第二系统效应”。第一次实施对我来说可扩展性不够，第二次实施略显过度，而第三次迭代目前来说还算合适——这要感谢我一路走来学到的一切！

那么，我是否建议你使用 Eleventy 来搭建你的下一个博客网站呢？这得看情况！

使用合适的工具

人们经常问我应该从哪个前端框架或静态网站生成器开始，我的答案始终是——视情况而定！我能给你的最可靠的建议是，确定你想要的功能，确定你可能需要如何扩展应用程序（在团队规模、内容管理、系统和模式方面），并且不要害怕尝试。你可能不会第一次就成功，但始终要努力使用合适的工具来完成工作。尽量不要过度设计，并始终注意你要求网站访问者下载到浏览器中的内容。你可以在Jamstack.org上查看大量的静态网站生成器列表。

通过迭代我的博客所使用的技术堆栈，我学会了如何使用三个前端框架，如何使用 markdown 文件或 CMS 为博客提供支持——以及所有这些如何有助于开发人员体验和网站的最终用户体验。

一如既往，我鼓励你去创造、去学习，并热爱你所做的事情。去尝试、去发布，然后不断迭代、迭代、再迭代。