Caching speeds up a website by reusing work. The browser can reuse files it already downloaded, and the server or CDN can reuse pages or responses it already built.
The hard part is choosing what can be reused, for how long, and how updates reach visitors when something changes.
Browser cache
Browser caching applies to files stored on the visitor’s device: CSS, JavaScript, images, fonts, icons, and sometimes other responses.
When cache headers are set well, a repeat visit does not download the same unchanged files again. In DevTools Network, those files may show as (from memory cache) or (from disk cache).
Static assets benefit the most:
- images
- fonts
- compiled CSS
- compiled JavaScript
- icons and logos
HTML is different because it changes more frequently and controls the current page. Cache it carefully unless your publishing system handles invalidation for you.
Versioned files make long cache times safer
Long-lived browser cache works best when filenames change after the file changes.
For example:
app.7f3a91.css
home-hero.2025-11.webpIf the filename includes a content hash or version, the browser can keep it for a long time. When the file changes, the URL changes too, so visitors receive the new version.
Without versioned filenames, long cache times can trap visitors on stale CSS or JavaScript.
Server cache
Server caching happens before the response reaches the visitor. Instead of rebuilding a page for every request, the server, framework, or CMS stores a ready response and serves it again.
This helps first-time visitors too. They do not have a browser cache yet, but they can still receive a page that the server already prepared.
Common server-side cache layers include:
- WordPress page cache plugins
- framework route caches
- database query caches
- CDN edge cache
- static site builds
The closer the cached response is to the visitor, the less work the origin server has to do.
CDN cache
A CDN can store files and pages at edge locations. Images, CSS, JavaScript, and static HTML are strong candidates. Dynamic account pages, carts, admin screens, and personalized responses need stricter rules.
Cache only what is safe to share. A public blog post can be cached broadly. A user’s account page should not be served from a public cache.
Check cache behavior in DevTools
Open DevTools Network and reload the page twice:
- With cache disabled, inspect the first-visit cost.
- With cache enabled, reload and compare which files transfer again.
Look at the Size column. Cached files show cache labels instead of full transfer sizes. Also inspect response headers for cache-control, etag, or last-modified.
If every static asset downloads again on the second load, browser caching is not doing enough.
Common caching mistakes
- Long cache headers on unversioned CSS or JavaScript.
- No long-term cache on hashed static files.
- CDN cache disabled for public pages that rarely change.
- Personalized pages cached as public.
- Cache cleared on every small content edit.
- Image URLs changing even when the file content is the same.
Caching should reduce repeated work without hiding updates from users. That balance comes from separating stable assets from frequently changing HTML and data.
The full slow-site loop
Caching is the final layer after diagnosis, image weight, JavaScript work, and loading order. It cannot make a 4 MB hero image a good idea, and it cannot stop a third-party script from blocking the main thread.
It can make unchanged work stay done. Once the page is light enough and ordered well, cache rules keep it from paying the same cost on every visit.
