This is a good point. The reason is that payloads are meant to support not just prerendering but also runtime generation if you are running a server. However, there's clearly a situation when we would want to use the CDN URL here. 🤔

Just to give some context:

My task in this context was actually to deploy a Nuxt rendered output, as static pages, to S3-based simple website hosting. These pages were error pages, that should be presented at the requested URL if the request resulted in an error. When I served the pages at the given URL, they would always fall into a "404 state", because the current URL wasn't in the routing of the application.

The first I learned, was that another developer used a ClientOnly node in the pages, because they thought it would be the right solution for another problem they faced. It was not the right solution, as we were aiming for fully static pages.

Once I fixed that, I noticed that the entire JS usage dropped to pretty much zero, and that these payloads also didn't seem to contain any really meaningful data.

So I went with the following configuration bits:

  experimental: {
    noScripts: true,
    payloadExtraction: false,
  },

The resulting pages were fully static HTML pages that I could serve from any host, or path. All other links in the document respected the cdnURL already through one mechanism or the other.

Sorry if any of the terminology is off. I'm in unknown territory here 😅

Thoughts @pi0?

I think we can implement once #21641 is merged.

@danielroe any news about implementation? I can help if you want :)