Your layout.js becomes two coordinated outputs — visible HTML for your eyes, and a growing array of serialized React the runtime replays.

This does not mean "Next copies this JSX into an HTML file." It means "Next will call this function during rendering, and the return value becomes part of a React tree."

In the App Router, app/layout.js is a special file. The top-most one is the root layout, and it must define the document-level <html> and <body> tags. Because you did not put "use client" at the top, this layout is a Server Component by default — layouts and pages render on the server, can be streamed, and only need Client Components when you require browser APIs, event handlers, state, or effects.

In your pasted HTML, that is why the final page contains Page rendered on <!-- -->6/22/2026, 9:53:29 PM.

So your final React tree is not just RootLayout. It is closer to RootLayout → children slot → LayoutRouter → Home page. That is why your output contains internal references you never wrote — they are App Router infrastructure that Next inserts around your route so it can support nested layouts, templates, loading states, errors, not-found pages, metadata, streaming, and client-side navigation:

Your layout says <body> {children} <footer>…</footer> </body>, and your page returns something like <main><h1>Hello Next!</h1></main>. So the render tree becomes a single nested structure:

So the direct transformation is just a function call whose children argument is your page, collapsed into flat markup:

Before anything Flight-specific, run the most ordinary JavaScript there is. Make an empty array. Push a couple of values. Log it. Nothing here is framework magic — push appends to the end and returns the new length; the array just grows.

Now the reveal: flip the toggle. The Next.js version is the same widget. Same empty array, same .push, same growth. Only two things changed — the array has an unusual name (self.__next_f), and the values you push are tagged tuples of serialized React instead of greetings.

The first Flight script on the page is always a bootstrap. It looks cryptic because it does two jobs at once: make sure the array exists, then push the first instruction into it. Tap each part below — the only genuinely interesting piece is || [], the guard that makes this line safe to run more than once and in any order.

Read expanded, the compact line is just an existence guard followed by a push:

Why guard with || [] at all? Because a streamed page is a pile of independent <script> tags — and a route can emit many of them. Any one might be the first to run, and every one after needs the array the first created. Watch four scripts arrive: the guard fires once, then every later script reuses the same queue.

The values flowing into the array are not bare strings. Each one is a two-element tuple: a number tag that says what kind of instruction this is, followed by its payload. The bootstrap pushes [0] — tag 0, no payload, meaning "initialize the reader." Almost everything after is [1, "…"] — tag 1, a string payload, meaning "here is more of the serialized model."

In the App Router, metadata is resolved on the server so it can be included in the initial HTML response. Even when you do not export custom metadata, Next still emits essential defaults like charset and viewport. The metadata system is why your Flight payload includes entries such as MetadataBoundary, ViewportBoundary, __next_metadata_boundary__, and __next_viewport_boundary__ — which eventually become the <meta charset> and <meta name="viewport"> tags in the head.

You wrote import "./styles.css"; Next sees that import in the root layout and treats it as a global app-level stylesheet. It is bundled and extracted to /_next/static/css/app/layout.css, then linked in <head> as a normal stylesheet the browser downloads. The ?v=1782158009762 suffix is a development-mode cache-busting timestamp that helps the browser get the newest stylesheet during dev.

Your output also has scripts that are not from your layout — they are the Next / React client runtime. Even though your RootLayout is a Server Component, the browser still needs some JavaScript so Next can hydrate Client Components, manage the App Router, process future navigations, and interpret the embedded RSC payload.

On the server, Server Components render into a special RSC payload, and that payload plus Client Component instructions are used to prerender HTML. So your response is not just HTML — it is an HTML shell + the RSC/Flight payload + router bootstrap data + client runtime scripts, interleaved on purpose. Read the raw bytes top to bottom and you see the rhythm: an HTML shell, then visible markup, then a Flight chunk, then more HTML, then another chunk, then a run of chunks.

Streaming the two together is what lets the page show pixels before the response finishes. As soon as the browser reaches a script, it runs it and stores the chunk — so it never waits for one giant JSON file at the end:

You will see anywhere from a couple to dozens. There is no fixed number — and crucially, it is not one per page, one per component, or one per Server Component. The count tracks something else entirely: how many Flight / RSC payload chunks Next decides to flush into this particular response.

Why more than one at all? Because the initial HTML response is streamed. Next does not wait for the whole route to finish before sending bytes — it sends the visible HTML preview early, then appends pieces of the RSC payload as they become available, each as its own inline <script> push. That is what lets a usable page paint while the hidden Flight data is still arriving alongside it.

So the precise statement: the number of push scripts is implementation- and route-dependent, with no public fixed maximum. It rises and falls with payload size, how many route segments and Suspense boundaries are involved, how much Server Component output exists, how many Client Component references are needed, how Next chooses to split and flush the stream, and even whether you are in dev or production and which Next version you are on.

They are not sprinkled at random. The response has three zones, and each script lands in the zone decided by when its data becomes available — which is exactly why the order you read on screen does not match the order in the file.

① The <head>, in the very first chunk. Before a single component has finished, Next emits the resource hints and the <script async src> bundle tags. The browser sees them immediately and starts downloading JavaScript, CSS, and fonts while the server is still rendering — fetching happens during server think-time, not after it.

② The <body> shell paints next. The static markup streams out, and every Suspense boundary is written as a fallback wrapped in comment markers: <!--$?--> (pending), an empty <template id="B:0"> slot, the skeleton UI, then <!--/$-->. The slot is a placeholder the browser can already paint around.

③ The streamed tail, in resolve order. When a boundary finishes on the server, three things are appended near the end of the body — wherever the byte stream happens to be: the resolved markup inside a <div hidden id="S:0">, a $RC("B:0","S:0") swap script, and a self.__next_f.push(...) carrying that boundary's RSC payload.

Past the __next_f.push lines, a Next.js document carries a few other <script> and <link> tags. Here is the whole cast, in four groups — the two that sit in the head, and the two that stream through the body.

① Resource hints are <link> tags, not scripts, but they drive script loading: preload and modulepreload tell the browser to start fetching a bundle before the tag that uses it appears; the stylesheet and font preloads do the same for CSS and fonts. They exist to overlap network time with server-render time.

② Bundle scripts are the real JavaScript, loaded with async. webpack-* is the module runtime; main-app-* boots React and the App Router client; app-pages-internals-* is the shared App Router runtime; the per-segment chunks (app/layout, app/page, and any shared [id] chunks) contain only your "use client" components; polyfills-* backfills older browsers and is skipped by modern ones. Together they hydrate the server-rendered HTML.

③ Flight data is the self.__next_f family you have been tracing: the bootstrap [0] that creates the queue, then [1, "…"] rows carrying the serialized element tree, props, and client-component references. Types 2 / 3 appear rarely, for internals like Server-Action metadata.

④ React streaming scripts are the DOM-surgery helpers: $RC swaps a resolved Suspense boundary into place, $RS moves a completed segment, and their function bodies are injected once the first time they are needed, then reused by id. These are React's, not Next's — Next layers the __next_f payload alongside them.

The string inside a [1, "…"] push is a sequence of rows separated by newlines. Each row is id:tag payload. Some rows are module references (a pointer to a client component's chunk — never the component's code), some are React elements written as arrays, and elements can point at other rows with a $L<id> reference. Tap a row to decode it and watch its references light up.

Mapped onto a real response, the records decode like this — a mix of rendered Server Components, serialized elements, module references, a CSS hint, and metadata:

The exact tokens like I, HL, D, $L6, $Y, $E(...) are React/Next implementation details, not public API. Conceptually:

You see records for boundaries and roots you never authored — because your app is not rendered as only RootLayout → Page. It is rendered inside Next's App Router machinery: the boundaries that make nested routing, streaming, errors, metadata, prefetching, and client navigation work.

So your real server render is closer to this — you only authored RootLayout, Home, and styles.css; Next wraps it in everything else:

At first, self.__next_f behaves like a normal array — chunks pile up because nobody is consuming them yet. Then Next's client runtime loads. Conceptually it reads what is buffered, then takes over push so later chunks are processed immediately instead of merely stored:

You now have the whole shape. These cards pin down each part precisely — what it is, why it is there, and the runtime-level or React-level fact underneath. Tap to open.

The pattern is most misunderstood in three specific ways. Each card states the wrong model and the right one.

Your RootLayout becomes the final HTML because Next calls it as a Server Component and turns its returned React element tree into server-rendered markup. But Next also embeds the Flight/RSC payload because HTML alone is not enough for the App Router — the browser also needs the serialized React tree, router state, module references, metadata boundaries, and Client Component references so React can reconcile the page and Next can perform client-side navigation.

Read as one line: self.__next_f.push(chunk) is array.push(chunk). The array is self.__next_f — a get-or-created queue, guarded by || [] so any script can be first. Each pushed item is [tag, data]: [0] boots the reader, [1, "…"] delivers rows of the model. The server braids those <script> pushes between chunks of visible HTML so the browser paints early. And when React's runtime loads, it drains the backlog and rewires push into a live pipe — so the stream that started as bytes ends as your running app.