Why does __NEXT_DATA__ exists?

[jensmeindertsma]

Can someone explain why the following element exists on my page:

<script id="__NEXT_DATA__" type="application/json">
{
   "props":{
      "pageProps":{}
   },
   "page":"/",
   "query":{},
   "buildId":"mgml30LY3PGj-2IRzRxCf",
   "runtimeConfig":{},
   "nextExport":true,
   "autoExport":true,
   "isFallback":false
}
</script>

I recently discovered that data fetching using getStaticProps populates props.pageProps with the value returned by getStaticPropsthat can be accessed inside the page component. I would like to know why this data is stored in this script. I am already using and displaying this data inside my component, so now it is included twice in my page. This might be bad for performance when I have a lot of data fetched by getStaticProps?

This is not meant as a complaint, but as a question. I would like to understand why this is needed, and how I can optimize it for large data ( like fetching a lot of Markdown from a CMS ).

[jamesmosier]

That is used so Next (well, React) knows what data you want to hydrate on your page during server side rendering. Otherwise the server would not know what data to use to populate your React components. The page needs to get the data from somewhere and the DOM makes the most sense for any server rendered JavaScript application.

[jensmeindertsma]

So this data is used by the client to pass to the hydrated React component as props? Do you have any material I can read to better understand hydration? I feel like I'm missing the point here. How does React know which components map to which static HTML once the HTML gets hydrated on the client side? Where is this "mapping" stored?

Also, it seems like a large problem that the page size increases so much when you fetch the entire page layout from a CMS at build time. Is this true?

[jensmeindertsma]

@jamesmosier I mean, what if I fetch a large blog post from a CMS in getStaticProps? This will fetch a lot of data which is then rendered by the page, basically as-is but with just styling applied. With __NEXT_DATA__, all the fetched data is placed in the HTML file again. This means it exists twice. I would really like to know whether this is a performance issue or not. Could you give me some insights on this?

Thanks so much for helping me out!

[arunoda]

@jensmeindertsma you point is correct about duplicating data. We do this because of how React works. Specially related to pre-rendered pages. This is the reason:

• Inside the server, it pre-render HTML
• Then inside the client, React need to map this HTML with the components related to this page
• Otherwise, there'll be a flash in the screen, which looks ugly
• So, it need to generate the same HTML inside the client.
• If those two are the same, React is happy and continue the client side work

So, it need to generate the same HTML inside the client.

This is why we need to send props and others along the HTML.

[jensmeindertsma]

Alright, but why can't the HTML - React mapping and this data be colocated? I can't find this mapping anywhere on a script tag on the page. Is it included in the Next.js bundle? Then why can't these props be? I'll open another discussion about fetching Markdown.

[richardthombs]

I'm struggling to understand why this behaviour is associated with the word "static". I'm expecting that pages produced by "npx next export" would be pure html. I can see that a dynamic site would need to have the content cached locally so that react can build its DOM, but what if I don't want react to be present at all on the client? I just want to use it to render a really static site, like Jekyll would?

[samfromaway]

Hello. I use next js for a website with tabs from Material UI and just found out that only the first tab panel will be rendered as HTML. All the content that is in other tab panels is only visible as the props JSON in the NEXT_DATA script. What effects does that have on SEO? Does that negatively affect how easy it is for the google (& co.) crawlers to crawl the website? Thanks :D

[richardthombs]

It does seem like we are sacrificing bandwidth for page rendering speed. I just checked by build more closely and there seems to be an additional copy of this data stored in a json file in _next/posts. So my docker image contains three sets of this information - the actual static page content, a bunch of JSON embedded in the web page and an additional set of JSON in the build.

Surely at least one of these can be optimised away?

[samfromaway]

@leerob you are right. As you said in your video reply, it depends if the UI is manipulated with JS or CSS.

I think Material UI was not primarily built for websites (SEO/SSR) but more for Web-Apps. I've seen some more behaviours where the UI in MUI is controlled by JS by default, sometimes there is a prop we can set like in the component Hidden https://material-ui.com/components/hidden/#implementations to change from JS to CSS.

I'm working on a project where we did a lot of SEO performance comparisons and the general gist I got is try to stay as close as possible to normal CSS and HTML, which also reduces this NEXT_DATA json.
The disadvantage of course is DX and UX as for example there is not a datepicker that comes close that what MUI has if I wanted to do that in vanillla CSS.

But I'm still a little concerned about the _NEXT_DATA json as I don't know if google crawls that like @haletothewood said. Which can lead to all sorts of confusion with google.

In a nutshell what I do from now on:

• Use as much vanilla CSS and HTML for styling. No fancy component library elements if not needed.
• If adding a component from a library like MUI, Chakra... check how the manipulation works (if CSS or JS)
• If I build a component myself, I try to use display none, instead of conditional rendering (e.g. isDisplay && <Component />)

But it would be great if someone from next could give an expert opinion on that.

[samfromaway]

BTW here my video question I had for leerob https://youtu.be/kJNDNYXYvPk. and here his reply:

Thanks for the video, that helped a lot! The issue is that the Material UI component is loading a new React component on the client-side versus Chakra which is server-rendering that component. It’s the same on my site. When you click “see more”, I’m using React state to then show that component. It’s worth checking if Google allows using display: none and still indexes that content. I’m not sure if it’s smart enough to detect that that content isn’t visible. If it does index that, then I would ensure that you’re not using a component that toggles content with JavaScript on the client side.

[richardthombs]

I just read this about whether Google indexes display: none content. Apparently it does: https://www.seroundtable.com/google-search-display-none-visibility-hidden-30535.html

[samfromaway]

Exactly, the issue is when an element like the MUI tab conditionally renders the UI. Then the element won't even be on the HTML in the DOM but (if I understood correctly) much of the information will be saved in the NEXT_DATA json and the JS bundle of next. The google bot of course won't see that then.