防采集策略对网站打开速度有影响吗？

有影响，但影响大小差了两个数量级：单纯的 IP 限流、User-Agent 黑名单、签名校验只会给单次请求增加 0.1–3 毫秒，用户完全无感；真正拖慢网站的是 JS 挑战、验证码、字体混淆和把正文挪到二次接口这几类策略，首屏多花 100 毫秒到 2 秒都有可能。所以问题不是「防采集会不会变慢」，而是「你用了哪一类防采集」。

防采集策略分几类？哪些会影响打开速度？

结论：按开销从低到高排，依次是请求特征过滤、频率限制、签名校验、JS 挑战、验证码、内容二次加载，前四类基本可以忽略，后两类才是速度杀手。

请求特征过滤（判断 User-Agent、Referer、Header 顺序）就是字符串匹配，耗时低于 0.1 毫秒。IP 频率限制如果走本机 Redis，一次判断 0.1–1 毫秒；走独立 Redis 集群跨机房，1–3 毫秒。签名校验用 HMAC-SHA256 算一次 0.05 毫秒级别。这三类加起来占不到 5 毫秒，相对于一次 TTFB（首字节时间）动辄 100–300 毫秒，属于噪声。

JS 挑战不一样。它要求浏览器先下载一段 JS、执行完、算出结果、带着 cookie 再请求一次，等于多了一个完整来回。实测桌面端增加 300–800 毫秒，4G 移动端 1–1.5 秒，弱网能到 2 秒以上。验证码更极端，它不占加载时间，但占用户交互时间，人工输入一次 3–15 秒。

内容二次加载（把正文放到 XHR 接口里，前端渲染）会多一次 RTT（往返时延），4G 下 50–150 毫秒，但如果是串行请求、接口还要回源查库，累积到 500 毫秒以上很常见。

字体混淆为什么会让页面变慢？

结论：因为文字要等字体文件下载完才能正确渲染，一个没做子集化的混淆字体能到 200–500 KB，首屏直接多等半秒。

字体混淆的原理是把某些字符映射成自定义字体的私有编码，爬虫抓到的 HTML 里是正确的数字，但渲染出来是乱码位。代价是浏览器必须下载这个字体才能显示正文里的数字，默认行为是 FOIT（字体未加载时文字不可见），首屏会白一下。

做法上，把混淆范围限制在电话、价格、编号这类字段，用 woff2 格式并对字符做子集化，文件能压到 5–20 KB，代价就降到 50 毫秒以内。全站正文都混淆、字体文件 300 KB 且不做子集化，是典型的「为了防爬把用户也一起罚了」。

怎么在防住爬虫的同时把速度损失压到最低？

结论：核心思路是分层处理——静态资源完全不校验，边缘节点做轻量判断，只有可疑流量才升级到 JS 挑战。

具体做法：

1. 静态资源（图片、CSS、JS、字体）走 CDN，不经过 WAF 和业务服务器的校验逻辑，这部分占页面请求数的 80% 以上，等于把大头摘出去。
2. 把频率限制和特征判断放在 Nginx/OpenResty 层配合本机 Redis，不要每次请求都查主库。一次数据库查询 5–20 毫秒，本机 Redis 0.1–1 毫秒，差距 20 倍。
3. JS 挑战只对可疑 IP 触发，正常用户第一次通过后发 cookie，有效期设 30 分钟到 24 小时，期间免验证。
4. 搜索引擎蜘蛛走白名单直接放行，别让百度、Google 也吃一次挑战——这会直接反映在收录量上。
5. 服务端渲染页面配 Cache-Control，让 CDN 缓存 60–300 秒，防采集逻辑只作用于动态接口。

怎么判断自己的防采集确实在拖慢速度？

结论：看两个指标就够——TTFB 目标小于 200 毫秒，LCP（最大内容绘制）目标小于 2.5 秒，超过就往防采集链路上查。

分别测三种状态：关掉全部防采集、只开轻量策略、全量策略开启。如果 TTFB 从 120 毫秒涨到 400 毫秒，问题基本在 JS 挑战或跨机房 Redis；如果 TTFB 没变但 LCP 涨了 500 毫秒以上，多半是字体混淆或二次接口。

有个常见误区要澄清：防采集从来不是「挡住」，而是「提高成本」。任何前端可见的内容最终都能被抓到，投入产出比最高的组合是轻量限流 + 关键字段混淆，而不是全站上验证码。

总结一下：IP 限流、特征过滤、签名校验这三类对打开速度的影响小于 5 毫秒，可以放心上；JS 挑战、验证码、字体混淆、内容二次加载会实打实增加 100 毫秒到 2 秒。把静态资源摘出校验链路、把判断下沉到边缘、把强验证限定在可疑流量上，防采集和打开速度并不冲突。