NEXTJS 13: self.__next_f.push

[dejurin]

I want to write right away that I have begin work with nextjs since version 12.

Hello, somebody knows what is it self.__next_f.push in source code.
self.__next_f.push double all content on webpage. Thus, the page becomes almost twice as large.

I have not seen this in version 12.

[more-by-more]

We're seeing these issue as well. Noticed our bandwidth usage on Vercel jumped by factor because of this. Switching to the /pages directory saw this usage drop to the expected level.

Looks to be serialised RSC data, but deleting it from the generated HTML file doesn't cause any issues. @leerob Are you able to offer any insight here? Understand /app isn't stable yet, but haven't seen this raised in the roadmap and currently stands (for us at least!) as the biggest issue for adopting /app dir for larger projects.

[lindesvard]

I noticed this today as well...

Using next 13.3.1 and all pages use SSG.

Tried cleaning up the script tags containing self.__next_f.push but that broke all the JS logic. So I guess it works to remove the script tags if you only have a static site without any js logic.

I really hope this is not needed (obviously it is needed now) in the long run.

[shuding]

This is expected and currently needed by React to "resume" the Server Component tree. In pages/, the duplicate content exists in JavaScript files too so React can hydrate.

You can read about Dan's thoughts on that here:

We need to add a capability in React to "skip" specially marked Flight text and keep using the one already in the DOM, thereby letting us deduplicate it.

vercel/next-react-server-components#13 (comment)

[kristijorgji]

It is expected but it has bad performance impact.

Is there any update on this or you recommend us to use the page router to avoid self.push duplicate html.
At least with page routes we got only the json into next data that is required for hydration and pages were not as huge as with the app router.

I also don't understand why is self.push putting the entire html for a server component. Such component does not have any interaction and maybe can be rendered only server-side like in old-school php and other blogs(Wordpress which still to nowadays is fantastic because does neither inject self html duplicate nor unedeed hydration data and keeps file size small)

[more-by-more]

Thanks for getting back here @shuding! That makes total sense re: being required to resume the RSC tree. I must have been at the end of the tree in my example, which is why removing that data had no effect.

Understand as well that the existing /pages directory has double up here too, however the sticking point for us on this one is that the size of the generated files from an ISR page under /app was much larger than that of the /pages output with ISR. This means the RSC approach incurs a higher bandwidth cost (on a cache miss) with hosts like Vercel when compared with the /pages directory. This seems a little counter intuitive at first glance as the RSC approach will result in sending less to the client.

For context, we've had to switch a project back to /pages mid-point here as the scale of the project and heavy usage of ISR tipped our approach in favour of not using RSC which is a shame! Totally understand everything is in flux here, but would be great to know if there are thoughts / awareness around the cost increase for the ISR & RSC combination, and if this is something that might be addressed in the future.

[kunalhdworks]

i get this thing in page source and its also render at homepage but if i reload page its comes actual design comes and then the and homepage also load its real render html

[kristijorgji]

Hi all,

do we have any update on this ?

Only this single particular issue makes app routing and React server components not usable.

I converted a blog to Next13 App Routing and size of page doubled.
With pages routing the json for hydration was injection, but was not so huge as the duplicate html injected in self.__next

[daneduijnkerke]

Would like an update on this. My pages are twice as big now. Is there a fix?

[kristijorgji]

Same. This is making NextJS unusable right now.
Especially for pages that have seo consideration they get sinked down in the bottom due to the huge size.

I migrated my NextJS blog/site to old-school rendering in server side with react natively without next and without any hydration (as was not needed for simple blog posts, that are in react 18 terms server components)

I do hope that NextJS solves this issue then will be a perfect framework with so much out of the box features.
And this is a huge blocker for real business projects where 10% seo difference means millions of $

[kristijorgji]

To be honest I am surprised that so few people ask about this issue. I guess most other users never check what is returned by their server or build pet projects

[hynpzo]

I kinda found a solution to this problem (it's more of a hack, but it does the job).
By overloading _documents.tsx, you can manage to remove the scripts you don't want.
I made a gist if you ever want to use it

[christiankaindl]

@hynpzo this discussion is about App Router, so _document.tsx is not relevant here.

[zhivulinal]

Is the issue not resolved yet?

[kunalhdworks]

if you facing chunk error problem on website then switch to SST in place of amplify
in your page source you will still see that chunk but it wont breaK YOUR PAGE

[shuding]

Inside Next.js, we are looking at ways to optimize the inlined payload (for example #52028). However, as I already mentioned above:

We need to add a capability in React to "skip" specially marked Flight text and keep using the one already in the DOM, thereby letting us deduplicate it.

vercel/next-react-server-components#13 (comment)

This is mainly something that needs to be implemented into React. That said, we will be working closely with the React core team to explore that idea.

[lucgagan]

@shuding Could you not load it outside of HTML? i.e. with a Fetch call after the page loads.

[Kein1945]

Just to vote up. Will wait fix of that behaviour, because only this one stops us to use Next.js for our production. We hardly working on performance score, and having duplicate data will increase our page weight.

[christiankaindl]

This is definitely an issue for us as well. The more Server Components are used, the larger the payload becomes (kind of ironic?). In our case the RSC payload is also significantly larger than the previous JSON payload from getStaticProps(). It seems this is because it is does not duplicate the JSON data itself (as getStaticProps() did), but rather all the HTML elements and attributes (classNames, etc.) are "duplicated" in the RSC payload.

We recently transitioned to app router and are struggling with the increased page sizes (on Vercel there is a 4.5MB limit on page response size). We render as much as possible using Server Components, and the RSC payload is often over 40-50% of the total HTML page size, which for large pages is a lot of overhad. Additionally, pages are routinely 30% larger than their previous pages directory counterpart (after optimizing everything I could; Removing duplication, classNames, attributes, etc.).

This is just one example, but it affects all pages. The larger the page, the more noticeable it becomes.

[christiankaindl]

That's a good point, I hadn't thought about this. Did a quick and dirty experiment with both versions of the site from the screenshot above, compressed with gzip and brotli algorithms (I used this site for the compressing). Even with compression, the pages dir version is quite significantly smaller than the RSC version. Brotli is definitely better than gzip, but there's still a difference of almost 20%.

In the "RSC payload manually removed" version I stripped out the RSC payload to see what the "ideal" would be (a.k.a. no content duplication at all):

Compression Algorithm / version	App dir (RSC)	Pages dir	App dir, with RSC payload manually removed
No compression	3.4MB	2.4MB	1.9MB
gzip	649.9KB	382.4KB	320.6KB
brotli	314.0KB	263.2KB	227.1KB

What this doesn't show is the additional JavaScript overhead of parsing and executing 1MB of extra code (I don't know how much overhead this creates). Also keep in mind that the HTML markup from the RSC version in this example is even a bit more optimized, as I already tried to remove as much "unnecessary" DOM elements, classNames, attributes etc. as I could to reduce file size.

The source files are attached, if anyone wants to double-check, they were saved via Firefox' "Save page as..." feature next-comparison.zip

[rajington]

Nice, thanks for digging into it. Yeah, seems like hydrating from HTML would require a React improvement, but then I wonder if hydrating from HTML might have even more of that overhead (parsing XML) is slower than reading JSON. I don't know much about that level of performance optimization, something I definitely would love, but not willing to move to HTMX or something for.

[christiankaindl]

Yeah I also don't know the answer to those questions, maybe the current solution is the right tradeoff. I just think having all HTML basically duplicated via the RSC payload is not what most people expect when they think of Server Components—also because one of it's main "marketing" selling point is "zero bundle size components". In reality it seems that you are trading JavaScript bundle size for RSC payload size to some degree.

Would also be interesting if others could post their compression results, maybe your results are different than what my (limited) testing suggests :)

[rajington]

I guess it depends on what is being used to generate the state on the server vs the amount of data hydration. In most of our cases (not just a simple fetch call) just being able to send the resulting state should be way orders of magnitude smaller.

Some of the stuff like db access in RSC code is a little bit too much for me, but native React support for "getInitialProps" at the component level feels like it should be an overall win for performance in most cases.

[gnoff]

@christiankaindl I wrote up a more comprehensive explanation of why Next (and React) does what it does here: #42170 (comment)

There isn't much cost at all to parsing these script tags. It's doing very little work in the script itself. Essentially just pushing a string into an array. This is different than parsing the same sized of javascript that is a real program because there is no real syntactic analysis that needs to be done. Basically the idea that these script tags is equivalently slow to fetching a tranditional JS bundle just really isn't realistic.

We could use a JSON script tag because at the end of the day we're really just doing data delivery. However the JSONP style loading has some nice advantages so we use an actual script tag instead. We could also base64 encode this as strings but that would inflate the byte size further so we don't.

In reality it seems that you are trading JavaScript bundle size for RSC payload size to some degree.

Absolutely this is true, but the key thing here is that these bytes aren't equivalent. You can't just look at total size and say bigger is worse.

[geoffrey-tan]

This makes my CSP fail, is there a good way to get a nonce on these scripts?

[dan91x]

@leerob hi, my CSP fail too, but we are using static export ( output:'export', ) .. we are trying to avoid script-src 'unsafe-inline'... there is a way??

[taheramr]

+1, how can we use output export and make CSP work for unsafe-inline? this is really critical and I don't understand why NextJS does not provide support for fully SSG apps to have proper CSP out of the box

[roman-antl-satoshilabs]

@leerob That link is good, but we're using static pages on CDN so we're not using any server. We're also putting the <meta http-equiv ... /> CSP meta tag inside the page instead using middleware, because make static pages dynamic.

Can you please give me a hint how to provide a nonce for these inline-scripts self.__next_f.push ?

[ReesMorris]

@leerob Is there any configuration to have the self.__next_f.push scripts extracted from the HTML and instead within their own .js files when using SSG? This would allow for script-src 'self' directives to work without needing to worry about nonces.

Our application isn't a static website, but we don't want to lose the performance benefits of revalidation by forcing the whole app to be dynamically rendered every page load.

[matthewjamesadam]

I have just run into this issue while trying to build a statically-exported site -- as far as I can tell, the only way to get such a site working is to allow unsafe-inline, which is not great. Writing the helper self.__next_f.push stuff into a separate file would definitely help with this.

[mwmwmw]

This seems to have gotten much worse in 14. We're seeing ~450 <script> tags with self.__next_f.push data. Can anyone else confirm?

[yassinebridi]

Can confirm, the performance is taking a big hit because of that, and we spent so much time migrating to the new app directory

[irmakcosarsahna]

Yes, we did too and we were disappointed.

[mwmwmw]

It's this function. I thought maybe it was a configuration or way we were handling requests. I tried to walk back through to see what is causing it to go bananas.

next.js/packages/next/src/server/app-render/use-flight-response.tsx

Line 87 in 6f8c580

.pipeThrough(createFlightTransformer(nonce, formState))

[regenthor]

I have just noticed this situation and stopped the build that was going into production. We need to resolve this as soon as possible, as it weakens the project in every way. Does anyone have a solution? Wishing for a quick resolution :( @mwmwmw @wbinnssmith

[andretti1977]

I'm rather disappointed: i'm implementing a new project using Nextjs 13 app router and it took a lot to me to study and understand the app router and i'm facing so many problems. Now i'm having a look at the html generated code and i can't find any trace of the html page structure in the body tag: just an incredible amount of self.__next_f.push functions and i can't understand why.
I'm seriously thinking of going back to pages router which was battle tested, working as expected and definitely simple to understand.
Anyhow does somebody knows why all the body's html has been stripped out?

[m1daz]

Don't know if this applies here too but I haven't even gotten to take a lot of advantage of RSC yet and as soon as I migrated from pages -> app router, my codebase saw pages have their filesize triple or even multiply by 5 times (110kb -> 620kb).

Even after lazy loading almost my entire damn application, and doing my best to minimize imports, I have gotten all filesizes back down to 110kb, yet now I have lost 15 performance score on lighthouse from 99 -> 85. Almost as if I was using npm run dev previously.

I'm a solo developer on a huge project with over 100,000 lines of code in the codebase and this is affecting performance and stability of the site greatly. Spent almost 12 hours minifying and migrating pages to app router only for it to barely get even close to pages router performance.

[jmantonellini]

Please solve this issue.. it's affecting our app performance as well.

[wjljack]

pure static html (without client component and interaction) do not need rsc payload, like generateMetadata,current both html meta and self._next_f.push has meta data,need remove meta in rsc payload

[apiel]

What we could argue then is what the point to use React for this kind of application?

[wjljack]

except meta,other region are dynamic,with react components

[apiel]

aah ok, got it 😅 this was not clear to me from you comment. But yeah, you have a point.

[apiel]

In general, I am bit mixed up about this thread. There is definitely an issue with the amount of duplicated data but this is not an issue of NextJs but because of React! However, there is for sure an issue in the way NextJs bundle the JavaScript. Having the JavaScript specific to the page being part to the html page might be ok, I assumed that we can save payload like this... However, there is a big issue about caching with the content that is common to all pages. Why is the JavaScript of the layout part of the same file?!! We have a separate file called layout.tsx, this is a naming convention coming from NextJs, it would be therefor very easy to extract it in a separate file to be able to cache this common part!! I can understand that making smart JavaScript loading is maybe not easy, but extracting common layout content is trivial to do and crucial for SEO and UX!

[mwmwmw]

If NextJS is a framework for making places to visit on the web (apps, sites, etc) and the page speed is considerably worse than other frameworks used to make websites, it's a problem.

Your NextJS website currently has a first-page-load speed penalty. Simple as that.

E-commerce experiences rely heavily on SEO-able content, fast loading times AND reactivity. Speed is of the utmost importance. In the case of e-commerce you have to treat every page load as an intent to buy, which means you need as little as possible in the way of doing that, milliseconds count. Customers whose e-commerce sites are built using Next complain the most.

It's a little disingenuous to simply handwave away A CORE WEB VITAL STATISTIC as irrelevant because that isn't what Next is for.

If Next is dropping support for core web vitals, they should say so. If Next doesn't want to support people building e-commerce solutions, they should remove those examples from the showcase.

There is a little ad on the Vercel site saying "NextJs Commerce!" that 100% means this is what Next js is for.

This is Next own demo

I don't see what the confusion is about.

[leerob]

You are looking at lab data, which could be affected by your extensions: https://vercel.com/blog/how-core-web-vitals-affect-seo

The TTFB is still slower than what I'd like, and we're improving that with Partial Prerendering here: vercel/commerce#1236

[mwmwmw]

I understand, but the performance of that page is not the issue at hand. It's just a simulated benchmark yes. But we can still use that benchmark to see the impact of additions while in development and before aggregate data has piled up. It's not useless. It's a smoke test. We know the live site, a real build is always going to perform a bit better. Then tag manager comes along and steals all that you gained (so I need headroom in the system to account for that eventuality).

I also believe CWV doesn't always translate into a true representation of the experience. but it's the measurement we have.

If a simulated 80 is a live 100, does a local 29 turn into a 49?

I don't blame Next generally, but I do have to work with the Next system and try to figure out how to make Next deliver a page score that isn't 49 with a TBT of 3 seconds.

So we go looking and all end up in this thread where we're like, hey perf is kinda bad, what do we do? Is there any way I can control what data is sent to the client? It doesn't need to be everything. My HTML doesn't need 4 megs of state.

You're still getting 80 out of the box. This is just FCP killing the page score, a pretty easy fix.

But the problem a lot of people (us, others in this thread) are having is massive TBT, and that is proving to be a little bit more difficult to track down.

Could it be the 100 script tags and strings being evaluated? How can I control this behavior? Can I shut it off momentarily to see if my TBT improves?

[gnoff]

If you are doing a dynamic render the TBT will largely be dominated by the data loading you do above Suspense boundaries. Some projects don't want any Skeleton UI and prefer the initial paint to be complete and if data loading takes some time the TBT will be higher. If you move some of this data loading beneath a Suspense boundary then the TBT will come down and you will see the loading state earlier.

If you want to make data loading faster you can cache it with unstable_cache() or not opting out of caching of fetches with { cache: 'no-store' }.

[daniel-koudouna]

We are facing the same problem after migrating a large chunk of our components into static components. A major pain point for us is the duplication of large parts of the page. An example in our case is our footer being duplicated into __next_f in a more verbose format than the original html, ( i.e ["$","div",null,{"className": ... even when it has no interactivity! We are concerned that bloating our HTML with this will affect SEO, particularly the abysmal HTML-to-text ratio after most of our text is duplicated inside script tags.

I think an option to have the rsc payload delivered like it happens in adjacent pages (i.e requesting /url?_rsc=hash ) would be welcome. This way, the initial HTML is not bloated. What are the downsides of this approach?

In a more broad context, how is the best way to render HTML with no interactivity? I would have thought RSC would be the best, or am I missing something from the mental model?

[gnoff]

I wrote up why we use the approach we do here: #42170 (comment)

If you have repeated static html components that render many times it could possibly be better to have that be a client component rather than a server component. If you render it only once then generally a server component is going to be better. I address in my comment why requesting the RSC response separately is not ideal

[damian-balas]

For me the <script></script> takes 90% of the HTML. This is what I get after I do a simple console.log

Is there anything I can do about it?

So many <script></script> characters are unnecessary kb.

[omerman]

I agree. Im really not sure why it's not a priority. I'd much rather see this solved than the "PPR" feature being stable

[gnoff]

Is your site public? Can I check it out?

[damian-balas]

@gnoff I'll ask my team if I can give you access. I'll send you an email as soon as I'll get their consent :)

Thanks!

[chrisneven]

Please keep us posted as well @damian-balas @gnoff

[DoIevenLift]

Hi all,

I know the discussion topic has been 'closed' and that the majority of the conversation here is surrounding webpage build size etc.

I am wondering if the display of raw information inside the self.__next_f.push is a security concern? Let's assume you have sensitive information that you need to display on the client, if this is 'streamed' into the client is there any possibility for sniffers etc to grab that information out of as it is streaming?

If this isn't the best place to ask / if its reopened the topic, my bad. Point me in the right direction.

Thanks!

[gnoff]

@DoIevenLift it's an unfortunate reality that anything sent to the browser must be treated as not-secret. If you have an authed website you are exposing sensitive information to the end user who has validated their ability to see this information but there is nothing that can stop that user from exfiltrating the data (copy & past, screenshot etc...). While you may not visually render all the data sent to the client you should not rely on any browser hiding measures in the browser to try to prevent the user from accessing information. If the info is too sensitive to send to the browser then it must stay on the server. This is not anything inherent to RSC or Next.js or even React, it's just a principle of any Web Application security

[IlirEdis]

uh-oh, i almost got fired and started questioning my dev career trying to get, at least, some optimal CWV score and not succeeding with a not so heavy app!
After all that work migrating from pages router and styled components to app router and tailwind, convinced that the score will improve for sure, i see this 😁 :

The funny thing is that the chunk of data that we see in the screenshot, doesn't belong to this page but i need that in another page.
C'mon guys, save my career 😁

[gnoff]

We can probably clean the script tags up after we consume them. Of those 2473 elements how many are script tags?

Also that warning is a heuristic b/c more dom nodes can slow things down but script tags have no visual representation so while the heuristic more nodes is worse than fewer not all nodes have the same consequence for performance. For instance there really isn't a style recalc cost for these script nodes

This is the risk of using something like lighthouse which is well intentioned but can drive you to incorrect decision making. CWV is useful because we know it is being used by google

[IlirEdis]

Hi @gnoff ,
I appreciate your effort for clarifying this to us!
I'm reading (and re-reading) all your comments here.

Regarding my data, i don't have parallel routes but i had something in my query fetching without knowing that i still have it there. After removing it, the amount of script tags decreased and the CWV overall score increased a bit. 🥳

So we have to be very careful with the data flow.

While investigating the same component, i noticed something interesting.

Now this is my component:

and the data coming here is of this shape:

... and the countriesArray array looks like this:

So this is not a lot of data and i use the slug to link to a dynamic route for each country.

BUT in production (NOT in development mode), in whichever page i am rendering this component, when i go to the network tab i see these files rendered for each country and they have data from the actual dynamic respective route, without even visiting that route:

For example this one has 723 lines of data and its load time is pretty large (1.2s):

... and i think this might be the reason behind my high TBT.

What do you think?

[IlirEdis]

Probably related to #59167

[gnoff]

@IlirEdis those are link prefetches. Next.js will prefetch <Link href="..." /> by default (set prefetch={false} to disable)

One way Next.js provides a fast navigation experience is to prefetch links on the page so when the link is clicked there is an instant state to render. If the prefetch was complete (b/c the page was statically built for instance) then the navigation is instant. If the prefetch was incomplete (b/c the page was not statically built) then the page contents up to the first loading.js will be returned. The idea here is that you can use loading.js to implement an instant-loading-state and then a full page load is requested. This allows for immediate visual feedback while rendering a dynamic page to get realtime content.

Based on your screenshot it seems you either have a very deep loading.js file so a lot of layout content is included. Or you have a statically built page so the entire link payload is available to the prefetch.

The router should be deprioritizing the prefetch calls to avoid blocking initial render resource loading. I'd be very interested to know if that was not happening. One thing you can try is adding prefetch={false} to every link on that page and seeing if it affects the TBT.

[IlirEdis]

Ah, i forgot about prefetch since now its automatic and enabled by default.
I'm not 100% sure since i'm getting different results, sometimes even without disabling prefetch but it seems it is affecting the TBT.
(I tested this on desktop since i don't render that component with the links on mobile)

with prefetch enabled:

with prefetch disabled:

I also found this: GoogleChrome/lighthouse#15351

[Kein1945]

We wanted to migrate to NextJS, but after I've seen that, we decided to postpone that decision. For our product CWV is absolutely important, so I'm waiting fix of duplicating data until we will be ready to migrate to NextJS.
Imagine if you main content of page is text of article. Is there any reason duplicate the text for hydration purpose at the expense of speed?
Same time I undertand that props tranfsormation can be irreversible.
Maybe good decision to prevent some components from hydration. But this decision is related to React dev team.

[gnoff]

Hi @Kein1945 see me explanation here: #42170 (comment)

I address why CWV isn't affected negatively by inlining the initial data for the page at the end of the HTML document.

[omerman]

Every new comment from a new person here makes me a little happier because I hope this issue will soon get the attention it deserves 😅

[LubomirGeorgiev]

@leerob Is this some kind of React limitation or design decision that it needs __next_f.push in order to hydrate the content for static HTML or it could be potentially fixed in Next.js without making any upstream changes to React.

[christiankaindl]

It's a React limitation in the hydration mechanism and would need to be fixed there. See this comment and the link it cites #42170 (comment)

We need to add a capability in React to "skip" specially marked Flight text and keep using the one already in the DOM, thereby letting us deduplicate it.

vercel/next-react-server-components#13 (comment)

[omerman]

Vercel pretty much decides what is a priority within Reacts development.. So I think that when there is a critical issue with server components way of working.. Next and react teams should resolve together 🤷‍♂️

[gnoff]

@LubomirGeorgiev it is a necessity because RSC is equivalent to dynamic bundling and so we can't just load static assets we need to hydrate with initial data that comes from somewhere. without RSC it comes from your static bundle assets. With RSC it comes from the RSC data generated at request time.

I explain more here: #42170 (comment)

[gnoff]

Hi folks, I work on Next.js and React and I wanted to provide a comprehensive answer to a number of questions related to __next_f.push

Is this data necessary?

The short answer is: yes

For React to be interactive it needs to hydrate in the browser. Before RSC hydration happened by downloading a code bundle which contained all the instructions on how to render the application on the client. While there is some efficiency to be gained by using static bundles it has a huge downside of growing with the scale of the application (there is nuance here for code splitting) and while you may host these static assets on a CDN to make them load faster and with less expensive bandwidth for non-trivial applications you would almost certainly be shipping many more KiB to the browser.

You can think of React Server Components as a form of dynamic bundling. A server render produces a set of client code chunks and server HTML markup represented as a tree. This tree conceptually IS the bundle. It's not longer entirely static but was produced at runtime and it needs to be loaded in the browser for hydration to happen.

What about MPA mode?

One might reasonably ask why we need to send this data if there are no client components. The short answer is Next.js does have a path to having an MPA mode and one could make an RSC framework that was entirely server side but Next.js has not prioritized this because we have more urgent things to focus on at the moment. Next.js is a full stack React framework and while MPA mode is an interesting use case it's not our primary focus so we don't have this yet.

What about using the HTML to hydrate?

One might also ask if React can just infer the the HTML markup form the HTML itself. One challenge here is we need to discover client components and where they compose within the HTML tree. We could add metadata to the HTML tree to encode this composition but that would add additional bytes and require your SSR'd HTML markup to contain React specific attributes which has it's own downsides. Another way this is potentially problematic is the initial data isn't only hydration data but also potentially interactively loaded UI. If you have a tooltip with hidden content and then a click handler is supposed to reveal that content then that part of the tree won't be in the HTML so we'd have no way to recover it.

There are some optimizations React can do to eventually get rid of the hydration data for leaf HTML trees (HTML that has no client components composed within it). The React team work on this someday and for some apps it might have a dramatic effect on the size of the initial data that needs to be sent but we have not started this work yet and don't have an ETA on when we will work on it. For apps that are fairly interactive and have a lot of composed client components this optimization won't have a major impact on the initial data size.

What is the best way to load initial data?

We've already established that React requires that there be initial data to both hydrate the App and to have the conceptual "bundle" for the page. The next question is what is the best way for Next.js to provide this initial data on document load.

Data Consistency and Cache Lifetimes

One thing we want to guarantee is that the initial data used to SSR the page exactly matches the initial data we provide React to hydrate the page. The best way to do this is to embed the initial data in the HTML document. If we made a separate resource the HTML document would load we'd need to potentially write the initial data somewhere so it can be fetched but this has infrastructure considerations (what if the write is too slow?, what if the request errors?). We could also just regenerate the initial data and server it in RSC format similar to the RSC responses we get for client navigation. This could work but then we'd render the page twice (worse for compute) and we have the chance that the second version disagrees with the first (what if you used new Date() in your RSC component?).

Additionally if we cache the page because it is static we know that the initial data is always cached for the lifetime of the Document itself since it lives within it. If we lifted the initial date out of the Document then we'd have to worry about cache invalidation of our cached initial data being synchronized with the Document cache.

Page Performance (Core Web Vitals)

The next consideration is page performance. Core Web Vitals are important and we don't want a larger page to block the display of critical visual information. The initial data is streamable and it arrives with a lower priority than visual content. You'll notice that in every HTML Document rendered by Next.js there is always the HTML "shell" first which is the Document head and body along with either the entire page content (if nothing suspended or you did not defined any loading states using Suspense) or some page content with loading states (if using Suspense to take advantage of server streaming rendering). If there is additional HTML to stream in Next.js will prioritize it over this initial data as well. The only time initial data is sent is when the render is waiting on IO to continue revealing additional visual content and we can emit some of the initial data to maximally use available bandwidth. It should be noted as well that for static responses we always produce a complete HTML document first and append the initial data at the end.

What does this mean for Core Web Vitals? The initial data is never in front of visually relevant content so the browser can parse and render the incoming HTML as fast as it is received. Whether the initial data arrives alter in the stream or independently as a subresource request has no bearing on FCP or LCP. In fact it actually can help because if we did a concurrent subresource request it might inappropriately starve bandwidth from critical resources for loading such as stylesheets and fonts. By encoding the initial data into the Document itself we can ensure it arrives at the lowest priority, never blocking other resource loading and never blocking visual HTML.

There is a related concern which is Page Weight. There is a notion that CWV suffer if page weight is bigger. This is only true via correlation in that bigger pages have more "stuff to load" generally and loading more stuff takes more time. But the extra page weight for initial data is not "stuff to load" and so each additional byte has no bearing on CWV. Page Weight is not a direct actor on CWV it's simply an indirect indicator of other stuff that might affect CWV so if you want to investigate CWV performance you need to look at things like your data fetching on the server, your ability to cache, whether your static assets are appropriate sized (optimized images for instance) or whether your fonts are being preloaded properly and discovered early.

Future React direction for initial data

In the future React will support first class support for initial data. It is such a common practice that you want your hydration to see what your SSR pass saw that it ought to be embedded directly in React itself. This means in the future there will be no __next_f.push however there will be something entirely equivalent that React implements and the data will still be embedded in the Document for all the same reasons Next.js currently embeds data this way today.

Summary

React requires hydration for interactivity. This is just part of React's model and not something Next.js is in a position to alter.

React Server Components are a form of dynamic bundling so initial data for hydration (and updates) is no longer statically serveable by CDN assets exclusively. This has tradeoffs but the bet React is making is that request specific dynamic bundles are better for most apps most of the time especially as they grow in size and complexity. Next.js is not in a position to alter this because it is inherent to the RSC model.

Next.js is optimized to provide the best possible CWV by streaming in initial data late and at low priority relative to subresource and HTML which have a big impact on CWV results. Encoding the initial data into the HTML Document is not only not bad it's specifically good and better than all the other options. The reason pages router or non RSC frameworks don't have a similar feature in their document streaming is the initial data is entirely static (it's bundler chunks) which while nice that is is static suffers from the inability to scope the "bundle" to what was rendered (allowing for nuances like code splitting)

There are some optimizations that React can make to shrink the size of the RSC tree but these optimizations will reduce the size of the initial data not eliminate it's need for existing in the first place. It's a quantitative change not a qualitative one

React believes in the model of embedding initial data into the HTML Document so much that it will eventually implement this into the framework itself so every SSR supporting React project doesn't have to implement this kind of thing itself. (Note that this isn't limited to RSC initial data, it could be things like i18n translations or any other data used during SSR that should be available on the client during hydration)

[stavros-k]

While I get that data somehow be available on hydration, what I don't get is why the scripts include also data that are not used for hydration.

Let me say first that I'm not a frontend pro, nor I know much about treeshaking and stuff.

What I mean, with my first line is;
I import few JSON files that have translations for eg 3 languages.
I render statically (SSG) all the pages, and I can see on each page that the content of ALL jsons are in there.
Okay its needed as it will behave as an SPA once its on the browser. So far, I get it.

But know is the tricky part. Those JSON files include keys that are used only when a flag in a config.ts file is enabled.
(eg enable these 4 extra pages). The config is known at buildtime.

So why are those keys also presented in the script tags?

Again, this might be a "me" issue/error, for not doing something obvious to hint the "builder" to prune those.

[gnoff]

I’d need to see the code that produced the situation you are describing to say why you are seeing all the files vs just the one that is used for the page. The answer will almost certainly have something to do with how you are importing the json files and how they get bundled by webpack or turbopack. Lmk if you have a repro you can share

[stavros-k]

Thanks for replying!

I've spent this afternoon educating myself a bit.
And yes as you described, the issue probably comes from the way I'm importing them.
The messages are provided from a Provider, so I can then do useTranslations() on client components.

There are some ways to avoid that, by using unstable_setRequestLocale, but that's only for pages that are not "use client"
So I can only use the provider (NextIntlClientProvider)

https://next-intl-docs.vercel.app/docs/usage/configuration#nextintlclientprovider
https://next-intl-docs.vercel.app/docs/getting-started/app-router#add-unstable_setrequestlocale-to-all-layouts-and-pages

So I guess this is "normal".

This is an "extreme" example, some translations I had was not very good formatted (which we actively working to fix)
We now have a pre-build script copying store specific configs/translations into a directory where code imports them up,
instead of importing all of the configs/translations for all stores there and using the one based on a flag.

It was in a format like the below, where multiple texts was duped.

"store1": {
  "title": "some-title",
  "some-specific": "translation for the store"
},
"store2": {
  "title": "some-title"
  "some-other-specific": "translation for this store"
}

[eric-burel]

@stavros-k for reference many organizations seems to be studying the issue of i18n with RSCs, that's how I ended up in this (very complicated) discussion by studying where client/server tokens end up. Somehow I only see the tokens used in client components il __next_f_push calls, the RSC approach seems to work as expected and shove some kb out of our HTML file.
Our efforts at devographics (state of js survey) are tracked in this PR: Devographics/Monorepo#367
Lingui seem to work on something similar but also adds build-time magic to extract tokens: lingui/js-lingui#1698

[stavros-k]

Thanks for the lingui issue link, I've subscribed as I'm very interested in this.

Our website is and has to be 100% translatable. Even the smallest text. While we don't have "dynamic" texts (like 1 apple 2 apples), there is a ton of text inside client components, which are animations for the most part, but I'm already going over and trying to do as much as possible, server side rendering and dropping those as children. But that sometimes results in messy code.

[anthonyhexium]

Moving to Astro. Thanks for those amazing years 🫡 !

[Sly36]

Same problem on our big statically exported site (7K pages), I have spent the last two weeks migrating all the application to app directory and making use of RSC for a web performance / seo taskforce only to see our Core Web Vitals getting worse. I'm sad...

[omerman]

Understood, thank you so much for your time anyways. Out of curiosity I might try to build a version with less server components on one of my routes to check how it effects the stats. Cheers

[IlirEdis]

Hello guys,
For my use case i found a solution and it is... you guessed: Astro!
Please note that im talking about measurements from CWV on https://pagespeed.web.dev/ and not from lighthouse. I always got 90> on lighthouse but i would never imagine that i would get this score in CWV.

I'm not very pro in Astro yet but it looks that its not very flexible for larger apps which require more complexity or a Saas app but for a website connected with a CMS (Sanity in my case) and getting data back and forth, after months of struggling with Next to get a decent CWV score, i got this amazing score on mobile.

[anthonyhexium]

@IlirEdis went with Astro too. It's oriented on content websites. So I would never build an app with it.

[IlirEdis]

@anthonyhexium yep, i agree. And i would never build a website with Next :)

[anthonyhexium]

Agree. I am done building marketing websites with Next.