真正该测的是不同brotli_quality下端到端TTFB、完整加载时间、CPU开销与压缩率的平衡点，而非单纯网络吞吐量；需直连后端、禁用CDN、固定资源样本，并通过curl定量验证与Chrome真实用户侧测试结合分析。
直接测“不同压缩等级的网络吞吐量”容易误导——吞吐量不是由压缩级别单独决定的，而是响应生成速度、传输带宽、客户端解压能力三者共同作用的结果。真正该测的是：在不同 brotli_quality 下，端到端首字节时间（TTFB）、完整加载时间、CPU 开销与压缩率的平衡点。以下是可落地的测试路径。
测试前必须确保环境真实可控
-
禁用 CDN 和中间代理：它们可能缓存或覆盖
Content-Encoding，导致你测的不是 Nginx 真实行为。直连后端 IP 或用curl --resolve绕过 DNS。 -
关闭动态压缩干扰：Nginx 配置中设
brotli_static off; brotli on;，确保每次请求都走实时编码；或反向：brotli_static on; brotli off;，只测预压缩文件（更贴近线上推荐方式）。 -
固定资源样本：选 3 类典型文件——
main.js（280KB）、app.css（95KB）、index.html（14KB），全部用brotli -q N -k预生成.br文件，避免构建过程引入噪声。
分级对比测试方法（命令行+脚本）
用 curl + time + zstd/brotli 工具链做轻量级定量验证：
# 1. 先确认服务端返回的是 br 编码且头部正确
curl -H "Accept-Encoding: br" -I https://localhost:8443/main.js | grep -E "Content-Encoding:|Vary:|Content-Length:"
# 2. 测不同 quality 下的压缩率和编码耗时（本地预压缩阶段）
for q in 3 4 5 6 7; do
echo "quality $q:"
brotli -q $q -k main.js
ls -lh main.js.br | awk '{print $5}'
# 输出如：quality 4: 72.1K，quality 6: 68.3K → 压缩率提升但边际递减
done
# 3. 测端到端延迟（10 次取平均，排除瞬时抖动）
for q in 4 5 6; do
echo "=== brotli quality $q ==="
for i in {1..10}; do
curl -s -w "%{time_starttransfer}\n" \
-H "Accept-Encoding: br" \
-o /dev/null \
https://localhost:8443/main.js
done | awk '{sum += $1} END {printf "avg TTFB: %.3fs\n", sum/NR}'
done关键指标怎么看
-
TTFB（首字节时间）上升 >15ms：说明
-q 6以上已开始拖慢响应，尤其在高并发下会明显堆积。 -
.br文件体积减少 <3% 但编码时间翻倍：比如q=5→6体积从 69.1K → 68.3K（↓1.2%），但time brotli -q5是 120ms，-q6升至 280ms → 不值得。 -
Content-Length与原始大小比值稳定在 0.22–0.28：说明文本类资源压缩已充分（HTML/CSS/JS 的典型压缩率区间），再提级收益极低。
真实用户侧验证不能只靠 curl
- 用 Chrome DevTools 的 Network → Disable cache + Throttling（Slow 3G），分别访问
/main.js?br-q4/main.js?br-q6（通过 query 控制后端路由到不同 quality 的静态文件），记录：-
Transfer Size（实际下载字节数） -
Finish时间（含解压） - 在 Performance 标签页看
Decode阶段是否出现长任务（说明客户端解压压力大）
-
- 对比发现：
q=4和q=6在弱网下Transfer Size差 5–8KB，但Finish时间反而更短——因为小文件解压快，整体体验更好。
不复杂但容易忽略。
