点开一个短链，页面唰一下就跳走了——很多人觉得这叫“没延迟”。其实，跳转过程里藏着好几层时间开销，有些连浏览器地址栏都来不及显示，但对安全和体验的影响却不小。
跳转不是瞬间完成的
HTTP 301/302 跳转本身就有网络往返（RTT）：浏览器发请求 → 服务器返回状态码 + Location 头 → 浏览器再发新请求。哪怕服务器在同城机房，单次 RTT 也常在 10–30ms；跨省或海外，轻松破百毫秒。中间若套了 CDN、WAF 或跳转链（A→B→C），延迟就是累加的。
前端跳转更“隐蔽”但未必更快
用 location.href 或 meta http-equiv="refresh" 的方式看似本地执行，可真到发起新请求时，照样要走 DNS 查询、TCP 握手、TLS 协商——这些一步都不能少。比如：
<meta http-equiv="refresh" content="0;url=https://example.com">里面的 content="0" 只是“立即触发”，不代表“零耗时”。用户点下链接到目标页首字渲染，往往已过去 200ms 甚至更多。
延迟背后可能藏风险
攻击者就爱利用跳转延迟做文章：比如在跳转前插入一段 JS 检测用户环境，判断是不是爬虫或安全工具；或者把跳转链拉长，在中间页塞广告、埋统计、甚至诱导点击恶意按钮。你感觉“就闪了一下”，其实页面已在后台跑了好几轮脚本。
怎么看出有没有延迟？
打开浏览器开发者工具（F12），切到 Network 面板，点链接，看请求列表：如果出现多个 30x 状态码，每个都带时间戳，那就是跳转链在“排队上岗”。再点开任意一条，看 Timing 标签页里的 “Waiting (TTFB)” 和 “Content Download”，加起来就是这次跳转实际卡顿多久。
顺手一提：某些企业内网跳转还叠加了统一认证网关，登录态校验失败时会先跳登录页、填完再跳回来——这种“延迟”根本不是网络问题，而是流程卡点。
别只盯着“快”，得看“谁控制跳转”
短链服务、邮件里的推广链接、APP 内嵌 WebView 跳转……这些看似平常的入口，跳转路径早被第三方定义好了。你点的不是目标站，是跳转服务的服务器。它想加个 500ms 延迟弹窗，你拦不住；想悄悄上报设备信息，你也看不见。
所以，“有没有延迟”不只是性能问题，更是控制权问题——延迟越长、跳转层级越多，中间可插手的环节就越多。