这个坑值得记一笔。站点做过一次目录调整，旧地址 301 到新地址，新地址又被 CDN 的规则跳了一次。用户从搜索点进来要等两次跳转才开始加载，Lighthouse 里 LCP 3.9 秒，但单看新地址只有 1.6 秒。
刚开始盯着「跳转目标还带查询参数 又触发一次缓存未命中」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。重定向发生在首字节之前 两次跳转直接叠加到 TTFB 上；CDN 上的跳转规则和源站规则重复 同一次访问被跳两遍；内链仍指向旧地址 每次点击都要走一遍跳转。
第一件事是看一次完整访问经过了几跳
curl -sIL https://www.example.com/old-path -o /dev/null -w '%{num_redirects} %{time_total}\n'然后逐跳记录耗时找出最慢的一环
curl -sIL -w '%{url_effective} %{time_starttransfer}\n' -o /dev/null https://www.example.com/old-path再往下把站内链批量改成新地址
grep -rl '/old-path/' /var/www/html | head -20等前面都确认过，再合并 CDN 与源站的重复跳转规则
location ^~ /old-path/ { return 301 https://www.example.com/new-path/; }改完先别撤，确认这几项。内链改完并去掉重复跳转后，从旧地址进入的访问少了一跳，LCP 从 3.9 秒降到 1.8 秒，TTFB 也回到 200ms 以内。
提醒一点。LCP 变慢不一定是资源加载的问题，跳转发生在首字节之前，这一段的耗时同样计入用户感知的等待。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。