HTTP Caching for Websites: A Complete Guide

HTTP caching is a set of rules that tell browsers and intermediary servers to store copies of your website’s files so they can be reused on later visits. Done well, it removes redundant downloads, slashes load times for returning visitors, and reduces server strain. The result is a faster, cheaper, more reliable site.

Key takeaways

• HTTP caching stores reusable copies of assets so repeat visits skip the network round trip and render almost instantly.
• The two pillars are freshness (Cache-Control and Expires) and validation (ETag and Last-Modified) working together.
• Fingerprinted static assets like CSS, JavaScript, fonts, and images can be cached for a full year safely.
• HTML documents should use short or revalidated caching so content updates reach visitors quickly.
• A content delivery network adds a second caching layer at the edge, close to your users.
• Framer handles fingerprinting, CDN delivery, and cache headers automatically, so most teams get strong caching without configuration.

What HTTP caching actually does

Every time someone visits your site, their browser requests files: the HTML document, stylesheets, scripts, fonts, and images. Without caching, the browser re-downloads every one of those files on every page view, even when nothing has changed. That wastes bandwidth, adds latency, and makes your server work harder than it needs to.

HTTP caching changes this. When a response includes the right headers, the browser keeps a local copy of the file. On the next request, it checks whether that copy is still usable. If it is, the browser serves the file from disk in milliseconds instead of fetching it again across the network. Visitors feel the difference immediately, especially on repeat visits and multi-page journeys.

Caching also happens beyond the browser. Content delivery networks, reverse proxies, and other intermediaries can hold copies of your assets and serve them to many users. This is where caching shifts from a small optimization to a major performance lever. If you are building a complete performance plan, caching sits alongside the work covered in our website speed optimization guide.

The two mechanisms: freshness and validation

HTTP caching rests on two ideas. The first is freshness: how long a cached copy can be used without checking back with the server. The second is validation: how the browser confirms a stored copy is still current when its freshness window expires.

Freshness with Cache-Control

The Cache-Control header is the modern way to control caching. It carries directives that describe exactly how a response may be stored and reused. The most important one is max-age, which sets how many seconds a response stays fresh. A header like Cache-Control: max-age=31536000 tells the browser the file is good for a year.

Other common directives shape the behavior further. public allows shared caches such as a CDN to store the file. private restricts storage to the individual browser, which suits personalized responses. no-cache permits storage but forces revalidation before each reuse. no-store blocks caching entirely, which you want for sensitive data. immutable tells the browser the file will never change during its lifetime, so it should not bother revalidating.

Validation with ETag and Last-Modified

When a cached file’s freshness expires, the browser does not always need to re-download it. Instead it can ask the server a simple question: has this changed? Validation headers make that possible.

An ETag is a fingerprint the server attaches to a file, often a hash of its contents. On revalidation, the browser sends that fingerprint back with an If-None-Match header. If the file is unchanged, the server replies with a lightweight 304 Not Modified status and no body. The browser keeps using its stored copy. Last-Modified works similarly using a timestamp and the If-Modified-Since header. Both turn a heavy download into a tiny confirmation request.

How to set cache policies by file type

Different files deserve different caching rules. The right policy depends on how often a file changes and how important it is for visitors to see updates instantly.

Static assets: cache aggressively

Stylesheets, JavaScript bundles, fonts, and images change rarely, and when they do, modern build tools give them a new filename. This practice is called fingerprinting or cache busting. A file named main.4f8a2c.css can be cached for a full year because any change produces a different filename like main.9b1d7e.css. The browser treats it as a brand new file and fetches it once.

For these assets, the strongest policy is Cache-Control: public, max-age=31536000, immutable. The browser caches them for a year and never revalidates, which removes even the small 304 check. This is the single biggest win in most caching setups. The CSS you ship matters here too, and our critical CSS guide explains how to structure stylesheets for fast first paint alongside long-term caching.

HTML documents: cache carefully

HTML is different. It is the entry point that references all your fingerprinted assets, and it changes whenever you publish new content. If you cache HTML for a year, visitors could see stale pages long after you update them. The safe approach is a short max-age combined with revalidation, such as Cache-Control: no-cache or a small value like max-age=300 paired with an ETag. The browser checks for a fresh version frequently but still avoids full downloads when nothing changed.

API responses and personalized content

Dynamic responses need judgment. Public data that updates on a schedule can use a modest max-age. Anything tied to a logged-in user should be private at most, and truly sensitive responses should use no-store. The guiding question is simple: would it ever be wrong to show a stored copy of this response to this person?

Caching and Core Web Vitals

Caching does not change how your page is built, but it strongly affects how fast it feels on repeat visits and across a session. When fonts and CSS load from cache, text renders sooner, which helps Largest Contentful Paint. When scripts load from cache, interactivity arrives faster, which helps Interaction to Next Paint. Stable cached layout assets also support a clean Cumulative Layout Shift score because nothing re-downloads and reflows mid-render.

Repeat-visit performance is easy to overlook because synthetic tests often measure a cold first load. Real users return, click into multiple pages, and benefit from every cached byte. To understand how these metrics connect to the broader picture, read our Core Web Vitals guide, which covers what Google measures and why it matters for both experience and search.

The CDN layer

Browser caching helps a single returning visitor. A content delivery network helps everyone. A CDN stores copies of your assets on servers distributed around the world, so a visitor in another country pulls files from a nearby edge location instead of your origin server far away. This cuts latency dramatically and protects your origin from traffic spikes.

CDNs respect the same Cache-Control headers, with the public directive signaling that an asset may be stored at the edge. Pair fingerprinted assets with long max-age values and a CDN, and most requests never reach your origin at all. The page loads from a server a few milliseconds away.

How to verify your caching is working

You should never assume your headers are correct. Verify them. Open your browser’s developer tools, go to the Network tab, and reload a page. Each request shows its response headers, including Cache-Control, ETag, and the status code. On a repeat load, cached files report a status like 200 (from disk cache) or a 304 Not Modified when revalidated. If a file you expect to be cached is downloading fully every time, its headers are wrong.

You can also check from the command line. A request with the headers-only flag returns the response headers without the body, letting you confirm exactly what Cache-Control value a file is serving. Run this against your CSS, JavaScript, and HTML to confirm each file type carries the policy you intended. Static assets should show a long max-age, and HTML should show a short or revalidating policy. Checking in production, not just on your local machine, is essential, because build and hosting layers can change headers in ways you did not expect.

Caching and your hosting layer

Caching behavior is shaped by where your site is hosted. Some platforms apply strong defaults automatically, while others leave the headers entirely up to you. On traditional servers you may need to configure caching rules directly, deciding per file type how long assets live and whether HTML revalidates. This gives full control but also full responsibility, and it is easy to ship a misconfiguration that either caches HTML too long or fails to cache assets at all.

Modern hosting platforms increasingly handle this for you, combining fingerprinted builds, edge CDNs, and sensible header defaults so that good caching is the baseline rather than a manual task. The trade-off is worth understanding for your specific stack, because the difference between a hand-tuned configuration and a platform that gets it right by default is often the difference between a site that is fast for everyone and one that is fast only after careful work. Knowing which category your host falls into tells you how much caching work is actually yours to do.

Common caching mistakes

The most damaging mistake is caching HTML too aggressively without a way to bust it. Visitors get stuck on old pages, and you cannot tell why your updates are not showing. Always keep HTML on a short leash.

The opposite mistake is caching nothing. Some teams disable caching while debugging and forget to re-enable it, leaving every visitor to re-download everything. Check your headers in production, not just on your machine.

A third common error is shipping static assets without fingerprinting, then being afraid to cache them because a change could leave users stranded on an old version. Fingerprinting solves this cleanly. If your build does not add content hashes to filenames, fix that before reaching for long cache lifetimes.

Finally, teams sometimes set conflicting headers, such as a long max-age alongside no-cache. Pick one coherent policy per file type and verify it with browser developer tools or a command-line request.

How Framer handles caching for you

Most of this work is invisible on Framer because the platform handles it automatically. Framer fingerprints your static assets, so CSS, JavaScript, fonts, and images get unique content-based filenames and long cache lifetimes without any setup. It serves everything through a global CDN, so visitors anywhere load assets from a nearby edge. And it applies sensible cache headers to HTML so your published changes appear quickly while still benefiting from validation.

This means a Framer site arrives with strong caching defaults baked in. You get the repeat-visit speed, the CDN reach, and the reduced server load without writing a single header. If your site has unusual requirements or you want to confirm everything is configured for your goals, our team can review your setup and tune it. You can talk to our Framer experts about a performance audit.

Frequently Asked Questions

How long should I cache my website files?

Cache fingerprinted static assets like CSS, JavaScript, fonts, and images for a full year using max-age=31536000 plus the immutable directive, since a content change produces a new filename. Cache HTML documents for a short window with revalidation so new content reaches visitors quickly.

What is the difference between no-cache and no-store?

The no-cache directive allows the browser to store a copy but requires it to revalidate with the server before reusing the file. The no-store directive forbids storing the response at all, which is the right choice for sensitive or personal data that should never be reused.

Does HTTP caching help with SEO?

Indirectly, yes. Caching improves load speed and Core Web Vitals, both of which Google considers in ranking. Faster repeat visits and lower server load also create a better experience, which supports engagement signals. Caching is not a direct ranking factor, but its performance benefits help.

Do I need to configure caching on Framer?

No. Framer fingerprints static assets, serves them through a global CDN, and applies sensible cache headers to HTML automatically. Most sites get strong caching with no setup. You only need to revisit it for unusual requirements, and a quick expert review can confirm everything is tuned for your goals.