给博客做一次性能体检：Lighthouse 56 分的复盘与清单

「静态网站 = 快」的误解#

动手之前，我默认静态站一定快：没有服务端渲染，没有数据库查询，文件在 Nginx 上即取即回。这个判断只对了一半。静态意味着服务端开销趋近于零，但用户感知的速度取决于首屏要下载多少东西——HTML、CSS、JavaScript、字体、图片，一个都不会少。

翻开首页的构成就很清楚：309 KB 的 HTML 说明首页是「一整页」输出；外观设置面板、音乐播放器、灯箱、樱花与水波纹特效、模拟时钟……这些功能各自带着脚本和样式，而且大多在页面加载时就被立即初始化。功能堆满了，浏览器首屏的负担也就堆满了。

96 和 100 分说明了什么#

先说好消息。可访问性 96 和 SEO 100 说明站点的骨架是健康的：语义化标签、标题层级、alt 文本、canonical、站点地图、RSS 这些结构性工作在定制主题时就已经做对了。这些是后期很难补的东西，性能反而是可以逐步偿还的债——这笔债的偿还顺序值得想清楚。

处方清单#

按优先级排列，前两项已经完成了第一批：

1. 脚本外置与按路由加载。 首批优化已上线：共享脚本改为缓存复用，收紧了 eager 预加载。下一批是让外观面板、音乐、灯箱和特效脚本退到首次交互之后再初始化——它们没有理由参与首屏竞争。
2. 移动端默认关闭特效。 水波纹和樱花在手机上默认不加载，并尊重系统的 prefers-reduced-motion 设置。这既是性能问题，也是可访问性问题。
3. 字体自托管。 霞鹜文楷目前走公共 CDN，可用性和隐私都有第三方依赖；计划自托管并配好系统字体回退，保证字体加载失败时阅读不受阻。
4. 建立预算。 给 HTML、CSS、JS、图片分别设上限，把 Core Web Vitals 纳入回归检查，用固定的 Lighthouse 基线防止优化成果在下一次加功能时悄悄退回去。

为什么不一口气全做完#

性能优化最忌讳的是把所有手段同时上线：时钟、切页、外观记忆这些功能都依赖脚本初始化时序，一次性改动意味着出问题时无法定位是哪一步引起的。一次只动一层，验证功能没有回归，再做下一层——慢，但每一步都可回退。

这份体检的结论不是「56 分不及格」，而是「功能与首屏成本的账单第一次对上了数」。分数是基线，不是成绩单。下次体检，希望性能那一栏能有新数字可写。