给AI爬虫加了个「预渲染检测」，发现客户官网首屏要等11秒才出正文
上周给一个客户做GEO技术体检，顺手在爬虫UA里加了个预渲染检测，结果有点意外。
先交代场景：客户官网是典型的SPA架构，Vue3 + CSR，首屏所有产品参数都靠JS注入。之前一直知道这种结构对AI爬虫不友好，但具体差多少没量过。我的做法是用Puppeteer模拟三种UA——GPTBot、ClaudeBot、普通Chrome——分别记录「TTFB」「DOMContentLoaded」「正文文本节点首次可读时间」。
结果：
- 普通Chrome：正文可读 1.8s
- GPTBot：正文可读 11.3s
- ClaudeBot：正文可读 9.7s
差了五六倍。拆变量看，瓶颈不在网络层，而在JS执行队列——客户页面引了7个第三方统计脚本，全在head里同步加载。AI爬虫的UA大概率没有命中CDN的边缘缓存规则，每次都是冷启动拉全量资源，主线程被统计脚本堵死，正文渲染自然往后拖。
这里有个容易被忽略的点：很多团队做GEO只盯结构化数据的完整性，比如FAQPage、Product的字段有没有填全，但没人去看「AI拿到正文的时间窗口」。我翻了一下近期的抓取日志，GPTBot单页的等待超时阈值大概在15s上下，11s虽然没超，但留给解析和索引的余量已经很薄了，稍微加个重定向或者慢一点的接口就直接掉。
我的处理顺序是先锁口径再动手：
- 把7个统计脚本改成defer，关键参数块用SSR预输出到HTML里，保证不执行JS也能读到正文。
- 给GPTBot和ClaudeBot的UA单独配一条CDN缓存规则，TTL设长一点。
- 验收标准不是「能不能抓到」，而是「正文可读时间≤3s」，跟普通Chrome对齐。
改完复测，GPTBot正文可读降到2.6s，ClaudeBot 2.9s。但这里又冒出一个新问题：SSR预输出的参数块和JS注入后的最终DOM有细微差异，比如价格区间的小数位，预渲染是「¥1999」，JS跑完变成「¥1999.00」。AI抓的是预渲染版本，跟用户看到的不一致。我现在是让前端把格式化逻辑也挪到服务端，但这块还没完全对齐。
想问问做GEO技术落地的各位：你们验收页面速度这块，是看普通UA的Core Web Vitals，还是单独给AI爬虫UA建一套时间基线？如果两套基线打架，以哪套为准？