brotli是否生效需验证三点：响应头含accept-encoding: br和content-encoding: br、资源体积显著缩小（比gzip小15–20%）、首屏指标如fcp/lcp提升；否则检查配置、压缩等级或启用预压缩。
直接测现代浏览器里的 Brotli 表现，关键不是“有没有 br”，而是“压缩是否真生效、解压是否不卡顿、传输是否真变快”。重点看三件事：响应头对不对、资源体缩没缩、页面加载顺不顺畅。
确认浏览器真实发了 br 请求并收到 br 响应
现代浏览器（Chrome 49+、Firefox 44+、Edge 11+、Safari 11+）默认在 HTTPS 下自动带 Accept-Encoding: br。但中间环节可能把它干掉：
- 用 Chrome DevTools 的 Network 面板刷新页面，点任意 JS/CSS 文件 → 查看 Headers → Request Headers 里必须有
Accept-Encoding: br, gzip或类似（br 在前更稳妥） - Response Headers 中必须出现
Content-Encoding: br，且状态码是 200 - 同时检查
Vary: Accept-Encoding是否存在，缺这个会导致 CDN 缓存错乱，后续非 br 请求拿到 br 内容而解析失败
验证压缩效果是否落在实际字节上
光有头不够，得看下载体积真变小了：
- 在 Network 面板里对比同一资源在「无网络限速」和「Slow 3G」下的 Transfer Size
- Brotli 压缩后体积应比未压缩小 30% 以上，比 Gzip 小 15–20%（比如原 JS 400 KB → Brotli 后约 110 KB，Gzip 后约 135 KB）
- 若发现 Transfer Size 和未压缩差不多，大概率是
brotli_ratio == 1：检查是否漏配brotli_types application/javascript，或brotli_min_length设得太低（建议 ≥1024），或响应体本身太小（如空 JSON）
观察首屏关键指标是否受益
Brotli 的价值最终体现在用户感知上：
- 打开 Performance 面板，记录一次完整页面加载，重点关注 FCP（First Contentful Paint）和 LCP（Largest Contentful Paint）时间
- 若开启 Brotli 后 TTFB（Time to First Byte）明显升高（>100ms），说明动态压缩拖慢了首字节——这时应调低
brotli_comp_level（6 是平衡点，别用 9 或 11），或改用brotli_static always预生成.br文件 - 对 JS 资源，可在控制台运行
performance.getEntriesByType('resource').filter(r => r.name.includes('.js') && r.encodedBodySize ，确认 <code>encodedBodySize确实远小于decodedBodySize
不复杂但容易忽略。
