From harness-claude
Configures Brotli, gzip, Zstandard compression for web assets like HTML/CSS/JS and APIs; covers pre-compression, dynamic setup, algorithm selection, and header negotiation to cut transfer sizes.
npx claudepluginhub intense-visions/harness-engineering --plugin harness-claudeThis skill uses the workspace's default tool permissions.
> Master content compression for web delivery — Brotli, gzip, and Zstandard algorithms, compression level selection, content-encoding negotiation, static pre-compression vs dynamic compression, and format-specific optimization strategies.
Optimizes web images using compression for JPEG/PNG/WebP/SVG, modern formats, and responsive techniques to reduce file size and improve loading speed.
Guides modern image format selection (WebP, AVIF, JPEG XL), quality-to-size trade-offs, picture element negotiation, and build pipeline automation for image-heavy pages with slow LCP.
Compresses JPG/PNG/GIF images to WebP using cwebp, iteratively reducing quality/resolution until under 100KB, preserves originals, reports sizes, updates file references. Use for web/SEO performance.
Share bugs, ideas, or general feedback.
Master content compression for web delivery — Brotli, gzip, and Zstandard algorithms, compression level selection, content-encoding negotiation, static pre-compression vs dynamic compression, and format-specific optimization strategies.
Verify compression is active. In Chrome DevTools Network panel, check the "Content-Encoding" response header for br (Brotli), gzip, or zstd. Compare "Size" column (transfer size) vs "Size" column tooltip (uncompressed size). If they are equal, compression is not active.
# Check compression with curl
curl -H "Accept-Encoding: br, gzip" -I https://example.com/app.js
# Look for: Content-Encoding: br
Choose the right algorithm. Decision matrix:
| Algorithm | Compression Ratio | Compression Speed | Decompression Speed | Browser Support |
|---|---|---|---|---|
| gzip (deflate) | Baseline | Fast (levels 1-4) | Very fast | 100% |
| Brotli | 15-26% better than gzip | Slow at high levels | Very fast | 97% |
| Zstandard | 10-20% better than gzip | Very fast | Very fast | ~70% (emerging) |
Default recommendation: Brotli for static assets (pre-compressed at build time), Brotli level 4-6 for dynamic responses, gzip as fallback.
Configure static pre-compression. For build artifacts (JS, CSS, HTML), compress at build time at maximum quality:
# Brotli pre-compression (level 11 — slow but maximum compression)
brotli -q 11 dist/app.js # creates dist/app.js.br
brotli -q 11 dist/style.css # creates dist/style.css.br
# gzip pre-compression (level 9 — maximum for gzip)
gzip -k -9 dist/app.js # creates dist/app.js.gz
Configure the server to serve pre-compressed files when available:
# Nginx: serve pre-compressed files
gzip_static on;
brotli_static on;
Configure dynamic compression for generated responses. For API responses, HTML templates, and other dynamic content, use moderate compression levels:
# Nginx dynamic Brotli configuration
brotli on;
brotli_comp_level 4; # Good balance of compression and CPU
brotli_types text/html text/plain text/css application/json
application/javascript text/xml application/xml
image/svg+xml;
# Nginx dynamic gzip configuration (fallback)
gzip on;
gzip_comp_level 6;
gzip_types text/html text/plain text/css application/json
application/javascript text/xml application/xml
image/svg+xml;
gzip_min_length 1000; # Don't compress tiny responses
Set correct response headers. Ensure Content-Encoding and Vary headers are correct:
Content-Encoding: br
Vary: Accept-Encoding
The Vary: Accept-Encoding header tells caches to store separate versions for different encodings. Without it, a CDN might serve a Brotli-compressed response to a client that only supports gzip.
Know what NOT to compress. Skip compression for:
Measure compression effectiveness. Compare transfer sizes before and after:
// Measure compression ratio for each resource
const resources = performance.getEntriesByType('resource');
resources.forEach((r) => {
if (r.transferSize > 0 && r.decodedBodySize > 0) {
const ratio = (1 - r.transferSize / r.decodedBodySize) * 100;
console.log(`${r.name}: ${ratio.toFixed(1)}% compressed`);
}
});
Brotli levels 0-11 offer a wide range of speed/ratio tradeoffs:
For gzip: level 6 is the standard default. Level 9 adds ~5% compression for ~50% more CPU. Level 1 is useful for real-time compression of large streaming responses.
Brotli includes a built-in static dictionary of common web content fragments (HTML tags, CSS properties, JavaScript keywords). This gives Brotli a significant advantage over gzip for small web resources. A 10KB JavaScript file might compress 20% better with Brotli than gzip specifically because common patterns like function, return, document.getElementById are in the dictionary.
LinkedIn reduced transfer sizes by 20% across their static assets by switching from gzip-6 (their previous standard) to a dual strategy: Brotli-11 for build-time pre-compressed static assets and Brotli-5 for dynamic API responses. The static assets (JS bundles, CSS) saw the largest gains — a 450KB (uncompressed) JavaScript bundle went from 120KB with gzip-6 to 95KB with Brotli-11. The migration required: adding Brotli pre-compression to the build pipeline, configuring Nginx brotli_static module, and ensuring the CDN correctly varied on Accept-Encoding.
Cloudflare published benchmarks showing that Brotli level 4 outperforms gzip level 9 in both compression ratio (4.5% better) and compression speed (15% faster) for typical web content (HTML, CSS, JS). For their CDN, they use Brotli-4 as the default dynamic compression level, which compresses a typical 100KB HTML page in 2ms (vs 3ms for gzip-9) while achieving a 25:1 compression ratio (vs 22:1 for gzip-9). They estimate this saves 15-20% bandwidth globally across their network.
Compressing already-compressed formats. JPEG, PNG, WebP, MP4, WOFF2, and ZIP files are already compressed. Attempting to compress them adds CPU cost with near-zero (<1%) size reduction, and may even increase size due to compression metadata overhead.
Using Brotli level 11 for dynamic responses. Brotli-11 takes approximately 100x longer than Brotli-4 to compress the same content. For a dynamic API response, this adds 50-200ms of CPU time per request. Use Brotli-11 only for static pre-compression at build time.
Not setting Vary: Accept-Encoding. Without this header, a CDN or proxy may cache the Brotli-compressed version and serve it to a client that only supports gzip (causing a decode error) or cache the uncompressed version and serve it to a client that supports Brotli (wasting bandwidth).
Compressing responses under 1KB. The overhead of compression framing (gzip header: ~20 bytes, Brotli header: ~10 bytes) combined with the minimum block size means very small responses may not shrink or may even grow after compression. Set a minimum size threshold (1KB recommended).