我的博客在每个 Lighthouse 类别上都获得了完美的 100 分。我喜欢写博客。我想建立一个轻便、快速、无杂乱、多博客运行且完全可访问的博客。最终，我差不多做到了。这是一个相当繁琐的过程。唉…我甚至不得不去掉我使用最多的框架 Next.js。这比我预期的要痛得多。我想分享改善性能的旅程，为什么我决定自己建立博客？当你想到博客时，会想到几个名字。Medium、Blogger、Ghost……但是没有一个让我满意。Medium 和 Blogger 功能臃肿，实际性能也不令人满意。Blogger Medium 真是吓人。嗯……还有一个问题：直接处理我们都喜欢的标记和原始代码（Markdown、HTML、CSS）是一件麻烦事。为了记录，所有性能测量都是在 pagespeed.web.dev 上进行的。当然，还有许多替代品：WordPress、Ghost、Hugo。我不喜欢 WordPress 的插件地狱。Ghost 必须自托管（ghost.org 也是，但太贵了……），每次版本升级都会破坏编辑器中的某些东西，因此保持更新是一件麻烦的事。Hugo 是这个群体中最好的，但总的来说，设置依然很麻烦。回头看来，我想要的其实是 SaaS。我最喜欢的是 Bear Blog。性能很好。我也喜欢它的产品哲学。但是它极简主义对我来说是个缺点。编辑器的用户体验也不适合我。如果它至少让我免费添加 AdSense 和附加图片，我可能就会直接使用 Bear Blog。和 Bear Blog 一样快，但功能更丰富，易用性更好。那就是我想建立的博客。哦，如果你有兴趣，可以在 bloffy.co 查看。总之，关于我够多了。让我分享我实际是如何改善性能的。让我们在 Lighthouse Performance 上冲刺 100 分。显然，缓存是必须的。显而易见，缓存是至关重要的。做对缓存，性能会大幅提升。Next.js 使缓存变得非常方便。有 ISR，它还为缓存扩展了 fetch 的 next 选项。非常方便。单独有效地使用这些可以大大提升性能。不过，我们的网站可以从世界各地访问。为什么这算不幸？在同一区域内，缓存能让事情变得快速，但来自其他区域的访客仍会遇到网络延迟。不，这太傻了。这就是 CDN 的用途。对，就是我们使用 CDN 的原因。如果你将 Next.js 应用部署到 Vercel，你会立刻获得一个 CDN。我不讨厌 Vercel；它非常方便。但专业计划从一开始就很昂贵，还有无服务器的冷启动问题，依赖 Vercel 生态系统也不是可以忽视的事。那么为什么不使用其他 CDN 服务呢？比如 Cloudflare。我诚实地认为 Cloudflare 是一家真正不错的公司。你可以在上面免费运行大规模基础设施和大多数应用。但后来我发现我其实不再需要 Next.js 的缓存。每次发布文章都要使两个缓存失效，让管理变得麻烦。总之，对于静态网站，我认为单靠 CDN 就足够了。这就是我不需要 Next.js 的原因之一。图像优化。如今的图像都超过 10MB。原封不动地在网络上提供这些，性能会完全失控。优化图像是一件麻烦的事。你必须根据设备尺寸进行调整、压缩，然后再处理 CDN。在之前的一个项目中，我有一个无服务器功能（AWS Lambda）每当有图像落入存储（S3）时就进行压缩和调整，并在前面放置 CloudFront 作为 CDN。这是一个非常合理的设置，可以精确按照我想要的方式定制。但这也是一个需要相当多维护的设置。所以这次我选择了 Cloudflare 的图像转换。即使在免费服务层，你也可以获得 5,000 张图像，所以我毫不犹豫地使用。此刻我听起来像是 Cloudflare 的销售代表。我只是一个普通的独立开发者。哒哒。这里是经过所有缓存和图像优化后 Next.js 博客的性能。作为参考，这是 Next.js 16.1.6。相当高的分数。但是这还不够。我们想要 100。一个清晰的、没有星号的 100。因此我深入了解了问题所在。它说发现了大量遗留 JavaScript，而这些并不是我写的。它来自 Next.js 打包中包含的框架运行时。但这个页面是一个静态页面，没有任何交互。每个页面都是用 ISR 预渲染的，我觉得我遵循了 Next.js 的指南。因此，作为实验，我移除了应用的每个客户端组件，只保留了服务器组件，然后再次测量。分数没有变动。起初我怀疑是水合问题，但一旦深入分析，问题不仅仅是水合。