Caching & Compression: Zero Re-Downloads
A returning visitor should never re-download your logo, fonts, or CSS. A first-time visitor should receive your HTML already compressed to 30% of its original size. These two mechanisms — caching and compression — directly move your Core Web Vitals scores.
Brotli Compression: The 2026 Standard
Uncompressed
100%
baseline payload
Gzip
~35%
of original size
Brotli
~25%
of original size
Brotli is enabled server-side and negotiated via the HTTP Accept-Encoding: br request header. Nginx, Apache, Cloudflare, and all major CDNs support Brotli natively. In Next.js on Vercel, Brotli is enabled by default.
Cache-Control Headers: The Right Directive Per Asset
Static Assets (JS, CSS, Images with hash)
Cache-Control: public, max-age=31536000, immutableCache for 1 year. Immutable prevents revalidation. Safe because content-hashed filenames change on update.
HTML Documents
Cache-Control: no-cacheForces revalidation on every visit. Browser checks if content changed via ETag — serves from cache if unchanged (304).
API JSON Responses
Cache-Control: private, no-storeSensitive, user-specific data must never be cached by a shared CDN. Private and no-store prevent all caching.
Murkuz AI SEO Scorecard Criteria
Brotli Implementation
Server compresses all HTML, CSS, and JS responses using Brotli (br encoding), with Gzip as fallback for unsupported clients.
Long-Lived Cache Headers
All fingerprinted static assets served with Cache-Control: public, max-age=31536000, immutable.
ETag Validation
HTML documents use ETag headers for conditional GET revalidation — enabling 304 responses for unchanged content.
Frequently Asked Questions
What is the difference between Gzip and Brotli compression?
Both are server-side text compression algorithms that reduce the file size of HTML, CSS, and JavaScript before transmitting them over HTTP. Brotli (developed by Google) consistently achieves 15-25% better compression ratios than Gzip for web assets, while maintaining comparable decompression speed in modern browsers. All major browsers support Brotli via the 'Accept-Encoding: br' request header. Gzip is a safe fallback for very old clients, but in 2026 serving Brotli should be your default.
What Cache-Control header should I set for static assets?
For static assets with content-based fingerprinted filenames (e.g., app.a4f2b1.js — where the hash changes when content changes), the optimal Cache-Control header is: Cache-Control: public, max-age=31536000, immutable. This tells browsers and CDNs to cache the file for one year and never revalidate it. The 'immutable' directive explicitly prevents conditional GET requests during the cache period. For HTML documents and API responses that must reflect live content, use: Cache-Control: no-cache (which still validates with the server but serves from cache if unchanged).
What is 'cache busting' and how is it implemented?
Cache busting is the practice of changing a static asset's URL when its content changes, forcing clients and CDNs to request the new version instead of serving the stale cached copy. The standard implementation is content-based hashing: your build tool (Webpack, Vite, Next.js) automatically appends a hash of the file's content to the filename (e.g., styles.3f8a2d.css). When you update the CSS, the new hash produces a new filename → a new cache hit miss → the browser downloads the new file.
Does a CDN improve SEO?
Yes, significantly. A CDN (Content Delivery Network) serves your static assets from the edge node geographically closest to each user, dramatically reducing Time to First Byte (TTFB) and overall page load time. Since TTFB and Core Web Vitals (LCP in particular) are confirmed ranking signals, a CDN that reduces your TTFB from 800ms to 80ms directly improves your LCP metric. CDNs also provide automatic DDoS protection, HTTP/3 support, and Brotli compression out of the box.
Written by Junaid Khalid