X3Photo Gallery Forums

This is interesting, I will look more into it tomorrow. There is already a pending X3 release which has a lot of focus on improved caching mechanisms, and perhaps we can include "immutable".

In regards to immutable, I would have to point out the following:

• It's a bit "vague". Browsers should really have some native implementation of this based on standard cache-expire headers. Chrome doesn't actually support "immutable", but instead uses it's own methods, which I assume is based on standard cache headers [ref].
• In fact, only Firefox and Edge 15 supports immutable for now, and only on SSL (https) [ref]. Safari is testing it apparently, and Chrome may have adopted it, or are using their own methods.
• Of course, this can only be applied to STATIC assets like images, css and javascript. 
• Naturally, it would only benefit visitors who already have loaded and cached these assets into browser from before. Even without the "immutable" header, files will still cache, but sometimes the browser sends a request "check if this file has changed", which is what "immutable" tries to prevent.
• FYI "immutable" has no effect on how CDN servers will cache your assets.

Thanks for bringing it up. All for squeezing X3 performance to the max.

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: