Browser caching allows visitors’ browsers to store copies of static files locally so they do not need to download the same files every time they visit a page.

This document explains how browser caching works on Pressidium Managed WordPress Hosting, how browser cache duration affects your site’s content, and how to verify browser caching behavior.

What browser caching does

When a visitor loads your website, their browser downloads resources such as images, CSS files, JavaScript files, and fonts.

Browser caching allows the browser to keep eligible files locally for a defined period. On subsequent page views, the browser may reuse those files instead of requesting them again.

This can:

  • Reduce the amount of data transferred between the visitor and your site.
  • Reduce repeated requests for unchanged resources.
  • Improve page load times for returning visitors.

Browser caching is controlled by HTTP response headers sent with a resource, primarily Cache-Control and, where applicable, Expires.

Browser caching and EDGE caching

Browser caching and EDGE caching operate at different layers.

EDGE caching stores eligible content on Pressidium’s global Edge infrastructure. When a cached resource is requested, EDGE can serve it without requiring the request to reach the origin.

Browser caching stores eligible content on the visitor’s device. The browser can then reuse the local copy without downloading the resource again while that copy remains valid.

A resource may therefore be cached at both layers:

Origin → EDGE cache → Visitor’s browser cache

These caches are managed independently. Purging content from EDGE does not remove copies that have already been stored in visitors’ browsers.

When to change browser caching settings

Longer browser cache durations can improve performance for resources that rarely change, but they can also cause visitors to continue seeing an older version of a file after you update it.

Consider browser cache duration when:

  • Static assets are updated frequently.
  • You are changing CSS, JavaScript, images, or other front-end resources.
  • Visitors continue seeing an older version of a resource after a deployment.
  • You are optimizing repeat-visit performance.

For files that change frequently, use shorter cache durations or properly versioned asset URLs so browsers can request a new version when the file changes.

The appropriate cache duration depends on how often a resource changes and whether its URL changes when the resource is updated.

Content typeRecommended behavior
ImagesLonger cache duration when files rarely change
CSS and JavaScriptLonger duration when asset URLs are properly versioned
FontsLonger cache duration when files rarely change
Static downloadsMedium to long duration depending on how often files change
HTML pagesAvoid unnecessarily long browser caching
Admin, login, cart, checkout, and account pagesAvoid long browser caching

For static assets, changing the asset URL when the file changes is generally safer than relying on visitors to manually clear their browser cache.

What happens when browser cache duration changes

Changes to browser caching affect new responses sent to visitors.

Files that a visitor’s browser has already cached may remain stored until their existing cache duration expires. Changing the cache duration does not automatically remove an existing copy from the visitor’s device.

For this reason, a visitor may temporarily continue seeing an older version of a resource even after the browser caching configuration has changed.

Using versioned asset URLs helps avoid this problem because the browser treats the updated URL as a new resource.

Verify browser caching

You can use your browser’s developer tools to inspect the caching headers returned for a resource.

To verify browser caching:

  1. Open your website in a browser.
  2. Open the browser’s Developer Tools.
  3. Select the Network tab.
  4. Reload the page.
  5. Select the image, CSS, JavaScript, font, or other resource you want to inspect.
  6. Review the response headers.

Look for headers such as:

  • Cache-Control
  • Expires

These headers indicate the browser caching instructions sent with the resource.

You can also test the page in a private or incognito window to reduce interference from files previously cached during normal browsing. However, use the response headers to determine the caching instructions actually being sent.

Common issues

Visitors still see an old CSS or JavaScript file

First, inspect the resource and confirm which version is being returned.

If EDGE is serving an older version of the resource, purge the relevant EDGE cache and test again.

If the current resource is being returned by EDGE but the browser continues using an older local copy, test in a private window or clear the browser cache.

For future updates, use properly versioned asset URLs so the URL changes when the asset changes.

An old image still appears

Check whether the image URL has changed.

If a new image is published under the same URL, an existing browser-cached copy may continue to be used until it expires.

Where practical, use a new or versioned URL when replacing an image that may already be cached by visitors.

A page is not updating

Do not assume browser caching is the cause.

Check the response and caching behavior to determine whether the stale content is coming from:

  • The visitor’s browser cache.
  • EDGE caching.
  • WordPress or another application-level cache.
  • The origin itself.

Clear or purge only the cache layer responsible for the stale content.

Dynamic or user-specific content appears incorrect

Dynamic and user-specific content should not be cached in a way that causes one visitor to receive inappropriate or stale content.

If you encounter unexpected behavior on pages such as login, account, cart, or checkout pages, verify the response headers and caching behavior before changing browser cache settings.

If the issue persists, contact Pressidium Support.

Browser caching does not appear to be active

Inspect the resource’s response headers first.

Check whether Cache-Control or Expires provides browser caching instructions and confirm that you are testing a cacheable resource such as an image, stylesheet, JavaScript file, or font.

If the expected headers are not present, contact Pressidium Support with the affected URL and the headers you observed.

Best practices

  • Use longer browser cache durations for static resources that rarely change.
  • Use properly versioned URLs for CSS, JavaScript, and other assets that may change.
  • Avoid unnecessarily long browser caching for dynamic or user-specific content.
  • Inspect response headers instead of relying only on what appears in the browser.
  • Distinguish between browser, EDGE, application, and origin caching before purging or changing cache settings.

Need help?

If browser caching is not behaving as expected, contact Pressidium Support.

Include:

  • The affected website and URL.
  • The resource that appears to be cached incorrectly.
  • The behavior you expected.
  • The behavior you observed.
  • Relevant response headers, if available.

This information can help Support identify which caching layer is responsible.

Where to go next