Lighthouse的评分不是调优工具，而是反映架构健康状况的镜子

为什么在同一网站上会出现差异

如果追求Lighthouse的高评价值，仅仅反复进行图片压缩、脚本延迟加载、布局偏移对策是不够的。观察实际项目时，持续保持高分的网站与每次新增功能后分数下降的网站的区别，不在于努力程度，而在于设计阶段的选择。浏览器在加载时处理的工作量越少，网站的得分越稳定。

Lighthouse真正检测的内容

Lighthouse不是用来判断框架优劣的工具，而是将实际用户体验量化的工具。

• 内容显示到屏幕上的速度
• JavaScript阻塞主线程的程度
• 页面加载中的布局稳定性
• 文档结构的无障碍性和爬取性

这些指标反映了开发初期的决策如何影响最终表现。依赖大型客户端打包的页面，得分必然较低。而基于静态HTML的页面，性能更容易预测。

JavaScript与水合：性能下降的主要原因

大量审计项目表明，JavaScript的执行是拖累Lighthouse得分的最大因素。这不是代码质量的问题，而是浏览器单线程环境的根本限制。

水合过程尤其负荷巨大，所有框架运行时的初始化、依赖关系图的解析、状态的初始化等任务，都在页面变得可交互之前完成。为了少量交互功能，往往需要不成比例的庞大JavaScript包。

默认以JavaScript为核心的架构，为了保持性能，必须持续优化。而将JavaScript作为显式选择的架构，则能带来更稳定的结果。

静态生成带来的确定性

预渲染的HTML可以消除多种性能变量：

• 无需等待服务器端渲染延迟
• 不需要在客户端进行引导处理
• 浏览器接收完整且可预测的HTML

因此，TTFB、LCP、CLS等关键指标会自动改善。静态生成不能保证完美得分，但大大减少了失败的可能性。

实例：个人博客重构中的经验

在重构博客时，尝试了几种标准方法。默认依赖水合的React方案灵活性较高，但每次新增功能时，都要为渲染模式、数据获取和打包大小烦恼。

于是尝试不同的思路，将静态HTML作为默认，将JavaScript作为例外。选择Astro的原因是，它的默认限制与我验证的假设相符。

令人印象深刻的是，初始得分高远不如随着时间推移，维持得分所需的努力少。新内容的发布没有带来倒退，小的交互元素也没有引发无关的警告。基线没有被侵蚀。

没有万能的解决方案

这种方法并不适用于所有场景。需要认证用户数据、实时更新、复杂客户端状态管理的应用，静态优先架构可能力不从心。

客户端渲染框架在需要高度灵活性的场景中更具优势，但也意味着运行时复杂性增加。关键在于架构的选择会直接反映在Lighthouse指标上。

影响Lighthouse得分稳定性的因素

Lighthouse揭示的不是努力，而是熵。

依赖运行时计算的系统，随着功能增加，复杂性不断积累。而在构建阶段处理的系统，默认可以抑制这种复杂性。

这解释了为什么某些网站需要不断优化性能，而另一些网站只需最小干预就能保持稳定。

结论：分数不是追求的目标，而是观察的指标

高的Lighthouse得分，更像是页面加载时浏览器所做工作的最小化架构的自然结果。

将性能作为设计的限制而非目标，Lighthouse不再是需要追逐的指标，而变成观察系统健康状况的工具。关键不在于选择哪个框架，而在于在哪些地方可以容忍复杂性。