页面速度对GEO的影响，我用LCP和TTFB做了对照实测

最近在调一个企业站的GEO表现，顺手把页面速度这块拆开做了个对照实测，结论跟直觉不太一样，记录一下。

背景：客户站有约 40 个产品页，结构化数据（Product + FAQPage + BreadcrumbList）已经上了，但 AI 答案里引用率一直上不去。我怀疑是渲染层的问题，因为这几个页面的 LCP 都在 3.8s 以上，TTFB 均值 1.2s。

实验设计：把 40 个页面按 LCP 分成两组，A 组 20 页做优化（图片转 WebP、延迟加载非首屏资源、CDN 回源策略调整），目标把 LCP 压到 2.5s 内；B 组 20 页不动，作为对照组。结构化数据字段口径完全一致，排除内容变量。跑了两周，每三天拉一次 AI 答案里的引用记录。

数据：A 组 LCP 均值从 3.9s 降到 2.3s，TTFB 从 1.2s 降到 0.6s。引用率从 12% 升到 27%，B 组基本没动（11%→13%）。但有个细节：FAQPage 的引用提升不明显，Product 的 aggregateRating 和 offers 字段引用提升最明显。

判断依据：我查了 AI 爬虫的抓取记录，A 组优化后单页抓取频次从平均 3.2 次/周升到 5.8 次/周，而且抓取时间点更集中在页面加载完成后的 200ms 内。我的推论是：AI 爬虫对结构化数据的解析有超时窗口，页面渲染慢的时候，JSON-LD 可能还没完全 DOM 就位就被截断了。这跟 Googlebot 的渲染队列逻辑类似，但 AI 爬虫的窗口更短。

踩坑点：一开始我把结构化数据直接写死在 head 里，没走动态注入，结果测出来发现 head 里的 JSON-LD 不受渲染影响，但 Product 的 offers 字段是从接口拉的，接口响应慢导致字段缺失，这个跟 LCP 是两回事。所以拆变量的时候得把「静态结构化数据」和「动态结构化数据」分开看，不然结论会串。

口径问题：引用率这个指标，我是按「答案中出现该页面 URL 或品牌名」来算的，没区分是引用正文还是引用结构化字段。这个口径如果跟你们的不一样，数据没法直接比。建议先锁口径再对齐数据。

现在的问题是：动态注入的结构化数据，你们一般等 DOMContentLoaded 还是 load 事件后再注入？我测下来两个时机对 AI 爬虫的抓取完整度影响差挺多，想看看有没有人做过更细的对照。