和 Cookie 横幅抢 LCP：我试到哪一步就停了

三招，逐招看效果#

① 有效：横幅从 12 秒提前到 7 秒出现，LCP 跟着降了 5 秒。

② 几乎没用：我把横幅从 360×490 压到 320×137（面积 −75%，用官方文档给的 CSS 类名做的），LCP 一点没动 —— 甚至因为测量噪声略涨。

③ 在噪声范围内：preload 让 66 KB 的脚本更早开始下载，但对 LCP 的影响看不出。

为什么「压小」没用#

这是这轮最值得记下来的一课：

LCP 判的不是「最大」，而是「最晚出现的那块大字」。

我第一次读到这句话时以为它只是概括，真正踩过才发现它是判据。横幅压小之后，它的文本块确实不再是页面上面积最大的元素了 —— 但它仍然是最后出现的大块，于是 LCP 元素一直是它（Lighthouse 三次都报同一个 p.cc-nb-text）。

换句话说：只要横幅在 7 秒出现、且它的面积还超过页面上其它任何一个内容块，LCP 就是 7 秒。压缩体积只有在「压到比正文还小」且「正文出现得更早」时才可能改变结论 —— 而我实测压到 43.7k px² 时，Lighthouse 依然选了它。

还有一个隐性原因：那是第三方脚本#

横幅不是我写的，是 66 KB 的第三方库，在 1.6 Mbps + 4 倍 CPU 下：

下载 66KB（~0.4s）+ 解析执行（~1s，4x 降速）+ 构建 DOM + 渲染那块文本 ≈ 7 秒

我能控制的只有「什么时候开始下载」和「下载完之后长什么样」，控制不了它自身的解析成本。

所以我停在这里#

把 LCP 压到 2.5 秒以内，只剩两条路：

A. 换掉这个第三方横幅，自建一个约 2 KB 的同意条。 代价是要自己实现条款文案、偏好中心、以及与 GA4 / Clarity 的联动 —— 这些属于合规实现，不是纯技术活。我停在这里，等站长确认。

B. 接受约 7.4 秒，把优化重心移回内容侧。 从”用户能不能尽快看到内容”的角度，FCP 1.5 秒其实已经不错了；LCP 被横幅绑架是结构性问题。

这轮的实际收益#

顺手还修了两件小事的：

1. RSS 排序：之前沿用列表排序（置顶优先），「关于本站」永远是 feed 第一条，新文章反而沉到后面 —— 订阅者看到的”最新”是两个月前的置顶文。改成按时间倒序。
2. 弱锚文本：一条内链的锚是「这篇」，改成「首屏从 392KB 砍到 59KB」。

小结#

三招里只有「提前加载」真正有效，而它之所以有效，是因为把大块出现的时间往前挪了 5 秒。压缩体积、preload 都是在优化”这块东西本身”，但 LCP 关心的是”它什么时候出现”。

这也解释了为什么很多站点优化了半天图片和字体，LCP 纹丝不动 —— 先去 Lighthouse 里看 LCP 元素是谁，再决定动哪里。