Missing "Link" Header for Critical Resources in Production in Next.js 15

[stefa98]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/next-js-15-d55c3c

To Reproduce

1. Run the application in development mode (next dev).
2. Check the response headers: the Link header for critical resources (e.g., fonts, styles) is present.
3. Build the application for production (next build and next start) or deploy it to Vercel in preview or production mode.
4. In production, the Link header is missing.

Current vs. Expected behavior

• Current behavior:
  In development mode, the Link header correctly includes critical resources to preload, such as fonts and stylesheets. However, in production or preview (e.g., on Vercel), the Link header is not present, and resources are not preloaded in the same way.

• Expected behavior:
  The Link header should also be present in production mode, allowing the browser to preload critical resources and potentially enable optimizations like 103 Early Hints.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32547
  Available CPU cores: 20
Binaries:
  Node: 20.11.1
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.0.1 // Latest available version is detected (15.0.1).
  eslint-config-next: 15.0.1
  react: 19.0.0-rc-69d4b800-20241021
  react-dom: 19.0.0-rc-69d4b800-20241021
  typescript: 5.6.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Output (export/standalone), Performance

Which stage(s) are affected? (Select all that apply)

next build (local), next start (local), Vercel (Deployed)

Additional context

The problem also occurs with the default nextjs template, implemented with “npx create-next-app”

I believe I found the logic that handles critical resources in the Link header in the following file:

next.js/packages/next/src/compiled/react-dom-experimental/cjs/react-dom-server.node.production.js

Line 5723 in 51d6e76

linkHeader ? onHeaders({ Link: linkHeader }) : onHeaders({});

The function safelyEmitEarlyPreloads seems to generate the Link header correctly during rendering, but it doesn't appear to be emitted in production. Is there a new option or configuration that needs to be enabled to have these critical resources included in the Link header during production? This would be particularly useful for enabling 103 Early Hints.

Thank you for any insights!

[lubieowoce]

the sandbox URL wasn't detected because it was missing https://, reopening

[samcx]

@stefa98 Thank you for submitting an issue!

We are taking a look

[samcx]

@stefa98 I believe this was always the case (pre v15 stable release). Currently, you need to have PPR (canary only) enabled to see Link Headers in Production.

Not sure yet about the behavior in Development where it's showing without PPR enabled, so sharing this with the team!

[childrentime]

#36089 To be honest, I eagerly hope that Next.js can support this feature. The neighboring Nuxt.js (https://nuxt.com/docs/guide/going-further/experimental-features#writeearlyhints) has already supported it for a while.

[stefa98]

Hi @samcx

Is there any news. about it? It would be a great thing to implement “Link” Headers for Critical Resources. it is a standard now that is used by so many websites and allows for better performance. Also I don't think it is that complicated to implement, it would be very nice for the next release and besides it is an issue that has been presented for months by the community

[amitkoth]

Agreed. All that's needed is a proper HTML format, and something like Cloudflare Pages automatically emits Early Hints:
https://developers.cloudflare.com/pages/configuration/early-hints/#2-automatic-link-header-generation

[wyattjoh]

The browser can prioritize better when there are link tags present in the page versus the header. When the page is fully static, there's no time advantage to injecting the link headers. It's present in dev all the time because these pages are rendered dynamically each time, though we may be omitting that in future releases to make it more consistent.

When Partial Prerendering is enabled (via the ppr: true flag), we do emit the link headers because we sometimes may not be able to serve the link tags early, and as a result, there is a time advantage to sending the header.

Future work may enable the 103 early hints, but we don't have a timeline for that yet. (but stay tuned 🥳!)

TLDR; this is working as expected, so we're going to close this for now. I'll move this to a discussion so we can continue to receive feedback on this case.

[amitkoth]

I just wanted to re-iterate here in case of confusion - all that's needed is the actual HTML format to change on output, nothing else, and something like Cloudflare Pages already detects and emits early hints headers - even on static compilation:

https://developers.cloudflare.com/pages/configuration/early-hints/#2-automatic-link-header-generation

No need for server-side headers here at all - just wrap exactly what is currently being generated with the right markup

[samcx]

something like Cloudflare Pages already detects and emits early hints headers - even on static compilation:

@amitkoth To clarify, generating Link Headers for fully static pages offers no performance gains (the / page in the reproduction is a fully static page). In the case of Cloudflare, offering a framework-agnostic feature like this would make sense. But, in the case of Next.js, we can be smarter about this.

In the case of PPR, which can simultaneously serve a "static shell" of page alongside a dynamic area of the page, we can't assume a page is fully-static, so we always generate Link Headers.

[amitkoth]

@samcx some use cases will vary - but we only build static and it's hosted at Cloudflare Pages. This trivial change to the markup alone will be handled at their end, and they then emit early hints without anything else needed. Also - this is not about individual static assets, but the overall page all multiplexing as early hints.

The benefits are clearly explained here and are very substantial:
https://blog.cloudflare.com/early-hints-on-cloudflare-pages/
It was also in the ticket which got closed and pushed into this discussion

The change is just the HTML output - the build process does not change.

[samcx]

all that's needed is the actual HTML format to change on output, nothing else, and something like Cloudflare Pages already detects and emits early hints headers - even on static compilation:

From the Cloudflare docs →

In order to make the authoring experience easier, Pages also automatically generates Link headers from any HTML elements with the following attributes:

@amitkoth React and Next.js already generate the necessary <link> tags in the <head>, so I'm not sure what exact HTML output change you're referring to that would be needed. If you're using output: export in Cloudflare Pages, I would expect Cloudflare to automatically add Early Hints, according to their docs.

The benefits are clearly explained here and are very substantial:

The e-commerce example they use is not the equivalent of a fully-static Next.js page.

but these pricing and inventory values are being templated in live for every request with Pages Functions. To simulate loading from an external data-source (possibly backed by KV, Durable Objects, D1, or even an external API like Shopify) we've added a fixed delay before this data resolves.

I think the Chrome docs somewhat clarify this—essentially, a fully-static page will always immediately return a 200 status.

Note: Before going deep into the topic, note that Early Hints are not useful if your server can send a 200 (or other final responses) right away. Instead, consider using the regular preload or preconnect on the main response (using the Link HTTP header), or in the main response (using elements), in such situations. For cases where your server needs a little time to generate the main response, read on!

• https://developer.chrome.com/docs/web-platform/early-hints#how-to-use

[amitkoth]

Okay, thanks for this - let me take a look and ask our developer too

[amitkoth]

@samcx for more specific context - our website is https://tallyfy.com - which is built static and hosted on Cloudflare Pages, so that's what we want early hints format on

[childrentime]

In fact, this can also benefit users of the page router, as browsers can preload static resources without waiting for backend API calls to complete. @samcx