What Is HTTP Caching?
HTTP caching is the mechanism that lets browsers and servers store copies of web files so they don't have to be downloaded again on every visit. Using HTTP response headers like Cache-Control and ETag, a server tells the browser how long it may reuse a file, such as an image, stylesheet, or script, before checking for a newer version. When done well, repeat visits load almost instantly because the browser serves assets from local storage instead of re-fetching them across the network, cutting bandwidth, server load, and page-load time.
- What it is
- Storing reusable copies of web responses to avoid re-downloading them
- Key header
- Cache-Control sets how long and where a response may be cached (MDN)
- Validation
- ETag and Last-Modified let a browser check if its copy is still fresh (MDN)
- Two cache layers
- Browser (private) cache and shared caches like CDNs or proxies
- Speed impact
- Improves repeat-visit LCP and reduces server requests (web.dev)
What HTTP caching covers #
HTTP caching is the set of rules that decide when a stored copy of a web response can be reused instead of downloaded again. Every file your site sends, an image, a font, a CSS bundle, a JavaScript file, even an HTML page, can be cached according to instructions the server attaches as HTTP headers. There are two main places caching happens: the private browser cache on a single visitor's device, and shared caches such as CDN edge nodes and corporate proxies that serve many users. When a browser needs a file it already holds and the rules say the copy is still fresh, it uses the local version and skips the network entirely. This is one of the highest-leverage speed techniques available, because the fastest request is the one never made. We tune it as a core part of /services/speed-optimization, since correct caching improves both first and repeat visits without changing a single line of your visible content.
Cache-Control, the main instruction #
The Cache-Control header is how a server tells caches what they may do with a response. Its directives are simple but powerful. The max-age value sets how many seconds a copy stays fresh. The public and private directives say whether shared caches may store it or only the user's own browser. no-cache means a cache may keep a copy but must revalidate before using it, while no-store forbids caching altogether, useful for sensitive pages. immutable tells the browser a file will never change, so it should not even revalidate. Getting these right is the difference between a site that feels instant on return visits and one that needlessly re-downloads everything. Static assets that carry a version in their filename can be cached for a year safely, while HTML usually needs short or revalidated caching so content updates appear quickly. Because these directives combine, public with max-age and immutable together, one carefully chosen header line can govern both browser and shared caches at once, which is why we treat Cache-Control as the single most important header to get right for repeat-visit speed.
# Versioned asset: cache hard for a year
Cache-Control: public, max-age=31536000, immutable
# HTML page: always revalidate before reuse
Cache-Control: no-cache
# Private/sensitive: never store
Cache-Control: no-storeValidation with ETags and Last-Modified #
When a cached copy expires, the browser does not always re-download the whole file. Instead it can revalidate: ask the server whether its stored version is still current. Two headers make this efficient. An ETag is a fingerprint the server assigns to a specific version of a file; the browser sends it back in an If-None-Match request. Last-Modified records the file's timestamp, echoed in an If-Modified-Since request. If nothing changed, the server replies with a tiny 304 Not Modified response and no file body, so the browser keeps its existing copy and only a few bytes cross the network. This validation dance keeps caches accurate without wasting bandwidth on unchanged files. It is especially valuable for large assets that update occasionally, where a full re-download would be costly but a 304 check is nearly free. Well-configured hosting sets these headers automatically, part of what we maintain under /services/managed-hosting.
Fresh, stale, and revalidation #
A cached response moves through states. While inside its max-age window it is fresh and served instantly with no network trip. Once past that window it becomes stale, and the cache must revalidate with the origin before reusing it, or fetch a fresh copy. Modern caching adds nuance with directives like stale-while-revalidate, which lets a cache serve a slightly stale copy immediately while quietly fetching a fresh one in the background, so the user never waits. This gives the speed of caching with the accuracy of frequent updates. Understanding these states is essential for setting sensible lifetimes: too short and you lose caching's benefit; too long and users see outdated content until it expires. The right values depend on how often each file actually changes, which is why we audit real assets during a /free-website-audit rather than applying one blanket rule to an entire site. The art is matching each file's cache lifetime to how often it truly changes, so visitors rarely wait for a full download yet never linger on a genuinely outdated page.
Browser cache versus shared cache #
Caching happens at two levels, and they behave differently. The browser cache is private to one device and one user, so it can safely store personalized responses. Shared caches, CDN edge nodes, ISP proxies, and corporate gateways, serve many people, so they must only store content that is identical for everyone. The public and private directives in Cache-Control control this boundary. Marking a page public when it contains user-specific data risks leaking one person's information to another through a shared cache, a serious bug. Marking truly shared assets private wastes the CDN's ability to cache them. Getting this split right lets static files fly from the edge while personalized pages stay safe. Because shared caching and CDNs are so intertwined, we plan HTTP cache headers and CDN rules together, and confirm correctness across logged-in and logged-out states so no visitor ever receives content meant for someone else.
How caching affects Core Web Vitals #
Good HTTP caching mainly improves the repeat-visit experience, and that shows up in the metrics Google watches. When returning visitors and users moving between pages reuse cached CSS, fonts, and scripts, the browser can render faster, improving Largest Contentful Paint and reducing layout delays. Cached fonts avoid the flash of invisible text that hurts perceived speed. Fewer network requests also mean less contention on slow mobile connections. While caching does less for a brand-new visitor with an empty cache, most real audiences include many returning users and multi-page sessions, so the aggregate effect on field data is significant (web.dev). Caching pairs with other speed levers, image compression, code splitting, and a CDN, to move Core Web Vitals from failing to passing. We verify the result with real measurements using /tools/website-grader, because the only caching that counts is the kind that improves load times your actual visitors experience.
Common caching mistakes #
Several caching errors are common and costly. The worst is caching HTML too aggressively, so visitors keep seeing an old page after you publish updates. Another is failing to version static assets: if styles.css always has the same name, you must choose between short caching that wastes bandwidth or long caching that traps users on old styles. The fix is fingerprinted filenames like styles.a1b2c3.css that change when content changes, allowing year-long immutable caching safely. Some sites accidentally set no-store everywhere out of caution, destroying performance. Others leak private data through shared caches by mislabeling personalized pages as public. Query strings, cookies, and vary headers add further subtlety about what counts as the same response. These mistakes are easy to make and hard to spot without inspecting headers directly. We check them systematically during /services/speed-optimization so your caching is both fast and correct, rather than one at the expense of the other.
How we implement caching #
We approach caching as a layered plan. First we classify each type of response: immutable versioned assets, occasionally changing images, frequently updated HTML, and never-cache private pages. Each gets appropriate Cache-Control directives, with ETags for efficient revalidation. We add filename fingerprinting to your build so static files can be cached for a year and busted automatically on change. We set matching rules at the CDN edge so shared caching aligns with browser caching. Then we test: inspect headers, confirm 304 responses on unchanged files, verify updated content appears immediately after publishing, and check that logged-in pages never cache into shared layers. Finally we measure field Core Web Vitals to confirm the gains are real. This work integrates with the build tooling we set up in /services/web-app-development and the ongoing tuning in /services/managed-hosting, so your caching keeps working correctly as the site evolves rather than silently breaking after the next deployment.
FAQ
What is the difference between Cache-Control and ETag?
Cache-Control tells the browser how long it may reuse a file before checking again. An ETag is a version fingerprint used to check whether a stored file is still current. Cache-Control governs freshness; ETag enables cheap revalidation with a small 304 response when nothing has changed.
Why do users see an old version of my page?
Usually the page or its assets were cached too aggressively without a way to bust the cache. HTML often needs no-cache or short lifetimes, and static files need versioned filenames. Until the cached copy expires or is purged, browsers keep serving the old version.
How long should I cache my files?
It depends on how often they change. Versioned static assets, images, CSS, and JS with a hash in the filename, can be cached up to a year with immutable. HTML and frequently updated pages should use short lifetimes or revalidation so new content appears quickly.
Does caching help or hurt SEO?
Correct caching helps. Faster repeat visits improve Core Web Vitals, a Google ranking signal (web.dev), and reduce server load. Caching only hurts SEO if misconfigured so search engines or users see stale content, which proper headers and cache busting prevent.
What is a 304 Not Modified response?
It is a tiny reply the server sends when a cached file has not changed. Instead of resending the whole file, the server confirms the browser's copy is still valid using ETag or Last-Modified, so only a few bytes travel and the browser reuses its stored version.
Can caching expose private data?
Yes, if personalized pages are marked cacheable by shared caches. A page labeled public could be stored by a CDN or proxy and served to another user. Sensitive or user-specific responses should use private or no-store to keep them out of shared caches.
How Local Web Advisor checks this for you
Is your own website getting speed & core web vitals right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for speed & core web vitals and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?