AB页跳转是本文的核心主题。上个月接了个做减肥产品的客户，百度账户每天烧两千多，落地页跳转的延迟在1.8秒到2.5秒之间来回飘。用户从点击广告到看到真正的产品页，要经历两次白屏。最直接的后果是页面跳出率干到78%，表单提交量一天不到10条。客户急得天天打电话，说再这样下去账户要停了。
这个场景我相信做AB页跳转的老手都不陌生。大部分时候我们一门心思研究怎么防检测、怎么过审，反倒把最基础的跳转速度给忽略了。实际上在百度这套流量体系里，跳转速度不光影响用户转化，还会影响账户质量度的判断。老账户跳转慢了直接掉展现，新账户跳转慢了会被系统判定为体验差，人为标记的风险也更高。
这篇文章我就把AB页跳转提速这件事掰开揉碎地讲一遍，从浏览器发起请求到最终渲染白页，每一步都有对应的优化手段和检验标准。全文没有虚的，全是验证过的参数和配置，你照着调就能看到变化。
先搞清楚你的跳转慢在哪一步
很多人的思路是“全网CDN加速”“服务器换更高配”，一顿操作下来钱没少花，速度还是原地踏步。原因是你根本没定位到瓶颈。AB页跳转链路至少包含五个环节：DNS解析、CDN节点回源、服务器响应、规则引擎判断、前端资源加载。任何一个环节延迟1秒，整体就慢1秒。所以动手之前我们先做个分段测速。
最简单的方法是用Chrome的开发者工具，打开Performance面板，记录一次完整的页面跳转。看Waterfall里每个请求的timing。如果卡在“Stalled”和“Request sent”之间，多半是网络连接和带宽问题。如果卡在“Waiting for server response”，那是服务器处理速度不行。如果白屏时间很久但HTML下载很快，那就是前端渲染或者规则引擎的问题。
再粗暴一点的做法，直接在你配置的跳转域名下建一个静态html文件，里面什么都不放，就写一个“test”字符。然后不带cookie、不带参数直接访问，记录响应时间。如果这个纯静态文件也要花1秒以上，说明服务器和网络链路有硬伤；如果这个文件秒开，但带UA跳转后变慢，那就是规则引擎那边拖了后腿。
优化方向一：DNS和网络链路，别让用户卡在第一步
我这里先讲一个最常见的坑：很多人做AB页跳转，使用的主域名和跳转域名全都挂在同一个DNS服务商上，而且还用的是默认配置。你的用户分布在全国各地，有的用移动宽带，有的用联通4G，有的用电信光纤。这几个运营商之间的DNS解析速度差别很大。如果解析一个域名要300毫秒，你还没开始跳转就已经输了。
解决办法有两个。第一，DNS服务商必须选支持EDNS Client Subnet的，也就是ECS功能。这个功能可以让DNS服务器根据用户的IP归属地返回最近的节点，而不是统一解析到服务器默认地址。阿里云DNS和腾讯云DNSPod都有这个选项，你在解析配置里面找到“ECS”开关，打开就行。第二，主域名和跳转域名不要用同一个域名。比如你的白页域名是check.com，真实落地页域名是offer.com，这两个域名的DNS必须分别配置在不同的服务商那里。这样即使一个服务商出问题，另一个还能正常解析。
另外还有个参数很多人不去调，就是TTL值。AB页跳转的域名解析记录，默认TTL如果设置成10分钟也没问题，因为生效后IP不变。但是新配的域名如果TTL设长了，你调整IP之后要等很久才能全局生效。稳妥的做法是配置阶段把TTL设成60秒，等完全稳定了再改成300秒。这不算提速，但能减少你更换服务器时的故障时间。
CDN节点怎么选才能不拖后腿
不少做AB跳转的朋友喜欢用CDN，因为能隐藏源站IP。但CDN选得不合适，反而会加一层跨网延迟。我之前用某家CDN，默认节点覆盖华南地区的IP段，但我的客户主投华东和华北，导致大部分用户都回源到华南节点再转发回来，一跳多出来200ms。
优化方法是把CDN的区域调度策略改成按运营商线路走。比如阿里云CDN支持设置“区域优先”和“运营商优先”。你需要在CDN配置里的“回源策略”中选择“就近回源”，并且把源站地址从域名改成IP，减少一层DNS递归解析。另外，如果你的跳转域名之前没有接入CDN，可以试试直接用nginx做七层转发，配合TCP优化参数，有时候反而比CDN更快。
优化方向二：服务器响应速度才是硬道理
服务器响应慢是最让人抓狂的，因为你不知道是PHP进程卡住了，还是数据库连接池满了，还是内核的TCP参数有问题。做AB页跳转的服务器，配置不用多高，2核4G就能支撑日十万级PV。关键在软件层面的优化。
Web服务器我建议直接用OpenResty，不要用传统的Nginx+PHP-FPM架构。OpenResty把Lua脚本直接嵌在Nginx进程里，处理规则判断不需要向后端PHP服务发请求。这样一次用户访问，从收到请求到返回302或200，全程只经过一个进程，没有跨进程通信开销。实测相同配置下，OpenResty处理跳转逻辑的速度是PHP-FPM的3倍以上。
具体配置参数上，我会调整三个地方。第一，Nginx的worker_processes设为CPU核心数，worker_connections设成4096。第二，打开keepalive连接，让同一个用户的多个请求复用TCP连接，避免重复握手。在upstream配置里加上keepalive 256。第三，启用gzip压缩，对HTTP响应体做压缩，但注意302跳转的响应体本来很小，gzip作用不大，主要是针对后面落地页首屏的静态资源。
规则引擎的缓存策略
跳转规则是AB页的灵魂，但规则引擎如果每来一个用户就去数据库查一次规则，速度肯定快不了。比如你配置了100个白名单规则和50个黑名单规则，每次请求都要把这些规则和当前用户做匹配，如果规则存储在MySQL里，那一个请求至少多出两次数据库查询。
我的做法是启动时把全部规则加载到共享内存，用Lua的table结构存在Nginx worker进程里。规则更新的时候通过reload接口去热刷新内存中的缓存，而不需要重启Nginx。这样每条请求的判断时间可以控制在0.05ms以内。甚至可以做到只对可疑流量走完整规则链，对明显放行的流量只做一次白名单匹配，减少CPU开销。
优化方向三：前端渲染的白屏时间压到300ms以内
AB页跳转最终要落到真实落地页，落地页的加载速度同样决定整体体验。我见过很多团队优化了跳转链路，但落地页用的是老掉牙的jQuery库，首页图片十几张原图，一进去白屏3秒。这样用户感知到的依旧是“慢”，前面的优化等于白做。
落地页优化的核心是压缩首屏资源。首先把所有JS文件合并压缩成一个文件，放在body底部加载。CSS也只需要把首屏需要的样式内联到html里，其他样式用异步加载。图片必须用WebP格式，并且加上lazy-loading属性。再一个，真别用大体积的UI框架，现在做落地页用纯css+js就够了，移动端首屏资源控制在80KB以内完全可以做到。
给一个具体参考值：优化后的落地页，从HTML文档开始下载到页面首屏绘制完成，时间要小于300ms。这个标准可以通过Performance面板的“Largest Contentful Paint”来衡量。如果LCP大于1秒，那就要继续砍资源，或者改用服务端渲染。
真实场景一：减肥产品客户如何把跳转延迟从2秒降到400ms
回到开头那个客户。当时我给他做了三项检查。第一，DNS解析时间占用了600毫秒，因为他的白页域名和落地页域名都在同一个DNS服务商，且没有开启ECS，导致北方用户解析到了南方节点。第二，服务器用的是Windows+Apache，进程模型处理请求非常慢。第三，规则引擎是PHP写的，每来一个用户都要连接一次MySQL查询规则，光数据库连接就花了300ms。
我直接把服务器换成了Linux+OpenResty，规则全部改成内存缓存。DNS服务商换成了支持ECS的智能解析，并且把白页域名单独切到了CDN。落地页那边把首屏图片从3MB压缩到200KB，JS从1.2MB精简到150KB。改完之后我用自己的手机（联通4G）连着测了10次，平均跳转耗时从1.9秒降到了420ms。客户的表单提交量在第二周就翻了3倍，账户质量度也跟着上来了。
真实场景二：一个技术流客户遇到跳转偶发卡顿的排查过程
还有一个做教育产品的客户，服务器配置很高，理论上不该慢。但他说有时候跳转要等3秒，有时候又秒开。这个“偶尔卡顿”最难查。我上去一看，发现他的服务器是香港的，带宽只有2Mbps。高峰期有十几个用户同时访问时，带宽被打满，每个连接都在排队。更坑的是他在nginx配置里开了gzip压缩，三张图片一共1.5MB，gzip对图片完全没效果，白白耗CPU。
解决方案很简单：把图片搬到对象存储加CDN，源站只留HTML和JS。同时把带宽升到5Mbps，gzip只对txt、html、css这类文本资源开启。调整之后，再也没出现过那个用户反馈的“间歇性卡顿”。这里想提醒大家的是，快不快要看峰值时的体验，不是测试时一个人访问很流畅就算完事。
常见问题与解决对照
问题一：跳转前有白屏，但服务器响应日志显示200状态码挺快
这是用户感知慢，但服务器处理不慢的典型症状。根因大概率是前端渲染阻塞了。检查一下你的落地页是不是用JS去跳转的，比如用window.location.replace而不是服务端302。如果是，直接在nginx层把replace改成return 302，省掉JS执行的几十毫秒和中间多一跳HTTP请求。另外检查HTML头部的内联样式和脚本，如果有阻塞渲染的同步script，把它们挪到body尾部。
问题二：移动端慢，电脑端快
这往往是图片太大。移动端带宽受限，同样的2MB图片，电脑端1秒加载完，手机端要3秒。把图片尺寸按照移动端屏幕宽度生成，比如750px宽，同时使用CDN的图片压缩功能（大多数CDN都有自适应压缩）。另外检查是不是引用了未压缩的jQuery库，移动端上用原生JS或者轻量级框架（比如Zepto）性能提升明显。
问题三：跳转规则命中没问题，但跳转后的地址打开慢
这说明你的落地页服务器本身性能不行。有些朋友图便宜，用虚拟主机来跑落地页，单个IP上几十个网站共享资源，一到晚高峰就跑不动。把落地页迁移到独立服务器，或者用OSS+CDN的静态页面方案。如果落地页是动态的，给数据库和PHP加Redis缓存，减少重复查询。
问题四：配置了CDN之后反而变慢了
检查CDN的回源Host是否和域名一致，如果不一致会导致每次回源都重新解析。再检查CDN的缓存命中率，如果动态规则命中不了缓存，CDN反而多了一层节点转发。对于AB页跳转场景，建议只对静态资源用CDN，动态跳转逻辑放在源站。我的配置是：白页域名用CDN加速静态文件，跳转逻辑由OpenResty直接处理，不走CDN。
最终优化清单，照着设置就能见效
给你一个可以直接保存到备忘录的检查清单。每完成一项就打个勾，全部完成后基本能保证跳转耗时在500ms以内。
- 白页域名和落地页域名分开，分别配置在不同DNS服务商，开启ECS功能
- Web服务器改用OpenResty，禁止Windows+Apache组合
- 规则加载到内存，不做数据库查询
- CDN只加速静态资源，动态跳转走源站
- 落地页首屏资源压缩到100KB你试试
- 开启nginx的http2和keepalive，一次连接复用到底
- 监控峰值带宽利用率，超过70%就要扩容
做完这七步，你的AB页跳转速度基本不会比普通网页慢了。如果还有问题，大概率是某个环节的配置细节不对，按我前面写的排查流程一步步来就行。做Cloak这行，稳和快都很重要，快有时候反而是最有效的防御策略，因为用户和平台都不会给一个卡顿页面太多耐心。
