从资源体积入手：压缩与合并静态文件

网络延迟的第一大杀手往往是“传输太多字节”。即使带宽充足，每多传1KB数据都会增加RTT（往返时间）内的排队和解析成本。实战中最有效的操作是启用Gzip或Brotli压缩，其中Brotli对文本资源通常比Gzip再减少15%～20%体积，但需注意服务器与浏览器是否都支持。与此同时，合并CSS与JS文件能减少HTTP请求数量，但现代HTTP/2下“过度合并”反而浪费缓存，因此更推荐按需打包，将首屏关键CSS内联、非关键脚本延迟加载。

除了压缩和合并，还要对图片进行格式与尺寸优化。使用WebP或AVIF替代旧式JPEG/PNG，可显著减少图片体积；同时利用CSS Sprite或Icon Font将多个小图标合并为一次请求。对于大图，应实现懒加载，并配合`srcset`让移动设备只下载合适分辨率的图片。每次减少几KB，长远看能节省数十次往返时间，对弱网用户尤其明显。通过构建工具如Webpack、Vite自动生成压缩产物，并定期审计资源大小，可以持续保持“瘦身”状态。

缩短连接路径：合理配置CDN和边缘缓存

延迟的另一大来源是“物理距离”。用户访问源站如果跨越数千公里，即使网络再快，光速传播也会产生几十甚至上百毫秒时延。搭建或接入CDN，将静态资源分发到离用户最近的节点，是缩短路径最直接的方案。配置时需要注意：为不同文件类型设置不同Cache-Control，例如图片缓存30天、CSS/JS缓存7天，并利用文件内容哈希作为版本号，避免缓存失效后重新下载。

边缘缓存不仅限于静态文件，动态接口也可以借助CDN的边缘计算能力实现“Partial Cache”。例如，将用户无关的新鲜内容用边缘HTML片段缓存，通过ESI（Edge Side Includes）或边缘函数拼接页面，能大幅降低回源请求。同时，源站应开放CORS并启用适当的`Vary`头，保证CDN不会缓存错误版本。在多地部署时，可采用Anycast或DNS智能解析，让每个用户自动接入最近的节点。实践证明，将CDN命中率从70%提升到95%，整体首屏延迟可下降40%以上。

让浏览器更聪明：预解析、预连接与预加载

有时延迟并非资源本身，而是浏览器“按需发现”的过程太慢。用户在输入URL后，浏览器需要依次解析HTML、发现CSS、再发现JS和图片，每个步骤都会增加一次往返。通过Preconnect可以提前与第三方域名建立TCP+TLS连接，消除后续请求的连接握手时间。例如，在HTML头部加入``，能显著缩短字体和CDN资源的等待。

更进一步，使用`dns-prefetch`提前解析域名IP，或使用`preload`加载关键资源（如首屏字体、Hero图片），让浏览器在解析HTML时就发起请求，而不是等CSS解析完毕。合理使用`prefetch`可以让用户即将访问的下一页面提前在空闲时下载，实现“未来延迟瘦身”。但要注意，预加载过多资源会抢占带宽，反而拖慢首屏。应通过Performance API和Lighthouse审计，只对真正影响LCP（Largest Contentful Paint）的资源做预加载，并设置`as`属性避免二次获取。利用`fetchpriority="high"`标记关键图片，浏览器会更智能地安排请求顺序。

服务端提速：启用HTTP/2与TCP BBR优化

网络优化最终要回归协议层面。HTTP/1.1存在队头阻塞和重复连接等低效问题，而HTTP/2支持多路复用、头部压缩和服务端推送，能在一个TCP连接上并行传输所有资源，大幅减少TCP握手的往返次数。在Nginx或Apache中开启HTTP/2只需几行配置：`listen 443 ssl http2;`。同时，确保所有资源使用HTTPS，因为HTTP/2强制加密。启用后，页面请求排队时间可减少80%以上。

TCP层同样值得调优。Linux默认的拥塞控制算法常为Cubic，在高带宽高延迟（BDP）链路上表现不佳。开启TCP BBR后，能提高吞吐量并降低队列延迟，尤其适合移动网络。可以通过`sysctl -w net.core.default_qdisc=fq`和`sysctl -w net.ipv4.tcp_congestion_control=bbr`启用。另外，增大TCP初始窗口（initcwnd）到10或更多，可让第一个数据包携带更多内容，减少慢启动次数。服务端还应启用TLS 1.3，其0-RTT模式允许恢复会话时直接携带请求，几乎消除握手延迟。但注意0-RTT存在重放风险，只对幂等GET请求启用。综合这些协议优化，网络延迟能再降低一个量级。