文章页的 LCP 元素是首屏标题文字，Chrome 里测出来 3.1 秒，图片和接口都很快，Performance 面板里字体请求在 2.8 秒才完成。
一开始怀疑是「font-display 没有设置，浏览器等字体超时才回退」，查了一圈，方向不对。
把日志和配置对完，能解释这个现象的基本就这几处。中文字体文件 4MB，首屏只用到几十个字。另一种情况是字体加载期间文字用备用字体渲染，切换时重新计算 LCP。
少数情况下是字体请求排在 CSS 之后，又被 CDN 缓存成了短过期。
动手时先确认 LCP 元素和字体请求时间
curl -sI https://www.example.com/fonts/main.woff2 | grep -i -E 'content-length|cache-control'给字体加预加载
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>再往下设置 font-display 避免长时间阻塞
@font-face{font-family:main;src:url(/fonts/main.woff2) format('woff2');font-display:swap;}等前面都确认过，再按字符子集裁剪字体
pyftsubset main.ttf --text-file=chars.txt --flavor=woff2 --output-file=main.woff2恢复的判定其实很直接。字体体积降到 200KB 以内，LCP 从 3.1 秒降到 1.6 秒，文字不再出现明显跳动。
文字型 LCP 的瓶颈常常是字体，裁剪子集比换 CDN 更直接，前提是先确认 LCP 元素到底是什么。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。