I hope more people can participate in the discussion of this topic !, How to render on the server without returning hydrated data next? This will increase the size and volume of HTML and document files

[parlay96]

Summary

I don't want to return data here?Our company has technical experts who have achieved this step。Can we consider delaying client hydration?

If the page data is not returned, the document will definitely become smaller, which is beneficial for improving loading time

Additional information

I don't want to return data here?Our company has technical experts who have achieved this step。Can we consider delaying client hydration?
![image](https://github.com/user-attachments/assets/3753850a-01d9-4391-8489-27162a74b69c)
If the page data is not returned, the document will definitely become smaller, which is beneficial for improving loading time
![image](https://github.com/user-attachments/assets/a9c8f1f0-7460-4d07-8545-79074247f30b)

Example

No response

[maciej-ka]

Based on few assumptions
(Please correct me if any of these are wrong)

• we have several components
• some of them need to be displayed immediately
• some would be better delayed
• before the delayed ones are loaded, we want to present loading placeholder

Existing solution would be to use next/dynamic.

Official docs

Lazy loading with next/dynamic

Example from the Docs

import dynamic from 'next/dynamic'
 
const DynamicHeader = dynamic(() => import('../components/header'), {
  loading: () => <p>Loading...</p>,
})
 
export default function Home() {
  return <DynamicHeader />
}

[parlay96]

@maciej-ka My goal is how to delete NEXT_DATA, as it will affect the size of my HTML file

[maciej-ka]

Interesting.

• is your website 100% static?
• do you use App Router or the Pages Router?

[icyJoseph]

This is the "problem" with hydration frameworks. So called, x2 data problem.

• Why does `__NEXT_DATA__` exists? #15117 (comment)

Here you can see, a summary of performance, and x2-ness of various frameworks: https://github.com/eknkc/ssr-benchmark

You can use this https://github.com/jherr/njs13-n-plus-one/blob/main/tester/index.js (works for App Router), tool, to measure the impact of this additional data.

The recommendation here is to massage your data within getStaticProps, or getServerSideProps, and avoid sending downstream way too much.

A consideration here is that, sensitive data, that's filtered as you render, but return from getStaticProps, or getServerSideProps, will still be present in the DOM, in __NEXT_DATA__.

If you choose to do a dynamic escape, you will opt that subtree out of SSR, which is not great either.

The Server Component architecture, can indeed help with this though, but it is not there just yet: #56283 (comment) - #42170

I think this discussion was also quite good to follow: #52119

But, yeah __NEXT_DATA__, as far as I remember lives on... I can tell you, most of the time it is ok, but I worked once with Akamai servers, which limit the total HTML payload, and that was no fun...

[maciej-ka]

Ton of interesting links, thanks @icyJoseph!

[parlay96]

@icyJoseph Thank you, my question is, is there any way to remove NEXT_DATA? Do you have any ideas? After all, it occupies a large amount of HTML and document space

[parlay96]

@timneutkens @Timer Is there any way to delete NEXT_DATA? Do you have any ideas? After all, it takes up a lot of HTML and document space， Boss, can you answer that? Thank you

[icyJoseph]

#34221

I see you have been asking this before. And again, at least in Pages Router, that's there to stay.

[parlay96]

@icyJoseph yes，But I don't know how to solve it

[parlay96]

@icyJoseph Sorry, buddy. We have already implemented the deletion

[maciej-ka]

After following your links, @icyJoseph, here is how I understand it:
(I may got something wrong, I'm here to learn)

• Page needs prerendered html for SEO.
• (my conclusion) Next.js can't hydrate solely from html because some parts of component state may not be present there.
• So in general 2x bandwidth cannot be avoided.

Still, hydration data could arrive at different moment.
a) sent in a separate request
a) or with component js, which @jensmeindertsma perhaps meant by colocation

Some guessing why atm NEXT_DATA is alongside prerender:

1. To avoid mismatch: if data arrived later, there may there might be updates (e.g., DB changes, Date change), causing UI oddities.
2. Performance: hydration data shares data preparation with prerender.
3. Non-idempotency. A component that sends emails might do it twice if hydration data is fetched separately.

Could the solution be to store NEXT_DATA server side in a short-lived cache, then let the client fetch it post load?

[parlay96]

@maciej-ka I completely agree with your approach. Do you have a good implementation code

[parlay96]

@timneutkens @Timer Is there any way to delete NEXT_DATA? Do you have any ideas? After all, it takes up a lot of HTML and document space， Boss, can you answer that? Thank you

[parlay96]

I hope more people can participate in the discussion of this topic !