从卡顿视频到流畅会议，延迟到底哪来的？
你有没有过这样的经历：开线上会议时对方声音断断续续，打游戏时明明操作了却半天没反应，或者加载网页总要等个两三秒才动一下。这些体验背后，大多逃不开一个词——网络延迟。
延迟不是单一问题，它可能藏在你的设备里、路由器上、运营商线路中，甚至远端服务器那边也在拖后腿。但别急，虽然没法完全消除，但通过一些通用优化手段，能把影响降到最低。
选对网络路径：DNS 和路由优化
DNS 解析慢，整个访问就起步晚。很多人还在用运营商默认的 DNS，其实换成像 1.1.1.1 或 114.114.114.114 这类公共 DNS，解析速度常常能快几十毫秒。
# Linux 或 macOS 终端测试不同 DNS 延迟
dig @1.1.1.1 google.com +short
dig @8.8.8.8 google.com +short另外，跨运营商访问也容易绕路。比如你是电信用户，却连上了联通的服务器，数据来回“跨省出差”，延迟自然高。这时候可以用工具测速选节点，或者在应用层做智能调度，自动选择最近的接入点。
减少往返次数：合并请求与预加载
每次 HTTP 请求都是一次“发消息-等回复”的过程。如果一个页面要加载 20 个小图标，发起 20 次请求，光是来回握手就得耗掉几百毫秒。
把多个小资源合成一个文件，或者用 HTTP/2 的多路复用特性，能让数据并行传输，显著降低整体延迟。前端还可以提前预判用户行为，比如在用户浏览商品列表时，悄悄预加载详情页的数据。
利用缓存，避免重复跑路
已经下载过的图片、脚本、配置文件，没必要每次都重新拉一遍。合理设置 HTTP 缓存头，比如 Cache-Control 和 ETag，可以让浏览器或 CDN 直接使用本地副本。
<meta http-equiv="Cache-Control" content="max-age=3600">移动端 App 也可以在本地保存接口返回结果，下次启动时先展示缓存内容，后台再悄悄刷新，用户体验立马顺滑不少。
压缩数据，让信息跑得轻一点
传得越多，花的时间越长。启用 Gzip 或 Brotli 压缩，能把文本类响应体积缩小 60% 以上。图片用 WebP 替代 JPEG，视频采用自适应码率，都是减轻传输负担的有效方式。
有些场景下，甚至可以牺牲一点精度换速度。比如实时位置上报，不需要每米都报，适当采样就能大幅减少数据量。
边缘计算：把服务搬得离你更近
传统架构里，所有请求都要回源到中心机房。而现在，CDN 和边缘节点可以把计算能力下沉到城市甚至区县级别。
比如你在广州发一条动态，系统可以在本地边缘节点完成审核、生成缩略图、写入缓存，不用跑到北京的主服务器走一圈再回来。这种“就近处理”模式，能把延迟从 50ms 降到 10ms 内。
客户端主动优化：别让等待感放大延迟
有时候延迟没变，但用户觉得更卡了，问题出在感知上。加个加载动画、显示骨架屏、先出文字后加载图，都能让等待过程显得更可控。
游戏里常见的“预测移动”也是这个道理：你按方向键时，客户端立刻响应动作，而不是等服务器确认后再动，这样即使有 100ms 延迟，操作看起来依然跟手。
网络延迟没法清零，但通过组合拳式的优化，完全可以做到“感觉不到”。关键是在每个环节都留心一点，积少成多，体验自然提升。