Serve static assets with an efficient cache policy.

[pdpinch]

In the lighthouse report at https://foo-software-lighthouse-reports.s3.amazonaws.com/report-1649708748467.html the tool notes that we aren't setting cache headers for static assets. Since so many of the static assets are used across the site, we should encourage browsers to cache them.

URL	Cache TTL	Transfer Size
…js/course.f83ad.js(ocw.mit.edu)	None	251 KiB
…sts-471j-engineering-apollo-the-moon-project-as-a-complex-….jpg(ocw.mit.edu)	None	133 KiB
…js/main.f83ad.js(ocw.mit.edu)	None	98 KiB
…fonts/MaterialI….woff2(ocw.mit.edu)	None	80 KiB
/images/ocw_logo_white.png(ocw.mit.edu)	None	62 KiB
…css/main.f83ad.css(ocw.mit.edu)	None	38 KiB
…css/course.f83ad.css(ocw.mit.edu)	None	32 KiB
/images/mit-ol.png(ocw.mit.edu)	None	9 KiB
/images/oeg_logo.png(ocw.mit.edu)	None	7 KiB
/images/Twitter.png(ocw.mit.edu)	None	3 KiB
/images/LinkedIn.png(ocw.mit.edu)	None	3 KiB
/images/Instagram.png(ocw.mit.edu)	None	3 KiB
/images/Youtube.png(ocw.mit.edu)	None	2 KiB
/images/Facebook.png(ocw.mit.edu)	None	1 KiB

[ChristopherChudzicki]

I was reading a bit about this today. My understanding is that currently users do cache our resources, but they always check with the server before using the cache. If the server responds 304 ("Not modified"), then the cached resource is used. Otherwise a new one is fetched.

Our JS/CSS assetts, at least, include a hash, so we could set Cache-Control: Max-age to just use the memory cache right away.

Our images (like ocw logo) are not hashed, but probably should be, then they can skip to memory cache right away, too