HTTP性能优化实战
在 Web 应用的用户体验中，性能是不可忽视的核心指标。研究表明，页面加载延迟每增加 1 秒，用户流失率可上升 7%，而 HTTP 作为数据传输的基石，其性能直接决定了应用的响应速度。
一、连接层面：减少握手开销，提升复用效率
HTTP 基于 TCP 协议实现，而 TCP 的 “三次握手”“四次挥手” 在高频请求场景下会产生显著延迟。优化连接层的核心是减少握手次数和提升连接复用率。
1. 升级 HTTP 版本：从 1.1 到 2/3 的质的飞跃
HTTP/1.1 的痛点：虽然支持持久连接（Connection: keep-alive），但存在 “队头阻塞” 问题 —— 同一连接中，前一个请求未完成时，后续请求必须排队等待，导致带宽利用率低。
HTTP/2 的突破：通过多路复用（Multiplexing）将多个请求拆分为二进制帧，在同一连接中并行传输，彻底解决队头阻塞。实测显示，在加载 100 个小资源的场景下，HTTP/2 比 1.1 提速 40% 以上。
HTTP/3 的进阶：基于 QUIC 协议（UDP 之上的可靠传输），实现 0-RTT 连接建立（首次连接 1-RTT，复用连接 0-RTT），并通过连接迁移技术解决网络切换（如 WiFi 转 4G）时的连接中断问题。目前 Chrome、Firefox 等主流浏览器已支持，适合对实时性要求高的场景（如直播、在线协作）。
实战建议：Nginx 配置 HTTP/2 仅需在 listen 指令后添加http2参数，同时需配置 SSL 证书（浏览器仅支持 HTTPS 下的 HTTP/2）：
server {
listen 443 ssl http2;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
}
2. 连接复用与预热：避免频繁创建销毁
长连接超时时间调优：HTTP/1.1 的 keep-alive 默认超时时间通常为 60 秒，可根据业务场景调整（如高频交互应用设为 120 秒，静态资源站设为 30 秒），避免连接闲置浪费资源。
域名分片与合并的平衡：早期为突破浏览器对同一域名的并发连接限制（通常 6 个），会采用多域名分片（如img1.example.com、img2.example.com），但 HTTP/2 已支持同一域名下的无限并发，此时应合并域名以减少 DNS 解析和 SSL 握手开销。
预连接与预加载：通过<link rel="preconnect" href="https://cdn.example.com">提前建立与 CDN 的连接，或用<link rel="prefetch" href="page2.js">预加载可能访问的资源，将延迟 “提前消化”。
二、资源传输：压缩、合并与优先级调度
HTTP 传输的核心是 “用更少的字节，更快地到达用户”，资源优化需从体积压缩和传输策略两方面入手。
1. 数据压缩：从文本到二进制的极致压缩
文本资源压缩：
Gzip 与 Brotli：Gzip 对 HTML、CSS、JS 的压缩率约 30%-70%，而 Brotli 在相同压缩级别下比 Gzip 高 10%-15%（但 CPU 消耗略高）。Nginx 可通过gzip_types和brotli_types指定压缩类型，并设置gzip_comp_level 5（平衡压缩率与 CPU）。
注意：图片、视频等二进制文件无需 Gzip 压缩（反而可能变大），应跳过压缩。
图片与媒体优化：
格式选择：WebP 比 JPEG 小 25%-35%，AVIF 比 WebP 再小 25%，可通过<picture>标签实现降级兼容：
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="示例图">
</picture>
-
- 响应式图片：用srcset和sizes根据设备分辨率加载不同尺寸图片，避免 “小屏加载大图” 的带宽浪费。
2. 资源合并与拆分：平衡请求数与缓存粒度
JS/CSS 合并：将多个小文件合并为一个（如通过 Webpack 打包），减少请求数，但需避免过度合并导致 “牵一发而动全身”—— 某行代码修改后，整个大文件缓存失效。建议按 “业务模块” 拆分（如common.js+home.js+user.js）。
关键资源优先加载：通过<script defer>（延迟执行）或<script async>（异步执行）避免 JS 阻塞 DOM 解析，将首屏渲染必需的 CSS 内联到 HTML（减少一次 CSS 请求），非关键 CSS 用media="print"标记为低优先级。
3. HTTP/2 优先级：让重要资源 “插队”
HTTP/2 允许为请求设置优先级（1-8 级），浏览器默认将 HTML、CSS 设为高优先级，图片设为中低优先级。开发者可通过Link头或服务器配置调整：
Link: </critical.css>; rel=preload; as=style; priority=high
实测显示，为首屏 CSS 设置高优先级后，页面渲染时间可缩短 15%-20%。
三、缓存策略：减少重复传输，利用本地存储
缓存是 HTTP 性能优化的 “性价比之王”，通过合理配置缓存规则，可将重复请求的响应时间从数百毫秒降至 0。
1. 缓存控制：Cache-Control 与 Expires 的协同
强缓存：用Cache-Control: max-age=31536000（单位秒）指定资源有效期（如 1 年），期间浏览器直接使用本地缓存，不发送请求。适合静态资源（如图片、库文件）。
协商缓存：当强缓存过期后，浏览器发送请求携带If-Modified-Since（对应Last-Modified）或If-None-Match（对应ETag），服务器判断资源未修改时返回 304，避免重新传输数据。适合动态但不频繁更新的资源（如用户头像）。
实战配置示例（Nginx）：
# 静态资源强缓存1年
location ~* \.(jpg|jpeg|png|webp|css|js)$ {
expires 1y;
add_header Cache-Control "public, max-age=31536000";
}
# 动态资源协商缓存
location ~* \.(php|jsp)$ {
add_header ETag "$request_filename:$mtime";
if_modified_since off;
expires off;
}
2. 缓存失效策略：指纹与版本控制
当资源更新时，需确保用户获取最新版本，常见方案：
文件名加哈希：如app.8f3d7.js，文件内容变化时哈希值改变，触发新请求。
版本目录：如/v2/css/style.css，版本升级时切换目录。
避免在 URL 后加随机参数（如style.css?v=123），可能导致缓存失效。
四、服务器与网络：从源头提升响应速度
1. CDN 加速：让资源 “离用户更近”
CDN 通过全球分布式节点缓存静态资源，用户请求会被路由到最近的节点，降低网络延迟。关键优化点：
静态资源（图片、JS、CSS）全部接入 CDN，动态内容（API 接口）可通过 CDN 的 “动态加速” 功能优化路由。
启用 CDN 的 “压缩”“HTTPS”“HTTP/2” 功能，与源站策略保持一致。
2. 服务器响应优化：减少后端处理时间
接口性能优化：通过数据库索引优化、缓存中间件（Redis）减少查询耗时，将 API 响应时间控制在 100ms 内（理想值）。
负载均衡：用 Nginx 或云服务商的负载均衡将请求分发到多台服务器，避免单点过载。
启用 GZIP/Brotli 压缩：服务器端压缩后再传输，减少带宽消耗（配置见上文）。
3. 减少不必要的 HTTP 请求
接口合并：将多个关联的 API 请求（如用户信息 + 订单列表）合并为一个，减少握手开销。
删除冗余 Cookie：Cookie 会随每个请求发送，对静态资源（如 CDN 上的图片）应移除 Cookie（通过独立域名实现，如img.example.com不设置 Cookie）。
五、实战效果：从 “3 秒” 到 “0.8 秒” 的优化案例
某电商网站优化前首屏加载需 3.2 秒，通过以下步骤优化后降至 0.8 秒：
升级 HTTP/2，解决队头阻塞，减少连接建立时间（-0.6 秒）；
静态资源接入 CDN，启用 WebP/AVIF 格式，压缩体积（-0.9 秒）；
配置强缓存（图片、JS/CSS 缓存 1 年），首屏关键 CSS 内联（-0.5 秒）；
合并 API 请求，优化数据库查询，减少接口响应时间（-0.4 秒）。