webcompat / webcompat.com

Source code for webcompat.com
https://webcompat.com
360 stars 191 forks source link

using Cache-control: immutable for some resources #2848

Open marimeireles opened 5 years ago

marimeireles commented 5 years ago

Karl sent me this article about cache control and there is a cool directive there that we're not using called immutable.

Currently we have these three files: webcompat.min.js?30eee9850c14f3be962f73e16c413fa2, untriaged.min.js?80af10d81a9f62e8dcd107a90dcde105, webcompat.min.css that could use immutable. This directive tells the browser that the file never changes, therefore the browser won't try to check for a newer version of the file. This is good for performance because this directive removes the latency of the back and forth requests to see if there is a new file available.

In all of the three files we use a long max-age directive max-age=9000000 which means we rarely (or more likely never) make the request to the server to check if there is a newer file available. We are essentially doing what this immutable directive is doing, we're just being more verbose. But according to this same article we shouldn't use things like style.css?hash because some servers erase everything after the "?" and that would break our currently cache policy:

A lot of proxy servers and CDNs will not cache anything with a query string either by configuration (e.g. from Cloudflare’s own documentation: "…a request for “style.css?something” will be normalised to just “style.css” when serving from the cache."), or defensively (the query string might contain information specific to one particular response)

I don't believe our server is erasing stuff after "?" because when we change the js or css files we see the changes immediately in the website so it's working as it should.

If @miketaylr is not thinking about changing our server provider I'd say we don't really need to worry with this and it's unnecessary to change our cache policy. But I'm not sure, maybe I'm missing something, what do you think @karlcow ?

Other than that I didn't find any optimization we could do at our cache policies. Thanks for the article Karl 🌟

karlcow commented 5 years ago

agreed with the two first propositions because they change with their cache-busting parameter, but the third one

webcompat.min.css that could use immutable

this is changing each time we update the CSS. And we need to refresh it. the max-age is here to tell the browser that it can keep it before doing a revalidation.

karlcow commented 5 years ago

@marimeireles I slightly tweaked the title so it's reflective of the proposal

marimeireles commented 5 years ago

So you think we should change the code to use immutable? Like, is this worthwhile?

karlcow commented 5 years ago

@marimeireles I'm not sure we would gain that much. On the other hand I can perfectly see the immutable applied to screenshot images uploaded on the issues. Because these will never change. Ever. They might disappear. but a URI for an image is here to stay. So yes on images that could be done. Putting immutable on something which has cache busting seems less necessary and in our context, not really necessary.