在被引用的域名中，通过Core Web Vitals的比例为58%。
在拥有现场数据的被引用域名中，整体58%通过了Core Web Vitals ，被引用最多的组在**81%**的加载中记录了良好的最大内容绘制（LCP）。总体而言，AI引用的页面速度相当快——但远非普遍如此：仍有相当一部分未能通过。
AI引用的页面速度有多快？
将每个被引用域名按其在AmICited追踪的提示词响应中被引用的次数分组，并结合Google的真实用户Core Web Vitals数据，各组之间呈现出一致的规律。被引用10次以上的组（659个有数据的域名）位于一端，而被引用1-2次的组（4,313个域名）位于另一端。我们可以测量的每个健康指标——通过率、服务器响应时间 和性能评分——趋势方向一致，这就是为什么这一（适度的）信号可信而非噪音。
底层数据
| 引用频率 | 有CrUX数据的域名数 | 通过Core Web Vitals | 中位TTFB | 平均性能评分 |
|---|---|---|---|---|
| 被引用10次以上 | 659 | 60% | 804 ms | 76.5 |
| 被引用3-9次 | 1,584 | 58% | 893 ms | 74.9 |
| 被引用1-2次 | 4,313 | 57% | 910 ms | 74.9 |
这对AI搜索可见性意味着什么
技术健康的页面被引用的频率确实略高一些，但这里的效应很小——网站健康度看起来是一个辅助因素，而非主要驱动因素，决定AI引擎是否会引用你。内容相关性显然更为重要（请参阅来源和主题层面的报告）。实际解读：修复Core Web Vitals和服务器响应时间是值得做的——它消除了一个轻微的阻力，对用户也有帮助——但单靠这一点并不能让你进入一个引擎的引用来源。将其视为入场券，然后在相关性上竞争。
超出平均值：未通过的42%告诉了我们什么
这组数据中最引人注目的数字不是通过Core Web Vitals的60%——而是被引用最多的组中未通过的40%。即使在AI引擎最常引用的页面中，也有四成的域名未能通过谷歌的Core Web Vitals评估。这是对"AI引擎正在对潜在来源进行性能检查"这一观点的有力反驳。
如果AI引擎设置了严格的性能门槛，我们会在被引用最多的页面中看到近乎普遍的CWV合规性。然而，我们看到的分布与更广泛的网络相似——只是略有上移。这告诉我们，AI引擎选择来源主要基于内容相关性、权威性和回答用户问题的能力，而技术性能只是次要因素。
40%的失败率也意味着，如果你的网站当前未通过Core Web Vitals，你并不孤单——即使在互联网上被引用最多的域名中也是如此。修复你的性能问题将使你进入多数阵营，但单靠这一点不会改变你的引用状况。被引用最多与被引用最少的组之间的性能差距是真实存在的，但小到足以让你需要在多个指标上从"差"提升到"好"——而不仅仅是在一个指标上勉强达标。
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
性能评分背后的故事：76.5与74.9的实际含义
被引用最多的域名平均Google PageSpeed性能评分为76.5，而被引用最少的为74.9，在100分制中仅差1.6分。作为参考，一张未优化的图片或一个未压缩的CSS文件就可能导致PageSpeed评分波动5-10分。我们看到的差距是真实存在的，但小到微不足道——这种差异可以通过被引用最多的域名稍微更可能使用CDN或稍微更可能有专门的性能预算来解释。
实际含义很明确：如果你的PageSpeed评分在70分左右，你已经处于AI引用频率不受性能显著限制的范围。追求90分以上的评分，对AI可见性 的回报会递减。更有效的时间利用方式是确保你不处于"差"的范围（低于50分），然后将重心转向内容策略。
这与传统SEO智慧如何相互作用
二十年来，SEO从业者一直被教导说网站速度是一个排名因素。对于谷歌搜索来说确实如此——页面体验信号，包括Core Web Vitals，是谷歌排名算法的一部分。但AI搜索引擎 如ChatGPT、Perplexity和Gemini 基于根本不同的原则运作。它们并非实时抓取网络来构建搜索索引，而是从一个预先索引的语料库中检索内容并综合生成答案。
这一区别对于你如何思考性能问题至关重要。在传统SEO中，较快的页面可能会在相同查询下超越较慢的页面（其他条件相同）。在AI搜索中，引擎并非以同样的方式将两个页面进行直接比较——它是在决定是否在答案中包含某个来源。性能方面的准入门槛似乎比传统搜索排名低得多，而对内容的具体性和权威性的要求则高得多。
实际结论：如果你已经在做良好的SEO性能工作，你可能已经处于AI引用不受速度限制的范围。不要停止这项工作——它对你的真实用户和传统搜索排名都有益。但不要期望额外的性能优化能为你打开新的AI引用大门。打开这些大门的是内容。
针对AI可见性性能工作的实用建议
将TTFB 作为AI可见性的主要性能指标。 在所有速度指标中，TTFB在被引用最多和被引用最少的组之间差距最大（804毫秒对比910毫秒）。它也是你最直接可控的指标——它反映的是服务器和CDN配置，而非前端复杂度。
目标设定为"足够好"，而非"完美"。 如果你的页面大部分时间都能通过Core Web Vitals，并且TTFB在1秒以内，你就处于性能不会拖累AI引用的范围。进一步的投资应投入内容而非速度。
审计你的服务器配置。 常见的TTFB改进包括：启用HTTP/2或HTTP/3、使用带边缘缓存的CDN、优化数据库查询以及启用服务器端缓存。这些通常是一次性修复，带来持续收益。
不要忽视移动端。 Google的CrUX数据按设备分类。如果你的移动端性能明显差于桌面端，你可能正在制造一个跨平台影响AI爬虫的差距。确保你的性能优化适用于两者。
监控性能漂移。 随着你添加功能、第三方脚本和内容，网站速度会随时间下降。建立定期的性能监控（每月一次就够了），以便在性能下滑到"差"的范围之前发现问题。
方法论
这是AI已经引用的页面之间的关联性，而非因果关系的证明：通过将Google CrUX/PageSpeed现场数据与每个域名在AmICited的1,905个追踪提示词中被引用的频率进行关联计算。被引用的8,845个域名中，有6,556个（74%）有CrUX数据可用。域名按被引用的响应次数分组；在每个组内，我们计算网站健康指标的平均值。当一个域名的大多数被审计URL在真实用户（CrUX）数据中通过了Google的LCP /INP /CLS阈值时，该域名即"通过Core Web Vitals"；TTFB和性能评分同样取平均值。没有足够CrUX数据的页面被排除在外。由于AmICited的提示词偏向SaaS、电商和客服主题，这些数据描述的是此类查询中被引用的网站。这种关系是真实但温和的，且为相关性关系——我们并非声称更快的页面导致了更多引用。
