页面加载速度和 AI 抓取有没有关系

有关系，但跟传统 SEO 里说的那种关系不是一回事。搜索引擎把速度当排序因素之一，AI 这边更朴素：抓取端有耐心上限，超时就放弃；正文要靠 JS 才出来的页面，抓到的常常是空壳。速度决定的是「能不能进语料」，不是「排第几」。

这句话记住，后面很多取舍就好做了。花在压缩图片上的功夫，收益常常不如把正文从 JS 里挪出来。

抓取端的耐心比浏览器短

人打开一个页面，转三秒会等，转八秒就关掉。爬虫没有情绪，它有超时阈值和配额。一个站一天能抓多少页是有数的，单页耗时越长，抓完一轮要的天数越多。

这层逻辑在 AI 场景里更紧。大模型厂商的抓取队列要覆盖整个互联网，分给单个站的预算很小。同一批页面，快的站一轮抓完，慢的站抓一半就换下一批。

很多「内容明明不差却不被引用」的站，问题就卡在这一步：它从来没被完整读过。

换个角度算账更清楚。假设一个站有八百个内容页，爬虫单页平均耗时从两秒降到半秒，抓完一轮从三周缩到十天。同一段时间里，它能被读到的次数翻了一倍。这个倍数比任何技巧都实在。

反过来，一个站如果单页要八秒以上，抓取端往往在第二轮就把优先级降下去。降下去之后很难再提上来，因为判定依据就是历史耗时。

渲染这层开销最贵

要跑 JS 才看得到内容的页面，爬虫得启一个无头浏览器，内存和 CPU 都是几十倍。用得起渲染队列的爬虫不多，配额也少得多。

我盯过一个站，正文全在 JS 里，抓取日志每天来几十次，真正带走内容的次数接近于零。来的不是正文，是把页面渲染一遍然后走人。

这类站看起来抓取量很大，实际上一个页面都没进库。日志里「有访问」和「有收录」之间差着一整层渲染。

纯 HTML 能读到，就等于快

反过来，一个样式很土、图片没压缩、正文却在 HTML 里的页面，抓取端读起来一点不费劲。它慢的只是人的感受，不是机器的成本。

这条差别值得反复说。做优化的人容易把两件事混在一起：人的加载体验，和机器的读取成本。前者影响跳出率，后者影响收录，两边的解法有重叠也有冲突。

它影响的是取样，不是打分

AI 引用一段内容，前提是这段内容在它的语料里出现过。语料怎么来的？靠抓。抓取是有覆盖率的，覆盖面之外的页面，写得再好也等于不存在。

速度差，覆盖率就低。覆盖率低，一段内容被抽到的概率就低。这条链条里没有任何「分数」的概念，只有「在不在」。

慢站被抓的是首页和栏目页

配额有限时，爬虫会先保重点页面：首页、栏目、更新频繁的列表。内页排在后面，一批抓不完，下一批还是先抓首页。

结果就是内页长期饥饿。内容页恰恰是回答具体问题的那些页，它们最需要被读，却排在队尾。

想验证这件事，看一眼抓取日志里内页的占比。如果九成落在首页和列表页，说明配额全被浅层吃掉了。

别的地方补不回来

有人想用外部分发绕过去：站上不抓，就去大平台发。这条路能救一部分，救不了全部。大平台的内容池里，同题内容密度极高，你要跟几千篇抢一个位置。

自家站的好处是能控结构、能挂内链、能长期沉淀。这些是大平台给不了的。为了省一点速度优化的功夫把主阵地让出去，账算不过来。

自查从三步开始

先关掉 JS 看正文

浏览器插件里禁用 JS，或者直接看「查看源代码」，能看到完整正文，就算过关。看不到，说明正文靠脚本渲染。

这一步卡住的话，别的优化都不用做，做了也没用。普查一遍全站，把正文不在 HTML 里的页面列出来，这是最要紧的一张清单。

再看首字节和首屏

首字节时间长，多半是后端或数据库慢；首屏慢而首字节快，问题在前端资源。两种慢，解法完全不同。

很多站把这两件事当一件事修，改了半天 CSS，其实后端一个慢查询就吃掉了两秒。先分清在哪一段，再动手。

看返回码和重定向链

一个页面如果先跳到 https、再跳到带 www、再跳到带斜杠，等于让爬虫走三趟。每一趟都要重新建连接，耗时按倍数涨。

抓取端的耐心本来就薄，被重定向耗掉一部分，留给下载正文的就少了一截。把链路收成一次直达，代价几乎为零，收益却是立竿见影的。

顺手看一眼有没有大量 404 和 500。内链指向失效地址，爬虫一次次扑空，配额就这么漏掉了。这类漏洞在改版后的老站上特别多，一查一大片。

数一数页面挂了多少外部资源

统计代码、在线客服、字体、图标库、地图组件，一个页面挂十几个外部域是常见的。每个都要建连接，任何一个卡住，整个页面就跟着等。

抓取端不执行大部分第三方脚本，所以这些对机器没影响。它们伤的是人。人的体验间接影响内容质量判断——跳出率高、停留短，这些信号会回到搜索端。

真要动手，先改这三处

把内容页静态化

内容型站点最划算的一刀。生成静态 HTML，或者加一层页面缓存，正文直接出现在源码里。改动量小，收益最大。

缓存要注意失效时机。发布新内容、改分类、改模板之后要清，否则访客看到的还是旧页。清缓存的脚本要能手动触发，不能只靠定时。

图片别拖累首屏

正文图统一压到合适的宽度，用现代格式，加懒加载。首屏之外的图不必先下。

要注意懒加载别套在正文首段上。有些主题把懒加载写在全局，连第一段旁边的图也延后，人打开看到一片空白。这类细节改起来小，感受差别很大。

第三方脚本延后

客服、统计、埋点这些，能延后就延后，能异步就异步。它们对内容没有贡献，却抢在最前面加载。

判断标准很简单：这个脚本去掉，页面内容会不会少一块？不会，就往后放。

一个常见的误会

很多人以为图多的页面一定慢。真正拖慢的是没压缩的图，不是图本身。一张手机直出照片七八兆，压到两百千字节以内，肉眼几乎看不出差别。

另一个误会是把速度当成一次性任务。内容在加、插件在装、统计代码在换，三个月不看的站，速度会自己退回去。半年查一次，比一次查到底更管用。

还有人拿测速工具的分数当目标。那个分数是实验室里的最优解，跟真实访客的设备和网络差得远。看自家后台的真实耗时分布，比看一个满分数字有用。

抓取日志能告诉你什么

日志里每一条都带着时间、状态码、路径和耗时。把同一个路径的耗时按天排序，能看出哪几页一直慢；把状态码按路径归堆，能看出哪些链接在漏配额。

再往下看一层：同一个路径被反复抓，说明内容在变或者页面在报错；一个路径一次没被抓过，说明它压根没进抓取范围，多半是内链没接上。

这些判断不需要复杂工具，把日志按月导出，用表格做两次排序就够了。看懂日志的人，做优化时不会瞎猜。

提速别把结构改坏

为了快把正文拆成十几段异步加载，或者把标题用图片代替，这类做法省下的是毫秒，丢掉的是整段内容的可读性。

机器读页面，读的是标签和文字。标题做成图片，等于把最要紧的一行信息抹掉。图文混排的表格也是同理，看着整齐，抽取时一片空白。

速度是门槛，不是目的。过了门槛之后，决定成败的还是内容本身答得准不准。前几年有个做工业配件的客户，站慢得让人想关掉，但每篇技术文章都写到了具体型号和公差，AI 答案里照样常出现他们。快能让内容被读到，只有准才能让内容被用上。

一句话收尾

把速度这件事拆成两半看：人的那一半管体验，机器的那一半管收录。两半都要顾，但先顾机器那一半，因为它决定你有没有参赛资格。

顺序别搞反。先让正文在源码里躺着，再谈压缩、缓存、CDN。前者是零到一，后者是一到一点二。