[Next.js + Magnolia Headless] Large Page Size Issue

[Dhyey Thumar]

Hi everyone,

I’m integrating Magnolia CMS with a Next.js app and ran into an issue regarding page size.

Context:

I'm using @magnolia/react-editor within a Next.js project to allow marketers to use frontend components in Magnolia pages and place them flexibly. The page content is fetched on the server side using the Magnolia Delivery API.

Problem:

After setting this up, I noticed a significant increase in the size of the page HTML. Upon debugging, I found that the entire page JSON is being sent down in an inline script tag within the HTML.

The confusing part is:

My HOC component that wraps Magnolia rendering logic is a React Server Component, so I wouldn't expect any client-side serialization of the entire JSON.

Questions:

• Why is the Magnolia JSON content being inlined like this?
• Is this behaviour coming from the @magnolia/react-editor package?
• Has anyone faced this kind of issue with Magnolia and Next.js?
• Any suggestions on how to prevent this and keep the payload smaller?

Environment:

• Next.js version: 14.2.15
• @magnolia/react-editor version: 2.0.0
• Node.js version: 22.13.1

Happy to provide more code or repo if it helps. Any insights would be hugely appreciated!

Attached the inline JSON example and HOC logic.

Thanks in advance,

Dhyey

[Dhyey Thumar]

Attached the inline JSON example and HOC logic.

[Mykola Soldatenkov]

• Why is the Magnolia JSON content being inlined like this?
  

• This is how Nextjs works.
  Nextjs serializes data retrieved server-side so that it can be passed to the client-side app. It is used in different mechanisms, but mostly to compare rendering results and managing initial states in hydration. See Hydration error docs and Github discussions for example. It is a quirk of the Isomorphic/ Universal apps :)
  
  In the Pages router it is serialized in a single inline script called  __NEXT_DATA__
  In the App Router, while getServerSideProps and getStaticProps are no longer used, data fetching happens via async server components or fetch() calls in layout.js, page.js, etc. So instead of a single inline script it can attach multiple smaller scripts.
  
  If I'm not wrong Server Components do not expose their props to the client.
  Only Client Components (or props passed to them) get serialized and sent to the browser.
  
  

• Is this behaviour coming from the @magnolia/react-editor package?
  

• No, this is a Nextjs behaviour
  
  

• Any suggestions on how to prevent this and keep the payload smaller?
  

• It depends on the nature of your project
  a) If you have a public blog for example, and you want good SEO - just leave it there.
  b) If you want to reduce the amount of serialized data, you can try to split data between server components and client components.
  Maybe go clean headless for some parts? Sometimes it's simpler to retrieve a smaller chunk of data based on a regular route, then handle a catch-all route.There is an example from Magnolia for that.
  c) If you have a dashboard or some sort of SaaS with login (unavailable to public users), then it should not require SSR. I'd say do everything client-side. Client-side doesn't hydrate, hence no serialized data in the body.

• My HOC component that wraps Magnolia rendering logic is a React Server Component, so

•  I wouldn't expect any client-side serialization of the entire JSON.
  I suspect that you pass down your props to a page and one of your pages and/or components is a client component, so it is serialized by one of the deeper nested components. Try to debug them.
  
  

--
You received this message because you are subscribed to the Google Groups "Magnolia User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to user-list+...@magnolia-cms.com.
To view this discussion, visit https://groups.google.com/a/magnolia-cms.com/d/msgid/user-list/8b42ca93-e71b-4f48-a71e-f0b0c7890619n%40magnolia-cms.com.

--

-- 

Powyższa wiadomość wraz z ewentualnymi załącznikami jest przeznaczona wyłącznie do wiadomości osób lub podmiotów, do których jest w sposób zamierzony zaadresowana. W przypadku otrzymania powyższej wiadomości w wyniku pomyłki, prosimy o pilne powiadomienie o tym fakcie nadawcy oraz o usunięcie wiadomości z systemu, a także o nie rozpowszechnianie treści w niej zawartych. Otrzymanie powyższej wiadomości nie może stanowić podstawy do jakichkolwiek zobowiązań nadawcy tej wiadomości wobec osób nie będących jej zamierzonymi adresatami. 

This e-mail message and any attachments is intended solely for the use of the persons or entities to whom it is intentionally addressed. If you have received this message in error, please notify the sender about this fact immediately and delete it completely from your computer system. Please do not disseminate this message unless you are the intended recipient of it. This e-mail message shall not create any legal obligation on the part of the sender to persons who are not intended recipients of it.

[Dhyey Thumar]

Hi Mykola,

Thank you so much for taking the time to help me out—I really appreciate it.

I'd like to highlight a few observations that might clarify the issue further:

• While I do have a few individual client components, they are located deeper in the render tree. I understand and accept that any props passed to those client components would need to be serialised to the client.

• However, the root component in my application—the HOC wrapping the Magnolia rendering logic—is a React Server Component. Based on this setup, I would not expect the entire Magnolia page JSON to be serialised and sent to the client.

• My intent is to keep the root as a server component, within which I mount Magnolia’s EditablePage component and pass it the complete page JSON along with other configuration options.

After inspecting the @magnolia/react-editor package, I looked into the file: "react-editor/src/server/components/EditablePage/EditablePage.tsx".
From what I can tell, this file mounts the EditablePageClient component, which is a client component. As a result, the entire Magnolia page JSON gets passed down to a client component—explaining why it’s being serialised into the HTML.

My question:

Is there any option to opt out of using the page client component, so that the Magnolia page rendering can remain within the server component boundary? This design forces me to mount a client component at the root of the render tree, which prevents me from taking full advantage of React Server Components.

Attaching few screenshots of @magnolia/react-editor package, to which I am referring.

If anyone has found a solution or a pattern to work around this, I’d be very grateful for your input.

Thanks again!
Dhyey

[Mykola Soldatenkov]

Oh, I didn't noticed they've released 2.0.0
I'm not sure, but I think you can:
a) try some of the suggestions described in nextjs-starter
b) try downgrade editor to version 1.x @magnolia/react-editor@1.x
c) try to override EditablePage by your own (although it sounds a bit hacky, and I'm not sure if all needed utils are exported properly)
d) report an issue in Jira
I will try to reproduce your case next week

[Dhyey Thumar]

Hi Mykola,

Thanks for the suggestions!

a) Yes, I’ve tried using the nextjs-starter demo project. Unfortunately, the issue originates from the @magnolia/react-editor package itself, so the demo project also exhibits the same behavior.

b) I actually started with version 1.x and later upgraded to 2.0.0, but the issue persists across both versions.

d) I’ve identified the root cause and have opened a detailed request on the official @magnolia/react-editor GitLab repository under the Issues tab.

Appreciate your help, and looking forward to hearing if you're able to reproduce it next week!

1. 
   

Issue link - https://gitlab.com/magnolia-ce/frontend-sdk/react-editor/-/issues/1

[Christoph Damm]

Hi Dhyey,

had a simliar issue (so would also appreciate a change there), which also actually has been put into the magnolia jira as far as i can see.
However: what i guess can help, depending on your use case and data structure, is to decrease the outcome of pages endpoint with the "properties" filtering, especially on referenced nodes!

Cheers,

Christoph

[Dhyey Thumar]

Hi Christoph,

That will certainly help; however, I also have a few HTML content nodes where users can add custom HTML directly via Magnolia. This could still lead to a size issue.

Thanks!
Dhyey