WordPress Browser Caching and Compression

Browser caching stores reusable responses on the visitor's device.

Compression reduces the number of bytes transferred for text resources such as HTML, CSS, JavaScript and JSON.

These mechanisms complement full-page caching but solve different problems.

Cache-Control

HTTP cache headers can define:

Public versioned assets can use long lifetimes. Personalized HTML and sensitive responses need stricter policies.

WordPress enqueues styles and scripts with version parameters.

A changed URL or version lets the browser fetch a new file while retaining long caching for unchanged assets.

Do not remove every version parameter without a replacement cache-busting strategy.

Validators such as ETag or Last-Modified can let the browser confirm that a cached response has not changed.

A revalidation still requires a network request, but it can avoid transferring the full resource.

Brotli and gzip compress text-based responses.

Images, video and already compressed archives usually gain little from another text-compression layer.

Ensure the server or CDN sends the correct Content-Encoding and Vary headers.

Browser caching of HTML requires care.

Logged-in, account, cart and personalized responses should not be stored in shared caches unless the architecture explicitly supports it.

Inspect headers and transferred sizes in browser developer tools.

Test first visit, repeat visit, update deployment and cache purge behavior.

No. Browser caching stores responses on the visitor's device; page caching can store generated HTML on the server or edge.

They can use very long lifetimes when filenames or versions change whenever content changes.