How caching reduces resource use and associated emissions

Caching reduces the number of times an origin server must answer a request and the volume of data that moves across the network. Fewer origin requests mean less CPU and I O on backend systems. Less data transferred saves client battery and network infrastructure energy. Both effects reduce the greenhouse gas footprint of delivering a website when measured over real traffic. The remainder of this article explains concrete techniques and trade offs for browser cache, CDN cache, and server side caches so teams can make decisions that preserve user experience while cutting avoidable work.

Cache layers and their roles

Browser cache

The browser cache keeps resources on the user device so repeated navigations fetch from local storage rather than the network. It is the last mile for avoiding network transfer and device CPU use. Use browser caching for static assets that can be safely reused between pages and visits.

Key controls to configure

• Cache Control header with max age to allow long living caches for immutable assets.
• ETag or Last Modified to support conditional requests when freshness matters.
• Service workers for sites that need offline first behavior or fine grained cache logic.

Practical patterns

• Serve CSS, JavaScript, fonts, and images with content hashed filenames and a long max age so the browser can cache them aggressively. When the file changes the filename changes and the new copy downloads.
• Use short max age for HTML while applying conditional requests or stale while revalidate behavior to reduce perceived latency without always hitting origin.

CDN cache

CDNs cache content close to users and absorb a large share of traffic that would otherwise reach the origin. CDN caches reduce global bandwidth and origin compute simultaneously. Configure CDN cache keys and TTLs deliberately so caches are effective without serving incorrect content.

Key controls to configure

• s maxage directive to set TTL for shared caches.
• Cache key composition to decide which request parts matter to cache entries.
• Stale while revalidate to return cached content while the CDN refreshes in the background.

Practical patterns

• Cache static assets at the edge with long TTLs and use versioned URLs to invalidate caches when needed.
• For personalized or per user content, separate the uncacheable portion from the cacheable shell so the CDN can still serve common assets.
• Use surrogate keys or cache tags if the CDN supports them to invalidate groups of objects without purging everything.

Server cache

Server side caches reduce backend compute. They include in memory caches, reverse proxies, and application level caches. Proper server caching lowers CPU cycles and database queries originating from cacheable requests.

Key controls to configure

• Cache granularity from whole page caching to fragment caching for parts of a page.
• Eviction and TTL policies that match content update frequency.
• Cache warmers to avoid cold start storms after deploys or purges.

Practical patterns

• Cache rendered HTML for public pages where content changes less frequently, and use short TTL or conditional revalidation for pages that change more often.
• Cache expensive query results rather than raw SQL calls when query parameters are stable across users.
• Use origin shielding or a single origin node that handles misses to reduce duplicated work across edge POPs.

Cache control directives and examples

Headers expressed in responses tell intermediaries and browsers how to treat resources. A few widely used directives and examples follow. When you set headers, keep the intent explicit so downstream caches behave as expected.

Examples

• Immutable static asset served with long cache life: Cache Control: max age=31536000, public, immutable
• Shared edge cache with revalidation: Cache Control: s maxage=3600, stale while revalidate=60
• HTML that uses conditional checks: Cache Control: max age=0, must revalidate; server sets ETag or Last Modified

When you use s maxage, note that it only applies to shared caches like CDNs and proxy caches. The public directive signals that shared caches may store the response. Immutable tells modern browsers that the resource will not change even if the filename is constant, enabling long term caching with confidence.

Decision criteria for TTLs and freshness

Pick TTLs by answering a small set of questions about each resource. How often does the content change? What is the user impact if a cached copy is slightly stale? Is the resource large in bytes or compute intensity? Priority should go to caching large, stable assets that carry the highest network and compute cost.

Simple decision rules

1. For assets with content hashed filenames use a very long TTL because updates change the URL.
2. For assets that change frequently but are not personalized use short TTLs combined with stale while revalidate to keep users responsive while the origin refreshes.
3. For personalized data avoid long caches. Instead cache shared fragments and compute personalization client side where possible.

Invalidation, purge and versioning strategies

Invalidation must be safe and predictable. Use URL versioning for static assets because it avoids the need to purge caches. Use cache tags or surrogate keys when you need to invalidate many related objects at once. When purging is unavoidable, prefer targeted purges over wholesale flushes and coordinate purges with deploys to avoid transient cache misses at scale.

Avoid these common mistakes

• Purer pages that rely on query strings for cache identity without normalizing the query parameters. This often results in cache fragmentation and reduced hit ratio.
• Setting no caching on HTML and serving the same unchanging HTML on many requests. This increases origin load unnecessarily.

Measuring impact and sound KPIs

Measure cache hit ratio at each layer, origin request rate, and bytes served from cache versus origin. Track backend CPU and database query rates to see the compute reduction after cache changes. Use real user measurement to confirm reduced client side network transfer on repeat visits. Combine these operational metrics with your existing carbon accounting process to estimate avoided emissions, using published conversion factors for electricity and network where appropriate.

Advanced techniques that preserve UX and save resources

Service workers allow fine grained control in the browser for caching single page application assets and API responses. Stale while revalidate at the edge returns cached content immediately while fetching a fresh copy in background. Edge compute combined with caching can assemble responses from cached fragments, reducing origin hits while still delivering near real time content.

When caching is not the right tool

Highly dynamic, audit critical, or legally constrained content may require real time origin responses. In those cases focus on caching adjacent layers such as static assets, CDN level caching for shared components, and database query optimization so the unavoidable origin work is as efficient as possible.

Implementation checklist

• Inventory assets and group by volatility and size.
• Apply content hashing and long TTLs to immutable assets.
• Set s maxage for CDN caches and use stale while revalidate where appropriate.
• Introduce server side caching for expensive compute or database operations.
• Use cache keys that normalize irrelevant request parts to increase hit ratios.
• Instrument cache hit ratio, origin request rate, and bytes saved and review after each change.

Small adjustments to cache configuration scale with traffic. A modest increase in edge hit ratio reduces origin work across all users and improves response times for everyone, while lowering the energy consumed by servers and networks. Start with the largest, most stable assets and iterate toward more sophisticated cache control as you verify outcomes.

Next steps for teams should include a brief measurement pilot that changes one header at a time, compares origin request counts before and after, and verifies user visible freshness on a representative set of pages.