Improve performance using `Cache-Control` headers for prototype kit assets

[Nooshu]

Off the back of the same conversation related to this issue, the prototype kit Cache-Control headers were examined and they are all Cache-Control: public, max-age=0.

max-age=0 forces most browsers to revalidate the asset sitting in the cache with a server before it can be used. This will be slowing rendering if the network conditions are poor, or on an older device. So we should update the header to be more long lived. In terms of for how long, that is TBD.

It should be possible setup Express to serve the right headers, although it’s tied into the kit’s ‘extensions’ system so it’s not trivial.

[joelanman]

we originally turned all caching off to make sure people working on their prototypes would never see the 'wrong' thing because of a caching issue somewhere. Might that happen here?

[edwardhorsford]

I'd hope / assume we could control caching of the html separate to assets - especially the font, which is highly unlikely to change.

[Nooshu]

Agreed, we should look at setting up headers different per type of resource and how often they change. Fonts, favicon, crest image etc are unlikely to change so they could have long life headers. jQuery will never change from a user perspective, and some of the other scripts may never change too. The HTML / CSS you may not want to even cache at all?

This post by Harry Roberts can offer us some guidance on which headers we could be using.

[joelanman]

now that production and dev modes are very separate this should be easier to do, we could also add compression to assets and any other performance features

[JonJMagee]

Related to #1931