Next.js 站点打开慢，就按这个顺序查
核心原则只有两条：用生产构建测，一次只改一个主要因素。 下面每一步都写清「看到什么算命中」，避免改了一堆东西、LCP 却没动。
先别测 dev，用生产模式起
npm run dev 的模块热替换和未压缩 bundle 会让时序完全失真， 在那里测出来的 LCP 没有参考价值。
npm run build npm run start # 手机连同一 Wi-Fi，用局域网 IP 打开（不要用 localhost 测手机） # 例：http://192.168.1.x:3000
录一次 Performance，找出真正的 LCP 元素
Chrome DevTools → Performance →Record and reload，网络先限到Slow 4G、CPU 限速 ×4。 录完在 Timings 里看 LCP 标记，点开确认它到底是哪张图/哪块文字——很多人优化了半天，优化的根本不是 LCP 元素。
Network 面板看三件事：体积、请求启动时间、下载耗时
把 Waterfall 的起点对齐到导航开始，看那张图的第一条竖线 离最左边有多远——那就是「发现得太晚」的长度，跟图多大无关。 本站右下角的探针直接把这个数打出来（「该图请求启动于 +Xms」）。
按四类对症下药
① 首屏图片太大：按展示宽度切档（srcset + sizes）、换 AVIF/WebP、压缩原图。
② 首屏图请求太晚：确认它真是 LCP 图后，用 preload /fetchPriority="high"，别让它落在懒加载或 JS 挂载之后。
③ 图下完了、页面还是不显示：查大体积客户端 JS、阻塞第三方脚本、首帧才启动的动画， 看 Performance 里的 Long Tasks 和 Main thread。
④ HTML 本身就慢：查服务端数据查询、SSR 阻塞、TTFB——这时网络面板里 第一个请求的等待时间就很长，跟图片无关。
每次只改一个因素，同条件复测
同样设备、同样网络限速、同样冷缓存。对比改前改后的 LCP。如果图片体积明显降了、LCP 却没改善，说明瓶颈不在图片， 回到 ③ 或 ④ 继续查——这是最常见的误判。
# 命令行里做一次可复现的移动端测量（生产域名） npx lighthouse https://你的域名/ \ --form-factor=mobile --throttling-method=simulate \ --only-categories=performance --view
这个站自己就是例子
首屏图在构建期生成了四档，页面只声明 srcset，由浏览器按视口选。下面是构建产物里的真实字节数。