Caching Strategy for Core Web Vitals: Browser Cache, CDN Cache, and What to Measure

Caching is one of the highest leverage performance fixes because it reduces repeated work. A good caching strategy can make pages feel instant for returning visitors, reduce server load, improve Time to First Byte, and help Core Web Vitals by getting critical assets to the browser faster. A bad caching strategy can do the opposite. It can serve stale prices, hide broken deploys, cache personalized pages, or make debugging miserable.

The goal is not to cache everything forever. The goal is to decide what can be reused, where it should be reused, how long it should live, and how it gets refreshed when the underlying content changes. That means thinking about browser cache, CDN cache, server cache, and application data separately instead of treating caching as a single switch.

Start by separating page HTML from static assets

The first mistake most teams make is using one caching rule for everything. Your homepage HTML, product page HTML, JavaScript bundle, CSS file, logo, font file, API response, and uploaded image do not have the same risk profile.

Static assets are usually the easiest win. Versioned files such as app.8fd21.css, main.4a7b9.js, and optimized images can often be cached for a year because the filename changes when the file changes. HTML is different. It may include fresh inventory, local content, user state, pricing, seasonal copy, or structured data. Cache it carefully and make sure there is a reliable purge or revalidation path.

A practical rule: cache versioned assets aggressively, cache public HTML briefly or with revalidation, and avoid caching anything that depends on a logged in user unless it is explicitly designed for it.

Use browser cache for repeat visits

Browser caching helps when the same visitor loads another page or returns later. The browser can reuse files it already downloaded instead of requesting them again. This is especially useful for CSS, JavaScript, fonts, logos, icons, and common interface images that appear across many pages.

For fingerprinted static assets, use a long lifetime such as Cache-Control: public, max-age=31536000, immutable. The immutable directive tells the browser not to check whether the file changed during its lifetime. That is safe only when the filename changes on every content change.

For HTML, use shorter rules. Many sites do well with Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400 at the CDN level. This tells browsers not to keep their own long copy, while allowing shared caches to serve the page quickly and refresh it in the background. The exact numbers depend on how often your content changes and how risky stale content would be.

Use CDN cache to reduce TTFB

Time to First Byte is not a Core Web Vital by itself, but it strongly influences Largest Contentful Paint. If the server takes a long time to deliver the first HTML byte, the browser cannot discover the hero image, CSS, scripts, or main content early. CDN caching helps by serving cacheable responses from an edge location closer to the visitor.

Start with public, high traffic pages: homepage, blog posts, documentation, glossary pages, category pages, location pages, and evergreen guides. These pages usually do not need server computation on every request. If the CDN can serve them from cache, the origin server does less work and users get the first byte faster.

Do not cache admin pages, account pages, carts, checkout, dashboards, preview URLs, or pages with private user data. Also be careful with query strings. Some query parameters change content, while tracking parameters such as utm_source usually should not create separate cache entries. Normalize or ignore marketing parameters where your CDN allows it.

Understand stale-while-revalidate

stale-while-revalidate is useful because it avoids making users wait while the cache refreshes. When a cached response becomes stale, the CDN can serve the old version immediately, then fetch a fresh version in the background for the next visitor.

This is excellent for blog posts, guides, help docs, and many marketing pages. A visitor receiving a page that is a few minutes old is usually fine. It is not fine for stock levels, limited time pricing, legal notices, or user specific information. The risk is not technical. The risk is whether a stale response would mislead the visitor or hurt the business.

Use stale responses where freshness is nice but speed matters more. Avoid them where freshness is part of the promise.

Measure cache hit ratio by template

A sitewide cache hit ratio can hide problems. If static assets have a 99 percent hit ratio but product pages miss constantly, the overall number may look healthy while important pages still feel slow. Measure cache behavior by template, path pattern, device type, geography, and response type.

Look for pages with high traffic and low hit rates. Common causes include unneeded cookies, random query parameters, inconsistent trailing slashes, headers that forbid caching, personalization baked into HTML, and deployment systems that purge too broadly. Fixing those issues often improves performance without touching page design or JavaScript.

Useful metrics include cache hit ratio, origin requests, edge response time, TTFB in field data, LCP changes on repeat visits, and the percentage of HTML served from cache. If you can connect cache improvements to real user metrics, it becomes easier to justify the work.

Avoid caching personalized HTML by accident

The worst caching bugs are privacy bugs. If a response contains a user's name, email, cart, account details, admin controls, location specific offer, or session dependent content, it should not be stored in a shared cache unless the system varies the response correctly and safely.

Audit pages that set cookies. Many CDNs bypass cache when cookies are present, which protects privacy but can destroy cache efficiency if every visitor gets a tracking cookie before the first page loads. Separate necessary session cookies from analytics cookies. Avoid making public pages look private just because a marketing script sets a cookie.

When content truly varies by location, language, device, or currency, use explicit vary rules and test them. Do not assume the CDN understands your application logic. Fetch the same URL with different headers and cookies to verify that each visitor gets the correct version.

Plan purge rules before you need them

Caching only works when you can refresh it predictably. If editors publish a new blog post, update a title tag, change a price, or fix a typo, they should not need to wait hours or ask an engineer to purge the entire site.

Create targeted purge rules. Purge a changed URL, related category pages, sitemap files, RSS feeds, and any listing pages that include the changed content. Avoid purging everything unless you truly changed global assets or layout. Full purges can create a traffic spike to origin and temporarily erase the performance benefit you built.

For static builds, make sure deploys produce new asset filenames. For CMS driven sites, connect publish events to cache invalidation. For ecommerce, connect product and inventory changes to the specific URLs they affect. The better your purge logic, the more confidently you can cache.

Check Core Web Vitals before and after

Caching should improve the user experience, not just a server dashboard. Before changing rules, record baseline data for important templates. Use Chrome UX Report, PageSpeed Insights field data, Real User Monitoring, server logs, CDN analytics, and synthetic tests from key regions.

After the change, watch TTFB, LCP, and repeat view performance. A better cache strategy often improves LCP because the browser receives HTML and critical assets sooner. It can also reduce INP indirectly by lowering the amount of late loading work on repeat visits. Cumulative Layout Shift usually needs layout fixes, but faster asset delivery can still reduce visible instability in some cases.

Do not celebrate a perfect Lighthouse run if field data does not move. Lab tools are useful for debugging, but cache value shows up most clearly across many real visits, regions, and templates.

The practical next step

Pick five important URLs and inspect their response headers. Check HTML, CSS, JavaScript, fonts, images, API calls, and redirects. Write down the current Cache-Control rules, whether the CDN served a hit or miss, and whether the response includes cookies or personalization.

Then make one focused improvement: long cache lifetimes for fingerprinted assets, short CDN caching for public HTML, query parameter normalization, targeted purge rules, or stale-while-revalidate for evergreen pages. Measure the effect on TTFB and LCP before expanding the rule to more templates.

A strong caching strategy is boring in the best way. Pages load faster, servers work less, deploys remain predictable, and users get fresh enough content without waiting for the origin on every request. That is exactly the kind of technical SEO fix that compounds over time.