2.1 Strong Caching#

Strong caching means: during the cache period, the browser doesn’t send a request at all and directly uses the local cache.

The HTTP response headers that implement strong caching are Cache-Control (HTTP/1.1) and Expires (HTTP/1.0).

1
HTTP/1.1 200 OK
2
Cache-Control: max-age=31536000, immutable

• max-age=<seconds>: The maximum valid time of the cache (in seconds), calculated from the request time
• immutable: Tells the browser that this resource will never change, and even if the user presses F5 to refresh, it should not re-validate

Expires vs Cache-Control

Expires uses absolute time, which has the problem of clock desynchronization:

1
Expires: Wed, 21 Oct 2026 07:28:00 GMT

If Cache-Control and Expires both exist, Cache-Control takes higher priority. In modern web development, we should uniformly use Cache-Control.

2.2 Negotiated Caching#

After strong caching expires, the browser sends a request with a validator to the server, and the server determines whether the resource has changed. If it hasn’t changed, it returns 304 Not Modified, and the browser continues to use the local cache; if it has changed, it returns 200 OK and the new content.

Negotiated caching relies on two pairs of HTTP headers:

Last-Modified / If-Modified-Since

1
# Response headers
2
Last-Modified: Tue, 01 Jul 2026 10:30:00 GMT
3

4
# Subsequent request headers
5
If-Modified-Since: Tue, 01 Jul 2026 10:30:00 GMT

The server compares the file’s last modification time. The drawback is that the precision is only at the second level, and if the file content doesn’t change but the mtime does (such as after a redeployment), it will also cause cache invalidation.

ETag / If-None-Match

1
# Response headers
2
ETag: "abc123"
3

4
# Subsequent request headers
5
If-None-Match: "abc123"

ETag is a hash value of the resource content, which is more precise than Last-Modified. If the content doesn’t change, the ETag doesn’t change. ETag has higher priority than Last-Modified.

4.1 Static Resources with Hashes (JS/CSS/Images)#

This is the type of resource most suited for aggressive caching. The content hash in the filename (such as main.a1b2c3d.js) ensures that the URL changes when the file content changes:

1
Cache-Control: public, max-age=31536000, immutable

• max-age=31536000: Cache for one year
• immutable: Even F5 refresh won’t re-validate, because URL change = content change

Modern bundlers like Vite, Webpack, and Next.js all output hashed filenames by default.

4.2 HTML Pages#

HTML cannot be aggressively cached because it is the entry point of the application. Once cached, users won’t see updates:

1
Cache-Control: no-cache

Or use a shorter max-age:

1
Cache-Control: public, max-age=0, must-revalidate

no-cache and max-age=0, must-revalidate have similar effects—validate every time, but allow returning 304.

4.3 API Endpoints#

For REST API responses, the caching strategy depends on the real-time requirements of the data:

1
// User personal info: do not cache
2
res.setHeader('Cache-Control', 'private, no-cache, no-store');
3

4
// Public article list: can cache for 60 seconds
5
res.setHeader('Cache-Control', 'public, max-age=60');
6

7
// Nearly unchanging data (e.g. country list): cache for 1 day
8
res.setHeader('Cache-Control', 'public, max-age=86400');

4.4 Font Files#

Font files are large in size and rarely change, making them suitable for long-term caching:

1
Cache-Control: public, max-age=31536000, immutable

But cross-origin issues need attention: browsers enforce CORS checks on font files, so make sure the CDN is configured with Access-Control-Allow-Origin.

4.5 Service Worker Scripts#

Service Worker caching has special rules: browsers ignore Cache-Control and cache for at most 24 hours. This is a browser security mechanism to ensure that malicious SWs don’t persist permanently.

5.1 CDN Cache Keys#

CDNs distinguish different resources based on cache keys. The default cache key is 域名 + URI. But for multilingual sites or A/B testing, custom cache keys may be needed:

1
#Add Accept-Language to the cache key to enable per-language caching
2
Cache-Key: ${host}${uri}${http_accept_language}

5.2 CDN Purge#

When resources need to be urgently updated, there are two options:

• Purge: Immediately delete the CDN cache, and the next request goes back to origin
• Prefetch: Push resources to CDN edge nodes in advance

Purge operations have a cooldown period (varies by CDN provider) and cannot be called frequently.

5.3 Coordinating Origin and CDN Cache Times#

A common question is: what happens when the origin’s Cache-Control: max-age=3600 conflicts with the cache time set in the CDN console?

Conclusion: Most CDNs prioritize the origin’s Cache-Control. But you can use s-maxage to separately control the CDN layer’s cache time:

1
Cache-Control: public, max-age=3600, s-maxage=86400

This means the browser caches for 1 hour, and the CDN caches for 24 hours.

6.1 File Fingerprinting#

The best practice. Each build artifact’s filename contains a hash of its content:

1
main.abc123.js  →  main.def456.js

Old files can continue to be cached, and new files are treated as new resources because of their different URLs. This is why Webpack/Vite output [name].[contenthash].js by default.

6.2 Cache Busting: Query Parameters#

Append ?v=1.0.1 to the URL:

1
<link rel="stylesheet" href="/style.css?v=2.0.0">

This approach is simple but has many problems:

• Many CDNs ignore query parameters by default, causing busting to fail
• Intermediate proxies may not cache resources with query parameters
• Cannot be used in conjunction with immutable

Not recommended; filename fingerprinting should be preferred.

6.3 Purge API#

Proactively clear the cache through the API provided by the CDN. Suitable for emergency fix scenarios (such as production bugs), but not suitable as a regular update method.

7.1 Chrome DevTools#

In the Network panel, check the Size column of resources:

• (disk cache) / (memory cache): Strong cache hit
• 304 Not Modified: Negotiated cache hit
• 200 OK（具体大小）: Re-downloaded from the server

Note: The Disable cache checkbox only takes effect while DevTools is open. Don’t forget to uncheck it to verify actual caching behavior.

7.2 cURL Command-Line Debugging#

1
# View full response headers
2
curl -I https://example.com/style.css
3

4
# Send If-None-Match to verify conditional caching
5
curl -I -H 'If-None-Match: "abc123"' https://example.com/style.css
6

7
# Simulate browser caching behavior
8
curl -H 'Cache-Control: max-age=0' https://example.com/style.css

7.3 Troubleshooting Common Issues#