我把 Next.js 拆掉之后，博客 Lighthouse 四项都到了 100

编者按：以下据独立开发者 korindiehacker 于 Bloffy 博客平台发布的英文原文编译整理，保留第一人称叙述与关键细节；文中 Lighthouse / PageSpeed 分数与耗时数字均为作者自测口径。

我的博客刚在 Lighthouse 每个类别都拿到了满分 100。我喜欢写博客，想做一套又轻又快、不堆杂物、能挂多个博客、还尽量无障碍的东西。折腾了很久，差不多做成了。过程挺磨人——连我用得最多的框架 Next.js 都得拆掉，痛苦程度远超预期。想把这段把性能抠上去的经历写下来。

我为什么要自己做博客

提到博客，脑子里会冒出 Medium、Blogger、Ghost……但没有一个让我满意。Medium 和 Blogger 功能臃肿，实测性能也不行。

用 PageSpeed（pagespeed.web.dev）测下来，结果真挺吓人。另一头，又很难直接跟我们喜欢的 Markdown、HTML、CSS 较真地打交道。

替代品也有：WordPress、Ghost、Hugo。我不喜欢 WordPress 的插件地狱；Ghost 要自建（ghost.org 又太贵），每次升级编辑器还容易坏；Hugo 算这几家里最好的，但搭起来仍嫌麻烦。回头看，我真正想要的其实是 SaaS。

最喜欢的是 Bear Blog：性能好，产品哲学也对味。但对极端极简有点过敏，编辑器体验也不合手。作者原话大意是：哪怕只让我免费加 AdSense、挂图，自己大概就会直接用 Bear Blog。

我想要的是：像 Bear Blog 一样快，功能与可用性再多一点。作者提到自己在做的平台叫 Bloffy（bloffy.co）。

先冲 Lighthouse Performance 100

缓存是基本功

缓存做好，性能会明显上去。Next.js 在这点上很方便：有 ISR，还给 fetch 加了 next 缓存选项。用好这些，性能能走很长一段。

可站点要面向全球。同区域内缓存很快，跨区域还是吃网络延迟。

所以才有 CDN

把 Next.js 部署到 Vercel，CDN 自带。Vercel 确实方便，但 Pro 一上来就贵，还有 serverless 冷启动，以及对 Vercel 生态的依赖，都绕不过去。

那就换 CDN？比如 Cloudflare。我真心觉得 Cloudflare 不错，大规模基建和多数应用能免费跑起来。可这样一来，Next.js 那套缓存反而显得多余：每发一篇文章要失效两套缓存，管理很烦。

结论：静态站，CDN 就够了。这是我不需要 Next.js 的第一条理由。

图片优化

现在图片动不动超过 10MB，原图往网站上一扔，性能直接崩。

优化又很烦：按设备缩放、压缩，还要配 CDN。以前项目里我用 Lambda 在图进 S3 时压缩缩放，前面挂 CloudFront，够定制，但也够维护。

这次改用 Cloudflare Image Transformations。免费档有 5000 张额度，我用得很放心。（写到这儿自己都觉得像 Cloudflare 销售，其实只是普通独立开发者。）

缓存 + 图片都做完，Next.js 博客测下来怎样

参考版本是 Next.js 16.1.6。分数已经挺高，但还不够——我想要干干净净、不带星号的 100。于是继续挖。

报告里说发现大量 legacy JavaScript，而且不是我写的，是 Next.js 打进包里的框架运行时。

可这页是零交互的静态页，整站用 ISR 预渲染，我也自认按指南做了。于是做了个实验：把所有客户端组件拆光，只留服务端组件，再测——分数几乎不动。

一开始怀疑 hydration，深挖后发现不只是 hydration。即便只有服务端组件，运行时 chunk、hydration，以及给路由用的 RSC payload 都会留下。因为 next/link、next/image 本身就是客户端组件（'use client'），光这两个就够把运行时拉进来并触发 hydration。

那把 next/link 和 next/image 也拿掉呢？App Router 自己的运行时、路由和错误边界还在。官方没有「降到零」的办法，只剩把渲染 HTML 里的脚本硬抠掉这种 hack。那时我突然想：都做到这份上了，我还用 Next.js 干什么？

还有那堆没用到的代码

能看到大头 JavaScript 都是用不上的。仅 unused code 就有 230,460 字节。多数静态站根本不需要 JS，更不需要这些没用的 JS。

这会儿我真纠结：为了那几分，拆掉 Next.js 对不对？面向公众的那套应用，我已经砸了不少时间。

拆掉 Next.js

最后，为了博客质量（哪怕只差 5 分），我决定整框架拆掉。长期看，那些多余能力我也不太用得上。考虑过纯原生，又不想放弃框架带来的生产力和基建。需要找一个更合适的。

我选了 Hono。喜欢它的技术哲学：「快、简单」正是当时最缺的，还有 JSX 支持是加分项。迁移成本看起来也不算夸张。

终于，100

就这样，四项都到了 100。你现在看的这页，可以直接丢进 pagespeed.web.dev 自己跑。

没有 JavaScript，unused code 锐减到 407 字节。附带好处：构建时间大约少了 40%。

（有人会问 SEO 为什么是 69？那是测试站，故意拦了搜索收录，所以才是 69。）

顺带一提：在 DevTools 里四项都 100 时，Lighthouse 真的会放烟花。🎉

长任务（渲染到屏前那段）在 Next.js 上是 309.3ms，同一页用 Hono 做成 68.01ms，大约改善 78%。

静态站真的还需要 Next.js 吗？

带着 hydration 的 JS 负载，对静态站到底有没有好处？我觉得没有。它留下不必要的 JavaScript，多数情况下就是多余。

不过，交互很重的应用，Next.js 仍可以是很好的框架。事实上，这个博客的管理后台，我还是用 Next.js 写的。

P.S. 这篇所在的博客跑在作者正在做的 Bloffy 上。

说明：文中 PageSpeed / Lighthouse 分数、unused code 体积、长任务耗时与构建时间变化，均为原作者自测；测试环境与复现条件以原文为准。成稿为编译润色，未改写其经历主线。

来源

[1] 原作者：korindiehacker；原文标题：Removing Next.js Got My Blog to 100 on Every Lighthouse Category，Bloffy 博客，2026年10月26日。

#经验分享 #Next.js #Hono #Lighthouse #博客性能 #Cloudflare