Skip to content 
With Cache-Control Hosting, I specifically control how browsers, proxies and CDNs cache content so that pages load faster and still remain up-to-date. To do this, I use targeted directives such as max-age, no-cache or no-store and thus balance performance, freshness and server load for HTML, assets and APIs.
Key points
The following overview shows the most important levers for Web optimization with cache control.
- TTL designLong max-age for assets, short times or revalidation for HTML.
- ValidationETag and Last-Modified reduce data traffic with 304 responses.
- Edge controls: s-maxage, stale-while-revalidate and stale-if-error for CDNs.
- Versioning: File names with hash/version allow aggressive caches.
- MonitoringCheck cache hit rates, 304 quotas and TTFB on an ongoing basis.
What makes cache control so effective in hosting?
I move work from the Origin server to the Cache, reduce latency and save bandwidth. A properly set cache control header controls how long files remain valid and when the client requests them from the server. I plan long validity periods for assets such as images, CSS and JS, while HTML lives for a short time or is always validated. This means that users encounter cached responses more frequently and still receive current Content. I avoid typical stumbling blocks such as contradictory headers or missing versioning early on, for example with this Cache-Fix Guide.
Basics: Combining directives correctly
With max-age I set the lifetime in seconds, such as 31536000 for one year for static resources. no-cache forces the client to validate before use, but does not prohibit storage. no-store excludes any storage and protects sensitive responses such as payment data. public allows caching in shared storage such as CDNs, private is limited to the browser cache. immutable signals that the file remains unchanged, which can be changed with Versioning (e.g. app.v1.2.js) are an excellent addition.
Clearly define Vary headers and cache keys
I make sure that cached objects match the request type. The Vary-header therefore belongs in every serious cache strategy. It influences the cache key and prevents incorrect reuse:
- Accept-EncodingMandatory with gzip/br, so that compressed and uncompressed variants are cached separately.
- Accept-Language: Only use if I am really delivering language-dependent content - otherwise there is a risk of fragmentation.
- Cookie: I avoid a global Vary: Cookie, because it destroys cache hit rates. Instead, I segment specifically according to relevant cookies (e.g. A/B variant) or remove irrelevant cookies at the edge.
- AuthorizationContent that depends on auth headers is not stored in shared caches or I deliberately key them if the CDN provider supports this.
# Apache: meaningful Vary headers for HTML and assets
Header merge Vary "Accept-Encoding"
Header merge Vary "Accept-Encoding"
On CDNs, I also define clear cache key rules: I do not include query parameters that are only used for tracking (e.g. utm_*) in the key. In this way, I prevent key explosion without jeopardizing freshness.
Practice: Configuration on Apache and Nginx
On Apache I set rules in the .htaccess or in the VirtualHost. I separate HTML from assets, give static files a long lifespan and secure HTML with revalidation. I avoid conflicts with Expires headers, modern browsers primarily respect cache control. On Nginx, I enforce correct add_header positions and make sure that no downstream instructions overwrite them. This is how I control Browser caching consistent across the entire stack.
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, must-revalidate"
location ~* \.(css|js|png|jpg|svg|woff2)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
location ~* \.(html)$ {
add_header Cache-Control "no-cache, must-revalidate";
}
CDN-only caching for HTML
If the browser should always check, but the Edge is allowed to cache, I set different lifetimes for client and CDN:
# Apache: Browser revalidated, Edge cached 5 minutes
Header set Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400"
Header merge Vary "Accept-Encoding"
# Nginx
location ~* \.(html)$ {
add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate, stale-while-revalidate=30, stale-if-error=86400";
add_header Vary "Accept-Encoding";
}
Validation: using ETag and Last-Modified effectively
I combine Cache control with ETag and Last-Modified to revalidate in a controlled manner. After expiry, the browser sends If-None-Match or If-Modified-Since; the server responds with 304 if the resource is unchanged. This saves bytes and significantly reduces CPU time at Origin. Important: ETags must be consistent, otherwise unnecessary misses will occur despite unchanged content. On clusters, I deactivate weak ETags or create strong hashes so that the rehabilitation remains reliable.
Consistency in multi-server environments
I make sure that ETags are not based on inode-based features that differ between nodes. I either provide a stable hash (build artifact) or rely on last-modified when deploys are atomic. For dynamic responses, I use application ETags that exactly match the payload hash. If revalidation is more expensive than re-rendering, I deliberately respond with 200 and a short TTL - measurement decides.
Strategies by resource type
I differentiate by content type, because HTML, assets, APIs and sensitive responses have different Requirements. Long TTLs for versioned files deliver best values, while HTML must remain tightly managed. For APIs, I plan short lifetimes and build in fault tolerance. I prevent any storage of personal or confidential responses. Those who go deeper into interfaces benefit from compact patterns for API caching in hosting, which I adapt to the response characteristics.
| Resource type | Recommended directive | Reason |
|---|---|---|
| Static assets (images, CSS, JS) | public, max-age=31536000, immutable | Long storage; versioning prevented Stale-Content |
| HTML pages | no-cache, must-revalidate | Fresh content through rehabilitation |
| APIs | public, max-age=300, stale-if-error=86400 | Short deadline, usable for Errors |
| Sensitive data | no-store | No storage from Data protection-Reasons |
Status codes, redirects and error pages
- 301 can and should be cached (long TTL) as it is permanent. I version target URLs to facilitate later changes.
- 302/307 are temporary - short TTL or revalidation, otherwise there is a risk of incorrect paths in the cache.
- 404 I cache for a short time (e.g. 60-300s) so that faulty hotlinks do not burden Origin without blocking real recreations.
- 500+ I do not cache, but leave on the Edge stale-if-error to provide users with the latest information.
Extended directives for CDNs and Edge
With s-maxage I separate the lifetime in the edge cache from that in the browser. stale-while-revalidate continues to deliver expired content while the edge updates in the background. stale-if-error keeps pages accessible during backend outages and boosts conversion and trust. must-revalidate forces a check after expiration and prevents unwanted renewals. This control pays directly on cache hit rates and Scaling especially during traffic peaks.
Surrogate and edge headers
In setups with edge rendering, I also use surrogate headers (e.g. Surrogate control) to set more CDN-specific TTLs and stale policies without changing browser behavior. This way, I strictly separate end-user and edge strategy and keep my control over both levels.
Invalidation and releases
I plan invalidation deliberately: versioned assets rarely need purges, whereas HTML and API routes need them more often. I define clear routines for:
- Purge by URL/Pattern for hotfixes and errors.
- Tag-based purges (if supported) to invalidate thematically related content.
- Staged rolloutsFirst deploy assets, then HTML with new references - this prevents broken references.
WordPress: Implementing caching securely
In WordPress, I activate headers via plugins or my own code and observe the Template-structure. Static files in wp-includes and uploads get long TTLs plus immutable, pages get no-cache with must-revalidate. Caution with logged-in users: private and differentiated cookies prevent incorrect personalization in the cache. I eliminate typical stumbling blocks with clear rules and by taking a look at these WordPress caching error. If necessary, I add server-side page caching and OPCache to make PHP execution noticeable. sinks.
<?php
function add_cache_headers() {
if (!is_admin()) {
header('Cache-Control: public, max-age=31536000, immutable', true);
}
}
add_action('send_headers', 'add_cache_headers');
Defuse personalization and cookies
I make sure that Set-Cookie not is set across the board on all pages. Unnecessary cookies prevent shared caching. I deliver explicitly for logged-in users:
# Example header for logged-in sessions
Cache-Control: private, no-store, max-age=0
Vary: Accept-Encoding
List and detail pages without personalization, on the other hand, get full CDN power. Where personalization is necessary, I work with edge fragments or small API payloads and have the rest cached aggressively.
Common mistakes and how I fix them
Too low TTL generates unnecessary server work and higher response times. Missing or contradictory headers force browsers to heuristic behavior and cost performance. Without versioning, I risk outdated assets despite long caches. Different ETag strategies on several servers lead to misses; I ensure consistent hashes or deactivate ETags there. I also check whether intermediaries such as gateways have their own Header append and overwrite.
Avoid heuristic caching
If neither Cache-Control nor Expires is set, browsers guess. I therefore always turn off explicit directives and clean up legacy issues (e.g. Pragma: no-cache from old proxies) to obtain deterministic behavior.
Query strings and cache busting
I use cache busting via file name hashes (style.abc123.css) instead of query strings. Many caches treat different queries as separate objects and thus increase the number of objects; with unchanged files, on the other hand, a new hash leads to a clean invalidation.
Monitoring, tests and metrics
I measure effects and make targeted corrections instead of making sweeping changes, because data beats gut feeling clear. I use curl to check headers, DevTools to simulate first and repeat views and Lighthouse to evaluate the effect on key figures. On the server and CDN side, I monitor cache hit rates, 304 quotas, byte saves and TTFB. Logs show me whether HTML is really revalidated and whether assets are rarely requested again. This allows me to recognize gaps early on and improve targeted.
Additional diagnostic signals
- Age-header shows how long an object has been in the cache - ideal for checking s-maxage.
- Cache status (if available) reveals HIT/MISS/STALE and the source (BROWSER, CDN, ORIGIN).
- Server timing I use it for my own markers (e.g. cache;desc=“revalidated“) to make paths visible in tools.
I automate checks in the CI/CD pipeline: After each deployment, a small test catalog validates headers, status codes and response sizes for the top routes. Regressions are noticed immediately.
SEO and business effects
Faster delivery strengthens Core Web Vitals, reduces bounces and raises the Visibility. Every round trip avoided reduces server costs and minimizes peak load risks. With traffic-intensive sites, I save a noticeable amount of data volume every month; depending on the tariff, this can add up to three-digit amounts in euros. A high cache hit rate also stabilizes response times for campaigns and sales. Those who increase performance in a predictable way usually also increase the Conversion.
Practical checklist in 7 steps
(1) Inventory files and separate HTML, assets, APIs and sensitive responses; these Segmentation facilitates rules. (2) Introduce versioning for CSS/JS/images; use hashes in filenames and set immutable. (3) Set no-cache and must-revalidate for HTML; keep pages fresh and controllable. (4) Define short TTLs for APIs plus stale-if-error to mitigate failures. stay. (5) Enable ETag or Last-Modified consistently; check 304 quotas. (6) Synchronize CDN and Origin headers; use s-maxage for Edge. (7) Measure hit rates, TTFB and byte saves; optimize iteratively and document decisions.
Additional practical cases and samples
- APIs with conditional requestsI explicitly allow GET/HEAD responses in the shared cache (public) with a short TTL and ETag. I only cache POST responses if they are precisely defined and unchanged - they remain uncacheable by default.
- Large files and range requests: For Media I deliver Accept-Ranges: bytes and long TTLs; the Edge relieves the Origin when resuming downloads.
- Responsive ImagesIf I output different image variants depending on the device, I key specifically (e.g. according to DPR or Width) and avoid uncontrolled Vary on too many signals.
- No-Transform: If image quality or cryptography is critical, I use Cache-Control: no-transform, so that proxies do not change the resource.
Summary to take away
I use Cache-Control specifically to Performance, to bring timeliness and costs into harmony. Long TTLs plus versioning for assets, revalidation for HTML and short deadlines for APIs deliver reliably good results. ETag and Last-Modified reduce data traffic, while s-maxage and stale policies exploit edge caching. Monitoring makes effects visible and shows where I should tighten up. This keeps hosting fast, controllable and economical attractive.
