Being a big fan of performance, I have looked into
cache-control: immutable. Unfortunately, this feature has very little- or no benefit in X3, and I don't think this feature will make it's way to the official X3
.htaccess file, which I want to keep at minimal. I like to write about these things, so let me explain from X3's perspective:
What does Immutable do?
Cache-Control "immutable", will tell the browser that a file cached in browser can be used instead of making new request to server. All good.
But doesn't existing cache-control already do this?
Yes, exactly. X3 already uses efficient cache-control headers, so that browsers will cache static images, javascript and css. When a visitor re-visits your website, cached assets will be served from their browser cache, thus making things load faster.
Then what's the point of immutable?
Sometimes, when visitor
reloads/refreshes a page (or certain other circumstances), browser will
re-validate a cached asset. This means it will send a request to server, check if the file changed (which it most likely didn't), and only
then serve the file from cache. You can read about this conditional process here:
http://stackoverflow.com/questions/2616 ... 0#26339940
Immutable was invented to notify browsers that
"this file will NEVER change, so don't even bother to re-validate it".
What's the general benefit?
Immutable was mainly invented for large websites like
Facebook or
BBC, where a visitor will often "refresh" the page to see new updates etc. Facebook serves 100+ tiny CSS/Javascript files on page load, which they obviously want to have cached in the browser. If the browser needs to re-validate all those files on page refresh, it will obviously slow things down. Read about this here:
https://code.facebook.com/posts/5571474 ... -facebook/
Why no benefit in X3?
- As pointed out above, immutable would only come into effect if visitor clicks to REFRESH page. This may have benefits for big websites like Facebook, who serve hundreds of tiny files, and when a visitor will often reload a page to view updates. However, this is not the case for a website like X3,
- Modern browsers are already dealing with page REFRESH without any "immutable" cache-control header (as they should). Chrome browser already deals with this automatically, and that is why they are reluctant to add support for immutable. Safari also wants to implement chrome-style reload behavior, making the "immutable" header entirely superfluous (non-beneficial).
- Only Firefox officially supports "immutable", see ref.
- X3 already caches files correctly, allowing browsers to use cached files when available under normal circumstances.
- Even if there was any benefit, X3 only loads a few CSS/javascript files ... These files are loaded from our Amazon CDN service anyway.
- In X3, it would ONLY benefit loading image files, ONLY if visitor clicks to REFRESH page and ONLY in Firefox (other browsers already deal with this properly).
Conclusion
Considering the above, for a website like X3, the immutable cache-control header is not worth the extra lines of code. I have however added the "immutable" cache-control header to images served from the X3 image-resizer, since it's done from PHP without having to pollute the .htaccess file.
If someone wants to add cache-control immutable to all static assets in X3, it can be added to the .htaccess:
# Immutable cache-control for static assets
<IfModule mod_headers.c>
<Files ~ "\.(jpe?g|png|gif|svg|mp3|mp4|json|css|js)$">
Header append Cache-Control "public, immutable"
</Files>
</IfModule>