HTTP cache is a fundamental and critical part of a web application, especially if the latter is able to serve fully rendered HTML pages.
App Router provides easier than ever SSR but seems so completely miss some of the other features critical for the purpose for which SSR is desired in the first place.

The problem

In a nutshell, the developer has no control over Last-Modified, Etag, and status code (i.e. 304) of a generated Page when using the App Router.

App Router fails to provide this functionality even in the simplest of scenarios:

• There is an API resource, say /api/v1/items/:id;
• There is a page /items/:id whose job is to provide UI on top of the API data and that does exactly one fetch to the API above;
• The page and the API resource can be considered in sync (the pages is simply another representation of the data)

The issues with App Router:

• Next.js opts the entire page into dynamic rendering because fetch depends on params, however dynamic rendering always returns 200 OK;
• Next.js forces Cache-Control: no-cache in the fetch request rendering any API-level CDN or caching completely useless.
• The developer can not implement HTTP caching manually by forwarding the headers because if fetch response is 304 there is not way to forward it to the client or render any data (there is no response body);
• The developer can not implement HTTP caching manually (without API-level caching) by a custom comparison of if-Modified-Since with the resource data (like updatedAt) because there is no way to set response status code to 304 or set Last-Modified (to be later received as if-Modified-Since) in the first place;
• The source of truth (API) can not set the TTL of the cache because revalidate is a static export, so is it as good has hard-coding it in the CDN instead of enjoying the flexibility of HTTP cache standards that have existed for decades.

The desired capabilities:

• Forward Etag of the primary API resource to the client and forward If-None-Match to the API (ETag is URL-scoped so this is perfectly fine if the page can be considered just a different representation of the API resource);
• Manually set If-None-Match in fetch requests when the page's ETag is deterministically derived from resource's ETag, such as having app version to invalidate layout changes without invalidating API-level chache;
• Forward the most recent Last-Modified among all the fetched resources to the client or set Last-Modified based on the application-specific property (updatedAt, editedAt, etc.) of a fetched resource; and forward If-Modified-Since from the client to the API;
• Set the response code to 304 if all fetched resources returned 304; or manually set the response code to 304 if the primary API resource returned 304; or set the response code to 304 manually upon a custom comparison of If-Modified-Since with the application-specific property (updatedAt, editedAt, etc.);
• Set the Cache-Control value based on the fetched resources (maxage of the fetched resource) or based on the request parameters (private if logged in, public is logged out, etc.).

Why Last-Modified, Etag, Cache-Control, and 304 Not Modified are important

Last-Modified is also used by crawlers to adjust crawl frequency, by browsers in heuristic caching, and by content management systems (CMS) to display the time the content was last modified.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified

Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. [...] the server may choose to return a 304 (Not Modified) HTTP status code with no response body, in which case Google will reuse the content version it crawled the last time. [...] you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn't changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.

Source: https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget

Note that the support of If-None-Match implies the support and use of Etag.

CloudFront caches 3xx responses according to the settings in your CloudFront distribution and the headers in the response.

If the CloudFront cache already has the latest version, the origin returns a status code 304 Not Modified.

Soure: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

There are zero mentions of these concerns in the documentation. Please keep in mind that the way Next.js handles fetch cache is a separate concern. It is either a server-side cache (orthogonal to HTTP cache) or affects fetch on the client-side when the app behaves like a Single-Page Application and not when requesting an entire page (like a crawler, a CDN, or the first visit in a user session).

This makes it nearly impossible to implement efficient caching strategies both for SEO or even having a simple CDN in front of a Next.js app.