Cache static assets #7611
Cache static assets #7611
Conversation
By default Hapi sends cache-control: no-cache headers. Because we version our static assets anyway, setting a nice long max-age on these responses is a huge and easy performance win. I've set max-age to an arbitrary, large period of one year.
|
I don't think we can do this until we version the static assets by shasum instead of build number. Plugin installs will result in the bundles changing, and it's imperative that they not be cached as a result. |
|
Do you feel like users needing to CMD + SHIFT + R on those rare occasions when a plugin is installed is reason enough to degrade performance for the other 99.9% of the time? |
|
No, but I don't think this is a dichotomy. Using hashes is the right solution, so let's get that done and then we can tweak cache parameters all we want. I know the two are technically not the same issue, but users shouldn't have to care about technicalities. Caching is the issue here, so let's get the caching right. |
|
Alright, I'll take a crack at it. Generating fingerprints with webpack appears to be pretty trivial, the trick is just making sure it jives with all the idiosyncrasies of our build process. |
|
@Bargs Do you still plan to work on this? |
|
someday, I hope so... |
|
This is probably more appropriate for the platform team now |
|
Could you at least cache the |
By default Hapi sends cache-control: no-cache headers. Because we version our static assets anyway, setting a nice long max-age on these responses is a huge and easy performance win. I've set max-age to an arbitrary, large period of one year.
You'll need to test this in production mode, dev mode still sets cache-control: no-cache. I'm guessing that's due to the base path proxy overriding headers, as it is wont to do. But I think that's actually desirable for dev mode anyway.
Fixes #6520