控制浏览器的负载是Lighthouse评分的本质意义

即使你对Lighthouse评分的改善非常努力，为什么仍然无法获得预期的结果呢？许多开发者反复进行图片压缩、脚本延迟加载、布局偏移应对措施、插件优化等操作。然而，当观察那些始终保持高分的网站时，会发现一些规律。这些规律并非激烈调优的结果，而是因为这些网站在浏览器运行时处理的计算量本身就很少。

也就是说，Lighthouse不仅仅是一个优化工具，更是一个信号，显示架构设计是否真正做出了有意义的选择。

浏览器实际测量的内容

Lighthouse评估的不是某个特定框架，而是由其产生的结果。具体来说，它测量以下内容：

• 内容变得可见的速度
• JavaScript对主线程的阻塞程度
• 加载中的布局稳定性
• 文档结构的无障碍性

这些指标都在架构设计阶段就已确定，尤其是直接关系到在运行时委托给浏览器的计算量。

如果页面的行为依赖于庞大的客户端打包，低分是理所当然的。相反，如果以静态HTML为基础，将客户端处理降到最低，性能就变得可预测。

JavaScript执行是最大变动因素

根据以往的审查经验，导致Lighthouse分数下降的最常见原因是JavaScript的执行。这并非代码质量的问题，而是因为JavaScript在单线程环境中排他性地执行，受到根本性限制。

框架的运行时、Hydration、依赖关系解析、初始状态设置——这些都在页面变得交互之前消耗时间。即使是很小的交互功能，也常常需要不成比例的大型打包。

在这里，做出明智的判断非常重要。以JavaScript为默认前提的架构需要持续不断的努力来维护性能。而将JavaScript作为明确的可选项的架构，往往能带来更稳定的结果。

静态输出带来的可预测性

预渲染的输出从性能方程中排除多个不确定因素：

• 请求时没有服务器端渲染的成本
• 不需要客户端引导
• 浏览器接收完整且可预测的HTML

从Lighthouse的角度来看，仅凭这种结构，即使没有刻意优化，也能改善TTFB、LCP、CLS等指标。虽然不能保证完美的分数，但可以大大降低失败的风险。

实现验证示例

在个人博客重构过程中，我比较了包括依赖React Hydration的多种方案。它们都具有灵活性和功能性，但在维护性能方面始终需要注意。每次添加新功能时，都要判断渲染模式、数据获取和打包大小。

作为实验，我优先考虑静态HTML，视JavaScript为例外。选择Astro的原因是，它的默认限制与我验证的假设一致。

令人惊讶的是，初始分数并非最重要，而是后续的维护难度。新增内容不会导致分数倒退，小的交互元素也不会引发意外警告，基线难以被侵蚀。在不断试验中，我保持了理想的Lighthouse分数，并将构建过程中的权衡另行记录。

方案选择的权衡

理解这一模式并非万能非常重要。

静态优先架构不适合高度动态、状态丰富的应用。在需要认证用户数据、实时更新、复杂客户端状态管理的场景中，实现会变得复杂。

在这种情况下，以客户端渲染为前提的框架提供了灵活性，但也带来了运行时的复杂性。关键在于，哪种架构更优并非重点，而是所选择的架构能以有意义的方式，直接反映在Lighthouse指标上。

分数的稳定性与脆弱性的本质

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

依赖运行时计算的系统，随着功能增加，复杂性也在积累。提前在构建时进行计算的系统，默认将这种复杂性控制在一定范围内。

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

本质意义

高分的Lighthouse成绩很少是积极优化的结果，而更可能是架构设计中最小化浏览器在初始加载时执行工作的自然结果。

工具会变，但根本原理不变。当性能不是追求目标，而是架构设计的初始约束时，Lighthouse的角色也会从“应达成的目标”转变为“观察当前状态的指标”。

这种转变的起点，不在于选择正确的框架，而在于有意识地限制那些允许复杂性贪婪积累的空间。