GZipMiddleware
TheGZipMiddleware handles GZip compression for responses when the client supports it (indicated by an Accept-Encoding header that includes “gzip”).
Usage
Parameters
int
default:"500"
The minimum response size in bytes before compression is applied. Responses smaller than this value will not be compressed. Default is 500 bytes.
int
default:"9"
The GZip compression level, ranging from 0 to 9. Higher values provide better compression but use more CPU. Default is 9 (maximum compression).
0: No compression1: Fastest compression, least CPU usage9: Best compression, most CPU usage
How It Works
The middleware automatically:- Checks if the client supports GZip compression via the
Accept-Encodingheader - Compresses the response body if it exceeds the
minimum_sizethreshold - Sets the
Content-Encoding: gzipheader on compressed responses - Removes the
Content-Lengthheader (as the compressed size differs)
Example with Custom Configuration
Performance Considerations
- Minimum Size: Set
minimum_sizeappropriately to avoid compressing small responses where compression overhead exceeds benefits - Compression Level: Balance between compression ratio and CPU usage:
- Use lower values (4-6) for CPU-constrained environments
- Use higher values (7-9) when bandwidth is more expensive than CPU
- Content Types: GZip works best with text-based content (JSON, HTML, CSS, JavaScript)
- Pre-compressed Assets: Consider pre-compressing static assets rather than compressing on every request
When to Use
GZipMiddleware is beneficial when:- Serving large JSON responses or text-based data
- Bandwidth is limited or expensive
- Clients primarily access your API over slower networks
- Response sizes regularly exceed 1KB
When to Avoid
- Binary data (images, videos) that are already compressed
- Very small responses (< 500 bytes) where compression adds overhead
- CPU resources are constrained
- You’re already using compression at the reverse proxy/CDN level