为什么引入的CSS文件体积过大_开启Gzip或Brotli压缩进行传输-css教程-PHP中文网

css 文件需通过 brotli 压缩至原始体积的 30%–40%，关键验证是 response headers 中存在 content-encoding: br；nginx 必须配置 brotli_static always、brotli_types 显式包含 text/css，并添加 vary: accept-encoding 响应头，同时构建时预生成 .br 文件，cdn 与源站不可重复压缩。

为什么引入的css文件体积过大_开启gzip或brotli压缩进行传输

直接开压缩，CSS 文件体积通常能压到原始的 30%–40%，但前提是链路每环都对得上——浏览器要发 Accept-Encoding: br 或 gzip，服务器得真返回 Content-Encoding: br 或 gzip，中间 CDN 不能缓存错版本。

怎么确认 CSS 真被 Brotli 压缩了

别信“我配了 brotli on”这种说法。打开 DevTools → Network → 刷新页面 → 找到任意 .css 请求 → 点开看 Response Headers。关键就一条：Content-Encoding: br 必须存在。没有？说明没走 Brotli。

常见断点：

Nginx 配了 brotli on，但漏了 brotli_static always，导致它无视已存在的 style.css.br，仍返回未压缩的 style.css
CDN（如 Cloudflare）支持 Brotli，但源站响应头没带 Vary: Accept-Encoding，结果缓存把 br 和 gzip 版本混成一个，Chrome 用户拿到的是 gzip 版本
brotli_types 没显式写 text/css，Nginx 默认不压缩 CSS

Nginx 启用 Brotli 的最小可靠配置

以下配置经实测可稳定投递 .br 文件，无需动态压缩开销：

http {
  brotli on;
  brotli_comp_level 7;
  brotli_types text/css application/javascript image/svg+xml;
  brotli_static always;
  add_header Vary "Accept-Encoding" always;
}

注意三点：

brotli_static always 是关键：它会直接读取同名 .br 文件（比如请求 main.css，就返回 main.css.br），比 on 更确定、更省 CPU
brotli_comp_level 7 是性价比拐点；设成 11 对 CSS 提升不到 2%，但 CPU 占用翻倍，高并发下容易拖垮静态服务
add_header Vary "Accept-Encoding" always 必须加，否则 CDN 缓存会污染，同一 URL 可能给 Chrome 返回 gzip，给 Safari 返回 br

Webpack 构建阶段必须预生成 .br 文件

运行时压缩（比如 compression-webpack-plugin 配 algorithm: 'brotliCompress'）只在 webpack-dev-server 生效，上线后完全不起作用。生产环境靠的是 Nginx 或 CDN 直接投递 .br 文件。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

构建脚本建议这样写：

brotli -q 11 -f -o dist/main.css.br dist/main.css

参数含义：

-q 11：对 CSS 这类文本资源值得拉满，Brotli 在高等级下压缩率明显优于 gzip
-f：强制覆盖已有 .br 文件，避免构建失败时残留旧版
确保 CI/CD 流程里这步执行成功，且 .br 文件和原 CSS 一起上传到 CDN 或部署目录

gzip 和 brotli 共存时谁生效

如果客户端请求头同时带 Accept-Encoding: br,gzip（现代 Chrome/Firefox 默认行为），Nginx 会优先返回 Brotli —— 但前提是它真能找到 .br 文件并配置了 brotli_static always。否则 fallback 到 gzip。

兼容性提醒：