cache control vs expires headers & if modified since
Cache control headers directives Meaning
no-cache
The no-cache response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.
Cache-Control: no-cache
NO cache vs no store
Note that no-cache does not mean “don’t cache”. no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of “don’t cache” that you want is actually “don’t store”, then no-store is the directive to use.
must-revalidate
The must-revalidate response directive indicates that the response can be stored in caches and can be reused while fresh. If the response becomes stale, it must be validated with the origin server before reuse.
Typically, must-revalidate is used with max-age.
Cache-Control: max-age=604800, must-revalidateproxy-revalidate
The proxy-revalidate response directive is the equivalent of must-revalidate, but specifically for shared caches only.
no-store
The no-store response directive indicates that any caches of any kind (private or shared) should not store this response.
Cache-Control: no-storestale-while-revalidate
The stale-while-revalidate response directive indicates that the cache could reuse a stale response while it revalidates it to a cache.
Cache-Control: max-age=604800, stale-while-revalidate=86400
In the example above, the response is fresh for 7 days (604800s). After 7 days it becomes stale, but the cache is allowed to reuse it for any requests that are made in the following day (86400s), provided that they revalidate the response in the background.
Revalidation will make the cache be fresh again, so it appears to clients that it was always fresh during that period — effectively hiding the latency penalty of revalidation from them.
If no request happened during that period, the cache became stale and the next request will revalidate normally.
Cache-Control
The Cache-Control general-header field is used to specify directives for caching mechanisms in both, requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.
Read more at MDN Web Docs
http cache-control header examples Best practices for html & js Css
Html
cache-control no-cache no-store
nginx
Add_header cache-control “no-cache, no-store”;
add_header Cache-Control “s-maxage=864000, max-age=0”;
CDN Server ache validity and browser cache validity 0 seconds means no store.
for html it needs sere from the server. (because no user can read same html page with same content multiple times, even if you updated browser or proxy /cdn seres old page because its expiry set to high.)
2nd reason: browser cache storage space & its validity on users local hard disk. ( most browsers overrides the data if cache limits the space / storage).
Firefox has option to maximum browser cache space, 1GB. chrome it automatically uses available space.
for CSS .JS. Image you can set upto maximum 1 year.
Add cache control header htaccess apache
Header set Cache-Control “max-age=31536000, public”
</filesMatch>
Add cache control header in Nginx
location block for static
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires max;
}
add cahce control header for nginx wordpress sites
in wordpress html files are dynamically generated php, so put add_header or any http headers in php location block.
Cache control header for html files
etag on;
add_header Vary “Accept-Encoding, Cookie”;
add_header Cache-Control “no-cache, no-store, must-revalidate”;}
Last-Modified header
Remove Expires: Thu, 19 Nov 1981 PHP Header Nginx, Apache, Whatever with root Access
1 year = 525600 minutes
session.cache_expire = 525600