|Issue 611416||Implement Cache-Control: immutable|
|Starred by 72 users||Project Member Reported by firstname.lastname@example.org, May 12 2016||Back to list|
Cache-Control: immutable signals that a resource will never change and should never be validated if fresh. This should speed up reloads significantly, see https://bitsup.blogspot.com/2016/05/cache-control-immutable.html?m=1 for a bigger explanation.
May 12 2016,
See https://bugzilla.mozilla.org/show_bug.cgi?id=1267474 for the mozilla bug tracking their implementation.
Jul 5 2016,
Any progress or plans?
Firefox 49.0 now supports the immutable flag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#Browser_compatibility , it would be great if Chromium did too!
As a demonstration of interest, we're going to be trialling this on the BBC website (likely the UK home page initially) over the next few weeks. We'd love to see support in Chromium.
Re #4: Looking forward to see your test results.
I now have a small set of preliminary results, these are from a trial with one of our teams, scope is: Pages: UK home (https://www.bbc.co.uk/) and Travel (https://www.bbc.co.uk/travel) Assets tested: https://mybbc.files.bbci.co.uk/* Data source: CDN edge responses Firefox v49+ represents ~2% of our user base Measurement metric: % ratio of 304's on mybbc.files.bbci.co.uk for HTTP (immutable doesn't work) vs. HTTPS Duration: 3 weeks of data without immutable, 1 week with immutable (i'll update this in ~2 weeks) Result: ~10.8% reduction in 304's served once immutable is enabled Caveat: This is a small dataset on a small number of pages. Hopefully it's interesting in some way though. We're looking to expand the trial into more of our teams and we have seen no issues thus far, except that the CDN strips Cache-Control extensions currently in some configurations - I have a ticket open with them via which I am hoping to rectify that. Please let me know if you need more info, more than happy to provide whatever i can. Cheers
Also, i did some semi-scientific page reload tests in Fx 49 and saw: * Home page * 12.6% reduction in domLoaded time * 84.9% reduction in num requests to network * Travel home page * 47.6% improvement in domLoaded time * 89.1% reduction in num requests to network This was mean values over 5 test runs per page, outliers *not* removed, on my laptop over a min. 1Gb/s link to the internet. Hopefully that provides something of a guide on visible effects.
Hi, do we at least have some idea as to whether this is something you plan to proceed with? Trying to get a feel for whether this is going to remain a "Firefox-only" feature for the time being.
I'd also be very interested to know if there is any movement on this. I just ran a few more numbers, now that we have some more data and, as a set of ballpark figures, we're now seeing ~31% fewer 304's served from our CDN edge on a subset of our static assets (which have immutable enabled) - this is obviously the effect of *just* Firefox v49+ which is ~7% of our audience right now. Extending these numbers, this *could* translate into saving ~8Tn requests/month (totalling ~2.4TB/month, assuming a mean size of 323 Bytes/304) against our primary CDN - if all our pages were HTTPS, all UA's supported immutable and all our assets were immutable. The truth is somewhere underneath that of course but it's a steer. For ref, Chrome is ~36% of all UA's for us, Safari (mainly mobile/tablet) is ~28%, IE/Edge combined ~15% so Chrome would be a big win for us and I assume that Chrome implementing would have a positive impact on the Safari an MSFT teams decision on whether/not to implement.
Oh, and if you are interested in seeing immutable in action, have a look at a BBC HTTPS web page e.g. (some of these may be UK only) https://www.bbc.com/account (should work anywhere in the world) or https://www.bbc.co.uk/ or https://www.bbc.co.uk/travel (there are others elsewhere, especially if you;re signed in).
We will soon start sending this for immutable responses from various large Google properties.
Chrome no longer forces validation on reload, so immutable shouldn't be necessary.
To add to #12, we might consider implementing Immutable if the following conditions are met: 1. there are substantial remaining opportunities 2. and they can only be addressed by adding this new API. In other words, what we are looking for: 1. data showing that there is a significant volume of resources that are inadequately validated (e.g. validation requests for still fresh resources). 2. lack of option to fix this on the Chrome side. Note: we have some following follow-up work that will further improve the situation: location.reload, reload behavior on offline error pages, etc. See the meta bug for more details: issue 612701.
WRT above - @email@example.com, please could you clarify which Chrome version(s)/dates i should look for in our stats to determine whether we have significant numbers of 304's which are unnecessary - i have log data i can get hold of from our CDN traffic. We should have enough traffic to validate with reasonable accuracy. Cheers
The main change has been live since Chrome 54. There should be a noticeable drop of 304 when comparing Chrome 53- to 54+. +toyoshim to provide more details about the additional changes: summary, status, launch plan.
Page reloads that are initiated by window.location.reload() still result in 304s. Is this intentional? Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36
see issue 670237 for details, but in short, I'm a running separate field study to change the location.reload behavior. M57 should have a chrome://flags to enable it explicitly, and 50% users in Canary/Dev should have the feature enabled.
Has been implemented also in WebKit https://bugs.webkit.org/show_bug.cgi?id=167497 Spec draft https://tools.ietf.org/html/draft-mcmanus-immutable-00
Great to hear immutable will hit Webkit - does this mean it'll make it to Desktop *and* mobile? Safari (mobile and desktop) constitutes a little under 30% of our audience so i'd love to get immutable for both :-)
Re #19, that's a question for Apple :) I'm still not seeing the value of immutable given the new reload behavior. Am I missing something?
Why am I banned?
Re #21, Well it's not just for reloading a page, it also affects opening a new tab. Since the assets are immutable chrome would never have to (try-)fetch the assets again. This would result in not only a refresh being faster but also a load without refresh. If the new reload behaviour works in a similar way then immutable would indeed not be needed but I guess the new behaviour only works for a refresh of a already open page?
For reference, Chrome's behavior is lightly described at: https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html When a user presses reload, Chrome will "only validate the main resource and continue with a regular page load."
just in case the value of immutable is not understood * its deterministic * it applies to things other than subresources (i.e. xhr revalidations can become cache hits) * There are resources that are fresh but not current - immutable lets you disambiguate between them. I think its fine to apply heuristics as you've done, but it would be better to also accept immutable as input in cases where you were about to do the revalidation anyhow (xhr?)
Does anyone have data to show how immutable can improve performance for e.g, top 100 sites? If other browsers can have such data, that would help us to consider to implement this. I put Holist-Interop just in case, but this won't cause user-visible compatibility issues.
firstname.lastname@example.org - My simplistic and small sample-set data above gives an idea for BBC web pages: https://bugs.chromium.org/p/chromium/issues/detail?id=611416#c6 https://bugs.chromium.org/p/chromium/issues/detail?id=611416#c7 Based on our data, we have another team deploying immutable tomorrow for their assets and another have lined it up for a subsequent release. I'd very much like to see the browsers adopt immutable as a standard methodology, as Patrick says, perhaps on top of other heuristics - so we know we can rely on it.
Oh, sorry I overlooked them. Chrome rolled out new reload behavior after you took that data. So if you can gather similar data again and can get another data for new sites, that helps us very much!
email@example.com - i'm happy to run some more tests, are you looking for a comparison between Firefox/immutable and Chrome/new behaviour?
firstname.lastname@example.org -Ah sorry, i think i see what you are asking for - stats from our CDN on the reduction in 304's pre/post Chrome reload behaviour change. I'll get that as soon as i can and feed back here. Let me know if i misunderstood :-)
FF/immutable vs Chrome/old vs Chrome/new would be nice if possible. Furtunately, Chrome 56 still have a flag to manage reload behavior via flag. chrome://flags/#enable-non-validating-reload-on-normal-reload This may be useful for such comparison, but this flag was already removed in later versions. Our expectation is new reload achieves similar performance gain as FF can do with immutable.
email@example.com - OK, leave that with me and i will get the data as soon as i have a chance. I expect (from a little testing i did with Chrome) that you're right though as a user, i agree with Patrick that it would be very helpful to have a level baseline we can rely on i.e. all browsers implementing immutable as a final step.
Kenji, it sounds like this issue is being worked on. If it has been triaged, could you please change the status appropriately?
It's untriaged in the sense that we haven't made a firm decision yet. We are asking for data to show that it's still beneficial despite the changes we did to Reload (adding needs feedback). Let me know if this is not the right way to do this.
Network bug triager here. Friendly ping, neil.craig.bbc@ just a reminder to provide the data requested.
Sorry for the delay, heavy workload at the mo. I'll try to get the data next week and post here.
OK, apologies again for the delay - it's a worthy cause though, i've been TLS'ing and H2'ing all the things :-) I just ran a few tests against our UK home page beta (https://www.bbc.co.uk/home/five/beta) with firefox 52 and chrome 56 (OSX), using OSX network link conditioner in 3G mode (downstream: 780Kbps, 0% loss, 100ms latency, upstream: 330Kbps, 0% loss, 100ms latency). Mean value of 5 page loads after initial cache priming, times are @ domContentLoaded: Chrome: Reload optimisation heuristics enabled: 2.5 sec Reload optimisation heuristics disabled: 4.2 sec Thus heuristics make it ~40% faster Firefox: Regular reload (i.e. using immutable): 1.9 sec Hard reload (i.e. bypassing immutable): 4.8 sec Thus immutable make it ~60% faster I realise there's a ton of nuance/detail here but it seems like immutable might well provide a reasonable chunk of benefit over and above the Chrome heuristics. This confirms my agreement with Patrick. It's tricky to get CDN stats for the number of 304's pre/post change as i'd have to have logs from pre the change which i don't unfortunately. Is that what you need or is there anything else?
Mar 21 (4 days ago),
Is it possible to investigate what kinds of additional network requests Chrome makes on reloads? I expect all resources except for the main html file can be served by disk cache even without immutable support if everything are setup correctly. I'm afraid that Chrome unexpectedly make network requests against files under specific conditions.
Mar 21 (4 days ago),
+1 to Toyoshim's request. We can't really conclude from the A/B above that adding support for immutable to Chrome would bring the improvement from 40% to 60%. Ignoring non-warranted sub-resource validation/requests, the case where immutable would help is when the asset has become stale. I believe that this should be rare because these assets should use max-age: 1 year (maximum value). But I could be missing something.
|► Sign in to add a comment|