WordPress And Browser Cache Headers: What Affects Them

Browser caching stores resources locally so repeat visits don't re-download them. The headers that control browser caching are set by the server; in WordPress, they come from a combination of the server configuration, caching plugins, and WordPress core behavior.

Understanding what controls the headers helps diagnose caching issues and improves repeat-visit performance.

The headers that matter

Cache-Control: the primary header controlling browser cache behavior. Specifies maximum age, whether the response is private or public, whether it can be cached at all.

Expires: an older header specifying an absolute expiration time. Cache-Control supersedes it but some setups still use both.

ETag: a unique identifier for the resource. The browser sends this back; if unchanged, the server returns 304 Not Modified.

Last-Modified: when the resource last changed. The browser uses this similarly to ETag for conditional requests.

The right cache durations

For different resource types, different cache durations are appropriate:

CSS and JavaScript files: long cache (1 year) with versioning in the filename. The browser caches aggressively; new versions get new URLs.

Images: long cache (1 year) for content images that don't change. Shorter for dynamic images.

HTML pages: short cache (5 minutes to 1 hour) since content changes frequently. Or no cache, depending on the site's update pattern.

Fonts: long cache (1 year) since fonts rarely change.

The pattern: static resources cache long; dynamic resources cache short.

The cache-busting through filenames

Long browser cache requires a way to update when resources change. The pattern: include a version or hash in the filename.

style.css?v=1.2.3 changes when v changes, forcing browsers to fetch the new version.

style-7f3a92.css uses content hash; new content produces new filename.

The cache plugin or build process handles the versioning. The pattern lets browsers cache aggressively while still seeing updates.

The CDN cache vs browser cache distinction

CDN cache and browser cache are different layers:

CDN cache stores resources at edge locations. Reduces origin load and serves users from nearby.

Browser cache stores resources on the user's device. Eliminates network requests entirely for cached resources.

Both are valuable. Browser cache produces the fastest repeat-visit experience because no network request happens at all.

The static asset versioning

WordPress versions static assets automatically. The CSS link includes ?ver=X.Y.Z based on the theme or plugin version. When versions change, the URL changes and the browser fetches the new version.

The versioning works for theme and plugin assets. Custom assets need versioning configured manually.

The pattern: every static asset has a version. Updates change the version. Browsers cache aggressively without staleness.

The HTML caching consideration

HTML pages typically shouldn't have long browser cache. The content changes when posts are added, updated, or deleted; cached HTML serves stale content.

Short browser cache for HTML (5 minutes) provides some benefit for users who navigate between pages quickly. Longer cache produces staleness.

The page cache (server-side) is what makes HTML serving fast; browser cache for HTML is a smaller optimization.

The honest framing

Browser cache headers are a real but quiet optimization. Sites with proper configuration get faster repeat-visit experience. Sites without configuration miss the opportunity.

Quality caching plugins handle the headers automatically. The benefit is captured without significant manual work.

For sites without quality caching plugins, the headers may not be set well. Server configuration (.htaccess rules for Apache, equivalent for other servers) can set the headers manually.

The investment is moderate; the benefit is real for sites with repeat visitors.