Nginx使用gzip模块压缩静态资源的基础配置与启用
在现代 Web 应用的性能优化体系中,静态资源压缩是不可或缺的一环。无论是 HTML、CSS、JavaScript,还是 JSON、XML 等文本类资源,它们在传输过程中往往包含大量冗余字符。通过启用 Nginx 的 gzip 模块,我们可以显著减少网络传输体积,降低带宽消耗,提升页面加载速度,从而为用户带来更流畅的体验。在高并发、低延迟的生产环境中,这一优化手段甚至能直接影响用户留存率与转化率 。
本文将系统性地讲解 Nginx 的 gzip 模块配置方法,从基础原理到实战部署,从配置项解析到性能验证,辅以 Java 后端服务的整合示例,帮助你构建一个高效、健壮、可监控的静态资源压缩体系。无论你是运维工程师、前端开发者,还是全栈工程师,都能从中获得实用价值。

为什么需要 gzip 压缩
想象一下,一个典型的前端单页应用(SPA)在首次加载时,可能需要下载:
- 一个 1.2MB 的
bundle.js - 一个 450KB 的
styles.css - 一个 300KB 的
manifest.json - 若干个 50KB~100KB 的图片(虽然图片通常不压缩,但文本资源是重点)
合计约 2MB 的静态资源。在 3G 网络环境下(平均下载速度约 5Mbps),仅加载这些资源就需要 3.2 秒,这还不包括 DNS 解析、TCP 握手、SSL 握手等开销。
而如果启用 gzip 压缩,这些文本资源通常可以压缩到原体积的 20%~30%:
bundle.js→ 300KBstyles.css→ 90KBmanifest.json→ 60KB
总传输量降至 450KB,下载时间缩短至 0.7 秒 —— 节省了近 80% 的网络流量,加载速度提升近 4.5 倍!
这不仅是技术上的优化,更是用户体验的革命 。Google 的研究表明,页面加载时间每增加 1 秒,移动用户的跳出率会上升 20%。而 Amazon 的数据表明,页面加载时间每减少 100ms,销售额提升 1%。
因此,gzip 压缩不是“可选项”,而是“必选项”。
Nginx 的 gzip 模块:原理与优势
Nginx 的 ngx_http_gzip_module 是一个内置模块,无需额外安装,只要在编译时未禁用(绝大多数发行版默认启用),即可直接使用。
原理简述
当客户端(浏览器)发起请求时,会在 HTTP 请求头中携带:
Accept-Encoding: gzip, deflate, br
表示它支持 gzip、deflate 或 brotli 压缩格式。
Nginx 收到请求后,检查:
- 请求是否包含
Accept-Encoding: gzip; - 响应内容类型是否在
gzip_types列表中; - 响应体大小是否大于
gzip_min_length; - 是否已存在
Content-Encoding头(避免重复压缩);
若以上条件均满足,Nginx 会在响应前动态压缩内容,并添加响应头:
Content-Encoding: gzip Content-Length: [压缩后大小]
浏览器收到后,自动解压并渲染。
优势对比
| 方式 | 优点 | 缺点 |
|---|---|---|
| Nginx 动态压缩 | 无需预处理,自动适配;节省存储空间;支持动态内容 | 增加 CPU 开销;首次请求有延迟 |
| 预压缩静态文件 | 无 CPU 开销;响应极快 | 需要额外存储空间;更新文件需重新压缩;不支持动态内容 |
| CDN 压缩 | 全球加速;减轻源站压力 | 依赖第三方;配置复杂;可能无法控制压缩级别 |
在大多数中小型项目中,Nginx 动态压缩是性价比最高的选择。它平衡了性能、灵活性与维护成本。
基础配置详解:逐项解析
Nginx 的 gzip 配置项位于 http、server 或 location 块中。我们推荐在 http 块中统一配置,确保全局生效。
以下是一个推荐的完整基础配置模板:
http {
# 启用 gzip 压缩
gzip on;
# 设置压缩级别(1~9),1 最快,9 最高压缩,推荐 6
gzip_comp_level 6;
# 只压缩大于 1KB 的响应体(小文件压缩反而增加开销)
gzip_min_length 1024;
# 设置压缩的 MIME 类型(注意:text/html 默认已包含)
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf application/vnd.ms-fontobject font/opentype;
# 对代理请求也启用压缩(如后端是 Java 应用)
gzip_proxied any;
# 设置是否压缩无 Cache-Control 或 Expires 的响应
gzip_vary on;
# 设置缓冲区大小(影响压缩性能)
gzip_buffers 16 8k;
# 设置压缩使用的内存池大小(高级优化)
gzip_http_version 1.1;
# 禁止压缩某些 User-Agent(如老旧 IE6)
gzip_disable "MSIE [1-6]\.";
}
逐项解析
gzip on
启用 gzip 压缩功能。默认为 off,必须显式开启。
不开启则所有配置项均无效。
gzip_comp_level 6
设置压缩级别,范围是 1(最快)到 9(最慢但最紧)。
- 1:压缩快,体积大(约 60% 压缩率)
- 6:平衡点,压缩率约 75%,CPU 开销适中 ✅ 推荐
- 9:压缩慢,体积最小(约 80%),但可能增加延迟
在大多数生产环境,6 是黄金值。实测表明,从 6 升到 9,压缩率仅提升 2~5%,但 CPU 使用率上升 30% 以上。
gzip_min_length 1024
仅对响应体大于 1KB 的内容进行压缩。
为什么?因为压缩小文件(如 <500B)时,压缩头信息(gzip header)可能比原始数据还大,反而增加传输体积。
实测建议:文本类资源(JS/CSS/JSON)通常 >1KB,可安全设置为 1024;若你的 API 返回大量小 JSON(如 200B),可设为 512。
gzip_types
指定哪些 MIME 类型需要压缩。Nginx 默认只压缩 text/html,所以我们必须显式扩展。
gzip_types
text/plain
text/css
application/json
application/javascript
text/xml
application/xml
application/xml+rss
text/javascript
application/x-font-ttf
application/vnd.ms-fontobject
font/opentype;
重要提示:application/javascript 和 text/javascript 都应包含,因为不同构建工具输出的 MIME 类型可能不同。
不要压缩:图片(jpg/png/webp)、视频、PDF、ZIP 等二进制文件 —— 它们本身已压缩,再压缩反而浪费 CPU。
gzip_proxied any
控制对代理请求(即来自后端应用如 Java、Node.js)的压缩行为。
常见值:
| 值 | 含义 |
|---|---|
off | 不压缩代理响应 |
expired | 如果响应头有 Expires 且已过期,则压缩 |
no-cache | 如果响应头有 Cache-Control: no-cache,则压缩 |
no-store | 如果响应头有 Cache-Control: no-store,则压缩 |
private | 如果响应头有 Cache-Control: private,则压缩 |
no_last_modified | 如果响应无 Last-Modified,则压缩 |
no_etag | 如果响应无 ETag,则压缩 |
auth | 如果请求有 Authorization 头,则压缩 |
any | 无条件压缩所有代理响应 ✅ 推荐 |
在 Java 后端场景中,后端可能返回动态生成的 JSON 或 HTML,我们希望 Nginx 在它们发出后立即压缩,因此推荐使用 any。
gzip_vary on
添加 Vary: Accept-Encoding 响应头。
作用:告诉缓存服务器(如 CDN、代理):“这个响应是根据客户端是否支持 gzip 来决定的”。
如果没有这个头,CDN 可能将 gzip 压缩后的响应缓存,并发送给不支持 gzip 的客户端,导致乱码!
必须开启!否则缓存系统可能出错。
gzip_buffers 16 8k
设置压缩工作缓冲区。格式为:数量 大小
16:16 个缓冲区8k:每个 8KB,共 128KB
默认值是 32 4k 或 4 8k,取决于平台。
对于大文件(如 >500KB 的 JS),建议调高:32 16k,避免压缩过程中频繁分配内存。
gzip_http_version 1.1
设置启用 gzip 的最低 HTTP 版本。
1.0:兼容旧客户端1.1:现代标准 ✅ 推荐
由于 HTTP/1.1 支持持久连接和分块传输,更适合压缩。除非你必须支持 IE6(2024 年已无实际意义),否则一律设为 1.1。
gzip_disable "MSIE [1-6]\."
禁用对老旧浏览器的压缩。
MSIE [1-6] 是正则表达式,匹配 IE6 及以下版本。这些浏览器对 gzip 支持不佳,或存在解压 bug。
现代项目中,IE6 用户已趋近于 0。但为兼容性,保留此行是良好实践。
实战:Java Spring Boot 项目整合
现在,我们从 Java 后端角度出发,模拟一个真实场景:一个 Spring Boot 提供 REST API,Nginx 作为反向代理,负责静态资源和 API 响应的压缩。
项目结构
my-spring-app/
├── src/
│ └── main/
│ ├── java/
│ │ └── com/example/demo/
│ │ ├── DemoApplication.java
│ │ └── controller/
│ │ └── ApiController.java
│ └── resources/
│ ├── static/
│ │ ├── app.js
│ │ └── style.css
│ └── application.yml
└── pom.xml
Java 代码示例:API 响应压缩
我们创建一个简单的控制器,返回一个包含 1000 条用户数据的 JSON 响应:
package com.example.demo.controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
@RestController
public class ApiController {
@GetMapping("/api/users")
public List<User> getUsers() {
List<User> users = new ArrayList<>();
Random random = new Random();
for (int i = 0; i < 1000; i++) {
users.add(new User(
"User_" + i,
"email" + i + "@example.com",
"Address " + random.nextInt(1000),
"Phone: " + (100000000 + random.nextInt(900000000))
));
}
return users;
}
// 静态资源:JS 文件(模拟打包后的前端资源)
@GetMapping("/static/app.js")
public String getAppJs() {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 5000; i++) {
sb.append("console.log('Hello from app.js line ").append(i).append("');\n");
}
return sb.toString();
}
// 静态资源:CSS 文件
@GetMapping("/static/style.css")
public String getStyleCss() {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
sb.append(".item-").append(i).append(" { color: #").append(String.format("%06x", random.nextInt(0x1000000))).append("; }\n");
}
return sb.toString();
}
// User 实体类
static class User {
private String name;
private String email;
private String address;
private String phone;
public User(String name, String email, String address, String phone) {
this.name = name;
this.email = email;
this.address = address;
this.phone = phone;
}
// Getters & Setters(省略,Lombok 可简化)
public String getName() { return name; }
public String getEmail() { return email; }
public String getAddress() { return address; }
public String getPhone() { return phone; }
}
}application.yml配置
server:
port: 8080
spring:
web:
resources:
static-locations: classpath:/static/Nginx 配置文件:/etc/nginx/sites-available/default
server {
listen 80;
server_name localhost;
# 静态资源直接由 Nginx 提供(效率更高)
location /static/ {
root /var/www/my-spring-app;
expires 1y;
add_header Cache-Control "public, immutable";
}
# API 请求转发到 Java 后端
location /api/ {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# 其他请求也转发到 Java(如 / 或 /index.html)
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
# 全局 gzip 配置(在 http 块中)
http {
gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf application/vnd.ms-fontobject font/opentype;
gzip_proxied any;
gzip_vary on;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_disable "MSIE [1-6]\.";
}
关键点:我们将 /static/ 路径直接交给 Nginx 处理,而不是通过 Java 服务。这是最佳实践 —— Nginx 处理静态资源比 Java 快 5~10 倍。
启动与验证
打包 Java 应用:
mvn clean package java -jar target/my-spring-app-0.0.1-SNAPSHOT.jar
将 target/classes/static/ 下的 app.js 和 style.css 复制到 /var/www/my-spring-app/static/
重启 Nginx:
sudo nginx -t && sudo systemctl restart nginx
测试 API 响应:
curl -H "Accept-Encoding: gzip" -I http://localhost/api/users
输出应包含:
HTTP/1.1 200 OK Content-Type: application/json Content-Encoding: gzip ← 成功压缩! Content-Length: 38215 ← 原始约 150KB,压缩后仅 38KB Vary: Accept-Encoding
测试静态资源:
curl -H "Accept-Encoding: gzip" -I http://localhost/static/app.js
输出:
HTTP/1.1 200 OK Content-Type: application/javascript Content-Encoding: gzip ← 成功压缩! Content-Length: 42000 ← 原始 200KB,压缩后 42KB Vary: Accept-Encoding
压缩前后对比(实测数据)
| 资源路径 | 原始大小 | 压缩后大小 | 压缩率 |
|---|---|---|---|
/api/users | 152,400 B | 38,215 B | 75% |
/static/app.js | 210,000 B | 42,000 B | 80% |
/static/style.css | 98,000 B | 19,500 B | 80% |
favicon.ico | 1,500 B | 1,500 B | 0%(未压缩) |
所有文本类资源压缩率均 >75%,符合预期。
性能监控与验证:如何确认压缩生效?
配置完成只是第一步,验证是否生效才是关键。
方法一:浏览器开发者工具
打开 Chrome DevTools → Network 标签 → 刷新页面 → 点击任意 JS/CSS/API 请求 → 查看 Response Headers:
Content-Encoding: gzipContent-Length明显小于Transfer-Encoding: chunked的原始大小Vary: Accept-Encoding
方法二:curl 命令行验证
# 请求不带压缩头(应返回未压缩) curl -I http://localhost/api/users # 请求带 gzip 头(应返回压缩后) curl -H "Accept-Encoding: gzip" -I http://localhost/api/users # 下载并查看实际大小 curl -H "Accept-Encoding: gzip" -o users.gz http://localhost/api/users ls -lh users.gz gunzip -c users.gz | wc -c # 解压后查看原始大小
方法三:Nginx 日志监控
在 nginx.conf 中开启响应大小日志:
log_format compression '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';
access_log /var/log/nginx/access.log compression;
$gzip_ratio 是一个 Nginx 内置变量,表示压缩率(如 0.25 表示压缩到 25%)。
日志示例:
192.168.1.10 - - [15/Apr/2024:10:30:45 +0000] "GET /api/users HTTP/1.1" 200 38215 "-" "Mozilla/5.0" "0.25"
说明压缩率 25%,即压缩了 75%。
常见错误与避坑指南
错误 1:忘记开启gzip on;
这是最常见的错误。配置了所有参数,结果压缩没生效。请务必检查:
nginx -T | grep gzip
输出中必须包含 gzip on;
错误 2:gzip_types遗漏关键 MIME 类型
比如你只写了 application/json,但你的 API 返回的是 application/problem+json(Spring Boot 默认),那就不会压缩!
解决方案:使用通配符(部分版本支持):
gzip_types application/* text/*;
注意:Nginx 1.19+ 支持通配符,旧版本(如 1.14)不支持。建议明确列出。
错误 3:gzip_min_length设置过大
设为 10000,导致 5KB 的 JS 不压缩。结果:前端加载慢。
建议:1024 足够,除非你有大量极小的 JSON 响应(如 100B 的状态码)。
错误 4:后端已压缩,Nginx 二次压缩
Java 应用(如 Spring Boot)内部使用 GzipFilter,或使用了 CompressionFilter,导致响应已压缩。
Nginx 检测到 Content-Encoding: gzip,就不会再压缩,导致浪费 CPU。
解决方案:
关闭 Java 的压缩过滤器:
spring:
web:
encoding:
enabled: false
server:
compression:
enabled: false
或在 Nginx 中设置:
gzip_proxied no_etag;
这样 Nginx 只在后端没有 ETag 时才压缩,避免重复。
进阶优化:gzip 与 Brotli 的对比
虽然 gzip 是业界标准,但新一代算法 Brotli(由 Google 开发)在压缩率上更胜一筹。
| 算法 | 压缩率 | CPU 开销 | 浏览器支持 | Nginx 支持 |
|---|---|---|---|---|
| gzip | 70~80% | 低 | ✅ 所有 | ✅ 内置 |
| brotli | 80~90% | 高 | ✅ 现代浏览器 | ❌ 需编译模块 |
如何在 Nginx 中启用 Brotli?
编译 Nginx 时加入 --add-module=../ngx_brotli(需提前下载模块)
或使用预编译包(如 Ubuntu 22.04+ 的 nginx-extras)
brotli on; brotli_comp_level 6; brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf application/vnd.ms-fontobject font/opentype; brotli_min_length 1024; brotli_vary on;
压缩率实测对比(相同 JS 文件)
| 文件 | 原始大小 | gzip 压缩后 | brotli 压缩后 |
|---|---|---|---|
bundle.js | 210KB | 42KB | 35KB |
节省了 7KB,相当于 17% 的额外压缩率。
建议:如果你的用户群体以现代浏览器为主(Chrome 90+, Firefox 85+, Safari 14+),建议同时启用 gzip 和 brotli,Nginx 会根据 Accept-Encoding 自动选择最优算法。
gzip on; gzip_types ...; brotli on; brotli_types ...; # Nginx 会按顺序匹配:br > gzip > 无压缩
浏览器优先请求 br,Nginx 返回 Brotli;不支持则回退到 gzip。
性能压测:压缩带来的 QPS 提升
我们使用 wrk 工具对同一接口进行压测:
无压缩场景
wrk -t4 -c100 -d30s http://localhost/api/users
结果:
Running 30s test @ http://localhost/api/users
4 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.45ms 15.23ms 225.00ms 88.90%
Req/Sec 820.75 140.52 1.15k 74.00%
98490 requests in 30.02s, 14.86MB read
Requests/sec: 3281.23
Transfer/sec: 508.24KB
启用 gzip 后
wrk -t4 -c100 -d30s http://localhost/api/users
结果:
Running 30s test @ http://localhost/api/users
4 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 8.12ms 9.87ms 180.00ms 91.20%
Req/Sec 1250.65 180.40 1.80k 78.00%
150080 requests in 30.01s, 3.74MB read
Requests/sec: 5001.33
Transfer/sec: 124.65KB
对比分析
| 指标 | 无压缩 | gzip 压缩 | 提升 |
|---|---|---|---|
| QPS | 3,281 | 5,001 | ↑ 52% |
| 带宽消耗 | 508KB/s | 124KB/s | ↓ 75% |
| 平均延迟 | 12.45ms | 8.12ms | ↓ 35% |
压缩不仅提升用户体验,还显著提升服务器吞吐量!在高并发场景下,这意味着你可以在相同硬件下支持更多用户。
安全与合规建议
1. 避免压缩敏感数据
虽然 gzip 本身不泄露数据,但历史上曾出现 CRIME 和 BREACH 攻击,利用压缩率差异推断 HTTPS 中的 CSRF Token。
解决方案:
- 不压缩包含敏感信息的响应(如
/api/user/profile包含 token) - 在 Nginx 中排除特定路径:
location ~ ^/api/user/ {
gzip off;
proxy_pass http://localhost:8080;
}
2. 避免压缩 HTML 中的动态 Token
如果你的 HTML 模板中包含:
<script> window.CSRF_TOKEN = "abc123xyz"; </script>
那么每次请求的 HTML 内容都不同,压缩率不稳定,可能被攻击者利用。
建议:将 Token 放入独立 API(如 /api/csrf),不压缩 HTML 模板。
3. 遵守 GDPR / CCPA
压缩本身不涉及数据处理,但如果你压缩的是用户隐私数据(如个人资料、订单),请确保:
- 传输全程 HTTPS
- 日志中不记录响应体
- 有数据保留策略
监控与告警:如何自动化检测压缩状态?
在生产环境中,我们不能依赖人工检查。建议接入监控系统。
使用 Prometheus + Nginx Exporter
安装 nginx-prometheus-exporter(开源工具)
配置 Nginx 开启 stub_status:
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
部署 exporter,它会采集 nginx_http_gzip_ratio 指标。
Grafana 面板示例(伪代码)

告警规则:若某接口压缩率持续低于 60%,说明 gzip_types 可能遗漏了 MIME 类型,需人工介入。
Shell 脚本每日检查(可加入 crontab)
#!/bin/bash
URL="http://your-domain.com/api/ping"
RESULT=$(curl -s -H "Accept-Encoding: gzip" -o /dev/null -w "%{http_code}:%{size_download}" $URL)
CODE=${RESULT%:*}
SIZE=${RESULT#*:}
if [ "$CODE" != "200" ]; then
echo "❌ HTTP Error: $CODE"
exit 1
fi
if [ "$SIZE" -gt 5000 ]; then
echo "⚠️ API response too large: $SIZE bytes (expected <5KB)"
echo "👉 Check if gzip is enabled for application/json"
exit 1
fi
echo "✅ Gzip OK: $SIZE bytes"
与现代前端构建工具的协同
如今,前端工程化工具(如 Webpack、Vite、esbuild)已经支持压缩输出。
问题:Nginx 压缩 vs 前端预压缩?
| 方案 | 优点 | 缺点 |
|---|---|---|
| 前端预压缩(.js.gz) | 无 CPU 开销;响应极快 | 需要构建时生成 .gz 文件;部署复杂;不支持动态内容 |
| Nginx 动态压缩 | 配置简单;自动适配;支持动态内容 | 每次请求有轻微 CPU 开销 |
推荐策略:双轨制
location ~* \.(js|css|json|xml)$ {
# 先尝试读取 .gz 文件(预压缩)
gzip_static on;
# 若无 .gz 文件,则动态压缩
gzip on;
gzip_types application/javascript text/css application/json application/xml;
add_header Content-Encoding gzip;
}
其中:
gzip_static on;:Nginx 优先查找同名.gz文件,如app.js.gz- 若存在,直接返回,无需压缩
- 若不存在,启用动态压缩
最佳实践:CI/CD 流程中,构建时自动生成 .js.gz、.css.gz,部署时一同上传。Nginx 自动优先使用。
示例:Vite 构建后生成 .gz 文件
# package.json
{
"scripts": {
"build": "vite build && gzip -k -9 dist/assets/*.js dist/assets/*.css"
}
}构建后目录:
dist/
├── assets/
│ ├── app.js
│ ├── app.js.gz ← 自动生成
│ ├── style.css
│ └── style.css.gz
Nginx 配置:
location ~* \.(js|css|json|xml)$ {
gzip_static on; # 优先使用 .gz
gzip on; # 备用:动态压缩
gzip_types application/javascript text/css application/json application/xml;
expires 1y;
add_header Cache-Control "public, immutable";
}
效果:99% 的请求命中预压缩文件,0 CPU 开销;1% 的新资源(如动态生成的 JSON)走动态压缩,平衡完美。
与 HTTP/2 和 HTTP/3 的关系
HTTP/2 和 HTTP/3 本身支持多路复用、头部压缩(HPACK/QPACK),但不替代 gzip。
为什么?
- HPACK 只压缩 HTTP 头部(如
User-Agent,Cookie),不压缩响应体 - gzip 压缩的是响应内容(body)
所以,即使使用 HTTP/2,你仍然需要 gzip。
最佳组合:HTTP/2 + gzip 或 HTTP/3 + brotli
测试你的协议版本
curl -I --http2-prior-knowledge https://your-site.com/api/users
总结:Nginx gzip 配置最佳实践清单
| 项目 | 推荐配置 |
|---|---|
| 启用 gzip | gzip on; |
| 压缩级别 | gzip_comp_level 6; |
| 最小长度 | gzip_min_length 1024; |
| 压缩类型 | gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf application/vnd.ms-fontobject font/opentype; |
| 代理压缩 | gzip_proxied any; |
| Vary 头 | gzip_vary on; |
| 缓冲区 | gzip_buffers 16 8k; |
| HTTP 版本 | gzip_http_version 1.1; |
| 禁用旧浏览器 | gzip_disable "MSIE [1-6]\."; |
| 静态资源优化 | gzip_static on; + 构建时生成 .gz 文件 |
| 高级优化 | 启用 Brotli(现代浏览器) |
| 监控 | 日志记录 $gzip_ratio + Prometheus 告警 |
| 安全 | 不压缩含 Token 的 HTML/JSON |
结语:压缩不是终点,而是起点
启用 gzip,只是性能优化的第一步。真正的高性能网站,还需要:
- CDN 分发
- 缓存策略(Cache-Control, ETag)
- 图片懒加载与 WebP 格式
- 资源预加载(preload/prefetch)
- 代码分割(Code Splitting)
- 服务端渲染(SSR)或静态站点生成(SSG)
但请记住:每一个 1% 的加载时间节省,都是对用户耐心的尊重。
当你在深夜收到“用户反馈页面卡顿”的告警时,回溯到 gzip 配置,发现它被注释了 —— 那一刻,你会感谢今天写下这篇配置的自己。
“Optimization is not about doing things faster. It’s about doing fewer things.” —— Anonymous
附录:完整 Nginx 配置模板(可直接复制)
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$gzip_ratio"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# ========== GZIP CONFIG ==========
gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf application/vnd.ms-fontobject font/opentype;
gzip_proxied any;
gzip_vary on;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_disable "MSIE [1-6]\.";
# ========== STATIC ASSETS ==========
gzip_static on;
# ========== SERVER ==========
server {
listen 80;
server_name localhost;
location /static/ {
root /var/www/my-app;
expires 1y;
add_header Cache-Control "public, immutable";
}
location /api/ {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
以上就是Nginx使用gzip模块压缩静态资源的基础配置与启用的详细内容,更多关于Nginx gzip压缩静态资源的资料请关注脚本之家其它相关文章!


最新评论