App router configuration incorrectly sets async tags instead of defer

[annez]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/angry-chaum-lrfdsw

To Reproduce

On sandbox

1. Devtools - async is on the <script> tags
2. Navigate to /test (pages)
3. Devtools - defer is on the <script> tags

On a repository

1. Create a new application (select app router)
2. Build the app npm run build
3. Run it npm start
4. Navigate to view:sourcehttp://localhost:3000
5. You can see that all tags are async=""

Current vs. Expected behavior

I believe this is a regression from the pages router which is not documented anywhere.

• Expected: All <script> tags should have the defer tag on them
• Current: <script> tags have the async tag on them

We've noticed a degradation in our time to render because now the async tag is being used which can block the main thread if its found by the browser first (see more: https://www.catchpoint.com/blog/new-render-blocking-indicator-in-chrome-and-webpagetest).

I don't think script tags in this case should be async and should be defer like before given that the browser will try and parse the javascript as its still rendering the page.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Wed Feb 21 21:44:43 PST 2024; root:xnu-10063.101.15~2/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.2.4 // Latest available version is detected (14.2.4).
  eslint-config-next: 14.2.4
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A

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

Performance, Script (next/script)

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

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

Additional context

No response

[gnoff]

Hi @annez

Regarding the issue reported and the repro you indicated this is a problem with next/script however the repro to my reading of it doesn't actually use next/script. Maybe I'm missing something. I do notice that the webpack runtime chunk for pages router arrives as a defer script whereas all the scripts are async in App Router. So I can't necessarily address the specific point you were trying to make with the issue but I will say that our use of async scripts in App Router is intentional.

With Streaming rendering App Router needs to become interactive before the entire DOM content has loaded so we need to be able to bootstrap the application while the Document is still being parsed. The special case of fully static pages could potentially be updated to switch scripts to defer since we know it that case the entire Document will be available immediately. However even here there may be some benefit to initiating hydration while the load is still occurring. The Document itself may not be cached while the script is and on a slow connection you can have interactivity before the entire page loads.

Going to close the issue because it behaves as designed. but feel free to engage here in the comments if you have further questions or statements to make.