真实提升效果取决于用户收到完整响应的速度，需通过日志中$body_bytes_sent和$request_time对比gzip开启前后的变化来评估。
直接看日志里的 $body_bytes_sent 和 $request_time，再比对开启 Gzip 前后的变化，就能判断真实提升效果。关键不是“压了多少”，而是“用户多快收到完整响应”。
记录压缩前后的真实耗时与传输量
必须先确保日志格式包含核心指标：
- 在
http块中定义带压缩信息的日志格式，例如：log_format gzip_test '$remote_addr [$time_local] "$request" $status $body_bytes_sent $request_time "$http_accept_encoding" $upstream_response_time'; - 启用该格式并轮换日志（避免混入旧数据）：
access_log /var/log/nginx/gzip_test.log gzip_test; - 特别注意：
$body_bytes_sent是实际发给用户的字节数（已压缩），$request_time是用户感知的总延迟，这两个值才是评估依据。
用日志数据对比压缩前后的关键差异
不要只看平均值，要分层分析：
- 抽样对比相同 URL、相似请求量（如每天上午10点）、相近客户端（
$http_accept_encoding含gzip的请求）的两组日志； - 用命令快速统计压缩收益：
awk '$7 > 0 {sum+=$5; count++} END {print "avg size:", sum/count " bytes"}' gzip_test.log（计算平均响应体大小） - 筛选慢请求是否减少：
awk '$6 > 1.5 {print $0}' gzip_test.log | wc -l（统计 request_time 超 1.5 秒的请求数，对比开启前后） - 检查大响应体是否明显变小：比如原来
$body_bytes_sent > 100000的 HTML 页面，开启后是否普遍降到 30000 以下。
排除干扰，确认是 Gzip 起效而非其他因素
日志里容易误判的几个点：
-
$upstream_response_time如果远大于$request_time，说明瓶颈在后端，Gzip 影响极小；只有当两者接近时，压缩才真正影响终端耗时； - 如果
$http_accept_encoding不含gzip，该请求根本没走压缩流程，日志里看到的$body_bytes_sent就是原始大小，需过滤掉； - HTTPS 环境下若同时启用了不安全的 TLS 配置（如 TLS 1.0/1.1 + 弱 cipher），可能因握手延迟掩盖压缩收益，需单独排查 SSL 握手时间（可通过
$ssl_handshake_time变量，需 Nginx ≥ 1.19.2）； - 静态资源（CSS/JS/HTML）压缩效果明显，但图片、字体、视频等二进制文件默认不压缩，日志中这些请求的
$body_bytes_sent不应有变化，否则说明配置有误（如误加了image/*到gzip_types）。
结合客户端真实体验验证
日志是服务端视角，最终要落到用户侧：
- 用 Chrome DevTools 的 Network 面板抓取同一页面，对比开启 Gzip 前后 “Size” 列（Transfer Size）是否下降，且 “Waterfall” 中 content download 阶段是否缩短；
- 关注 TTFB（Time to First Byte）是否基本不变 —— Gzip 不影响首字节时间，只缩短后续传输；若 TTFB 显著降低，说明另有优化（如缓存命中），不能归功于 Gzip；
- 对移动端用户尤其重要：弱网下，传输量减少 60% 往往意味着加载完成时间减少 40% 以上，这在日志的
$request_time分布直方图中会体现为右尾明显收窄。
