Lighthouse分数不是优化的结果，而是反映架构本质的镜子

Lighthouse的评分高低对比会揭示一些令人惊讶的事实。得分高的网站并不一定是花费最多优化时间的网站，而更可能是设计简洁、没有赋予浏览器过多负担的站点。

性能指标所反映的内容

Lighthouse所测量的并不是工具或框架的排名，而是实际的成果：

• 用户看到有意义内容的速度
• JavaScript占用主线程的时间
• 页面加载过程中布局的稳定程度
• 文档结构的可访问性和爬取性

这些指标（TTFB、LCP、CLS）是实现阶段决策的连锁反应，尤其直接关系到浏览器在运行时的计算量。

依赖大型客户端打包的架构中，低分几乎不可避免。而以静态HTML为核心、客户端逻辑最少的网站，则能实现可预期且稳定的性能表现。

JavaScript的贪婪：性能下降的真凶

许多被审查的项目都面临一个共同问题：JavaScript的执行。

这并非代码质量的问题，而是源于浏览器单线程环境的根本限制。框架运行时、Hydration、依赖解析、状态初始化——这些都在浪费页面变得交互式之前的时间。

即使是少量的交互功能，也常常要求不成比例的庞大打包体积。默认以JavaScript为假设的架构，需要持续调整以维持性能。

相反，将JavaScript明确定位为可选择的架构，往往能带来更稳定的结果。这种哲学差异在Lighthouse得分中表现得尤为明显。

构建时处理消除不确定性

预渲染输出从性能方程中移除了多个变量：

• 不再需要请求时的服务器端渲染成本
• 不再需要客户端引导加载内容
• 浏览器接收可预测、完整的HTML

因此，TTFB、LCP、CLS等指标自然改善。虽然不能保证完美得分，但大大降低了失败的可能性。

实例学习

一个个人博客的重构项目中，尝试了多种方案。基于React、以Hydration为前提的设置虽然灵活，但性能需要持续关注。每次新增功能，都要重新考虑渲染策略、数据获取方式和打包大小。

相反，采用以静态HTML为起点、将JavaScript作为例外的方案，效果显著。选择Astro的原因在于其限制设计与验证假设的目标一致。

令人惊讶的不是初始得分，而是随着时间推移性能的稳定性：

• 新内容发布后不会导致得分下降
• 小型交互元素不会引发连锁警告
• 基线难以恶化

在这种架构下，Lighthouse得分不再是追求的目标，而是自然的结果。

权衡的现实

这种方法并非万能。以静态为核心的架构不适合高度动态、状态丰富的应用场景。需要认证用户数据、实时更新、复杂客户端状态管理的场合，实现难度会增加。

以客户端渲染为基础的框架能提供更大灵活性，但也意味着运行时复杂度的提升。

关键在于，哪种架构更优并不重要，重要的是架构的选择直接影响Lighthouse指标。

得分稳定的机制与下降的原因

Lighthouse反映的不是优化努力的成果，而是系统复杂性。

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

这解释了为什么某些网站需要不断调优性能，而另一些网站则能在最少干预下保持稳定。

本质的选择

高Lighthouse得分通常不是通过积极优化工具调整的结果，而是源自于从架构上最小化浏览器初始加载处理负荷的自然表现。

工具和趋势会变化，但根本原则不会变：将性能作为目标不是设计的目标，而是作为限制条件融入设计中。这样，Lighthouse得分就不再是追求的目标，而是一个简单的观察指标。

这种转变不在于“选择哪个框架”，而在于“在哪个环节允许复杂性”。