Next.js 性能优化实战清单：从首屏到交互

性能优化最容易陷入两个误区：
一是只看 Lighthouse 分数，不看真实用户体验；
二是做了很多“优化动作”，却没有持续监控指标。

先定义目标，再谈优化

我通常会先设定三个最小目标：

• LCP 控制在可接受范围
• INP 保持稳定，不因交互变复杂而抖动
• 首屏 CSS/JS 体积可解释、可追踪

有了目标之后，你做的每一条优化都能验证价值。

渲染策略选择

Next.js 提供了多种渲染方式，但不是越“动态”越好。
经验上：

• 静态可静态（SSG）
• 动态可缓存（ISR / revalidate）
• 必须实时才走强动态

这样能显著降低服务器压力，也能改善首屏稳定性。

资源层优化

常见的几个收益很高的动作：

1. 关键路由代码拆分，减少初始包
2. 图片按尺寸和格式优化，避免过大原图
3. 字体只加载必要字重
4. 对低优先级模块做延迟加载

这些动作看起来“基础”，但往往贡献最大的就是基础项。

交互性能

INP 问题大多来自主线程阻塞。
当一个交互触发大量同步计算，用户就会感觉“点了没反应”。
处理方式包括：

• 将重计算拆分为更小任务
• 使用 requestIdleCallback / worker 处理非关键逻辑
• 减少无意义的状态联动刷新

监控与回归

优化一次不难，长期保持才难。
建议至少建立：

• 线上 Web Vitals 采集
• PR 阶段体积变化提醒
• 关键页面渲染耗时趋势

这样你就能在性能退化的第一时间发现问题，而不是上线后一周才“感觉变慢”。

结语

性能工作不是“冲分”，而是“降低用户等待成本”。
把它当成产品体验的一部分，收益会比你想象的更稳定。