Config to set cache control headers

[jonkafton]

What are the relevant tickets?

https://github.com/mitodl/hq/issues/5796

Description (What does it do?)

Next.js sets no-cache for any dynamically rendered pages, though we have taken the approach of ensuring all server rendered HTML is public and can be stored on shared caches.

This change overrides this behavior by setting cache headers explicitly for all of our routes.

How can this be tested?

Must be tested in Production mode.

Locally you should see Cache-Control: public, max-age=120 on all base HTML responses, but not on JS chunks, images or other static content.

Once deployed you should see CDN cache hits on subsequent requests (X-Cache header).

Additional Context

• This also upgrades Next.js to 14.2.15 so that we have this recent change in v14.2.10 Add ability to customize Cache-Control vercel/next.js#69802.

• Several routes are static rendered at build time (/about, /departments, /topics, /units, etc). Next.js gives these an s-maxage=31536000, though we're setting all to the same for consistency.

• This does also set the cache header on RSC payloads e.g. /?resource=6135&_rsc=1wtp7. This may cause issues.

• This only sets a short TTL of 120s - wanting to be cautious while we first test.

[ChristopherChudzicki]

My suggestion is mention RSC here, too.

Suggested change

	/* This is intended to target the base HTML responses. Some are dynamically rendered,
	* so Next.js instructs no-cache, however we are currently serving public content that
	* is cacheable. Excludes everything with a file extension so we're matching only on routes.
	*/
	/* This is intended to target the base HTML responses and streamed RSC
	* content. Some routes are dynamically rendered, so NextJS by default
	* sets no-cache. However we are currently serving public content that is
	* cacheable.
	*
	* Excludes everything with a file extension so we're matching only on routes.
	*/

[ChristopherChudzicki]

IMO both 120 and 600 could be much longer. Do you intend on increasing after testing?

Should we use s-maxage instead? My understanding is Fastly would respect that, but not browsers? (cc @blarghmatey ?)

[jonkafton]

IMO both 120 and 600 could be much longer. Do you intend on increasing after testing?

Yes. I want to test the behavior before and after cache expiry for comparison. We can cache the images indefinitely assuming the cache purge on release works as expected. For the HTML perhaps half the duration we consider an API response to be fresh - 12 hours?

Should we use s-maxage instead? My understanding is Fastly would respect that, but not browsers?

I've updated to s-maxage as you're correct - we're only trying to instruct the shared cache. It's not 100% clear whether browsers would cache responses marked as public, though it seems intended more to override shared cache behavior for authenticated requests and not to instruct browsers.