同一个页面三次抓取，正文出现时间从2秒跳到11秒，我拆了三天变量

上周帮一个客户看官网的 AI 抓取表现，遇到一个挺典型的问题：同一个 URL，三次抓取日志里，正文（大约在 DOM 里第 1800 行之后）的首次出现时间分别是 2.1s、4.7s、11.3s。同一台机器、同一个机房、缓存都清过，变量只有时间点。

按我之前的习惯，先锁口径再验收。这次先把「正文出现」定义清楚：不是 HTML 返回时间，是渲染树里正文容器 #main-content 有第一个非空文本节点的时间。用 Puppeteer 的 performance.timing 和 MutationObserver 打点，精确到毫秒。

拆变量的过程大概是这样：

1. 网络层：三次抓取的 TTFB 分别是 180ms、320ms、210ms，差异不足以解释 9 秒的差距。排除。
2. 资源加载：第三次抓取时，首屏三张 WebP 图片的加载时间分别是 8.2s、8.4s、8.9s。但正文容器在 DOM 里排在图片之前，按渲染顺序不该被阻塞到 11 秒。
3. JS 执行：页面有个第三方推荐位脚本，同步阻塞在主线程上，执行时长 1.8s 到 4.5s 不等，取决于接口返回。第三次抓取时接口返回慢，阻塞了 4.3s。
4. 预渲染检测：这是关键。我在 robots.txt 里没写 User-Agent: * 的预渲染规则，但页面 JS 里有一段检测 navigator.webdriver 的逻辑，命中了就延迟加载正文容器。第三次抓取时 UA 恰好被识别为自动化工具，触发了延迟。

最后定位到两个叠加因素：第三方推荐位脚本的同步阻塞，加上一段不该存在的 navigator.webdriver 检测逻辑。删掉检测逻辑、把推荐位脚本改成 async 之后，连续抓了 20 次，正文首次出现时间稳定在 1.9s 到 2.3s 之间。

这个事让我更确信：GEO 的技术底子不在内容层，在渲染层。结构化数据再规范，如果正文要 11 秒才出现，爬虫的观测窗口根本等不到。

我现在的验收表上加了两个字段：first-contentful-paint 和「正文容器首个文本节点时间」，都精确到毫秒，并且要求连续抓取 10 次取 P90。

想问问各位：你们在验收时，正文出现时间是按首屏算还是按 DOM 算？有没有人遇到过 navigator.webdriver 检测导致 AI 爬虫被区别对待的情况？