先测量，再动手

性能优化最容易掉进的陷阱，是凭感觉改代码。我们先在统一设备和网络条件下记录基线：LCP 4.2 秒、首屏 JavaScript 612 KB、关键请求链长度 8。

没有稳定的测量方式，就没有可信的优化结果。

浏览器 Performance 面板指出了三个主要问题：主图加载晚、大型依赖阻塞主线程，以及首屏之外的组件被提前渲染。

缩短关键请求链

将首图转换为 WebP，并通过 preload 提前声明；字体只保留实际使用的字重，同时让非关键脚本延迟加载。

<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">

这一步让 LCP 下降了约 1.1 秒。优化不是把所有资源都设为高优先级，而是让浏览器知道什么最重要。

把工作留到需要的时候

路由级代码拆分将首屏脚本降到 238 KB；长列表使用虚拟化，首屏下方模块则通过 Intersection Observer 延迟初始化。主线程长任务从 7 个减少到 2 个。

让结果不会反弹

最后，我们在持续集成中加入性能预算：首屏 JS 不超过 250 KB，LCP 在移动网络下不超过 2.5 秒。性能优化不应是一场运动，而应该成为团队默认的质量标准。