-
Notifications
You must be signed in to change notification settings - Fork 26.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
React lazy or next dynamic don't reduce an app route's "First Load JS" #49454
Comments
@antoineol try adding
and make sure you are using a dynamic import: https://nextjs.org/docs/app/building-your-application/optimizing/lazy-loading#nextdynamic see docs:
via: https://nextjs.org/docs/app/building-your-application/optimizing/lazy-loading#skipping-ssr Also, based on your before and after screenshots, your homepage size and first load JS is decreasing. Before: After: |
does the "first load JS shared by all" number change? i see above, it is 76.9 kB. is it smaller when using a dynamic import? next/dynamic is what you should be using, and add https://nextjs.org/docs/pages/building-your-application/optimizing/lazy-loading#with-no-ssr
|
also I checked your CodeSandbox @antoineol, you're not rendering that imported component anywhere, try adding this:
within the page's return statement, for example:
that may make a difference, compared to rendering that component and importing it normally, without the dynamic render: no dynamic import:
versus dynamic, no srr:
|
No, "first load JS shared by all" does not change. Only the "First Load JS" of the page, depending on what's imported.
True, for the minimal reproduction, just importing (lazily) was enough to increase the "First Load JS", even without any usage. Using the component doesn't change it. It sounds like the issue is still there:
Any idea about what could be wrong?
Thanks for your help! |
We're seeing something similar. We are consuming our svg lib with a custom Icon-component where we pass name and then use an object built up by next/dynamic values for the actual svg icon. With the app dir enabled these svgs end up as part of one of the main bundles, without it into separate bundles per svg file (as intended). I've experimented a bit and it seems like next/dynamic loaded components referenced from a sever component will find it's way into one of the client js bundles. |
I observe the same behavior in newer NextJS with Which means
No, it worked properly in NextJS v12, at least. Was one of the best way to reduce a bundle size. Likely a regression after a rewrite to TurboPack. But it's kinda weird that nobody else has noticed it. Maybe it's conditional on something 🤔 Note: the only imports of forementioned components are dynamic, no silly mistakes like static + dynamic imports or reexports from |
having the same problem with app router |
It's a wired behavior (and not well documented), but I stopped dynamic import from ssr and extracted to a client side file it worked. Before (600KB first load js):
After (80KB first load js):
|
Experiencing the same issue in next 13 using app router |
that works for me; however, there is still an issue with PSI (google pagespeed insights or lighthouse): using wrapper with a dynamic inside client component with ssr:false Route (app) Size First Load JS
without an element at all: Route (app) Size First Load JS
without wrapper - using a dynamic in server component with ssr:false:
|
it's kind of a joke that at least since May code splitting doesn't work in NextJS app directory. We are now on version 14.0.1, app router is recommended for all new applications since May, (v13.4.0 right?) and core features don't work at all (code splitting, cache & revalidation (fixed in 14.0.2-canary.3 tho, finally)). 2.4k open issues and Vercel is focusing on server actions that are just a sugar layer on top of the api routes. Like... seriously? Let's imagine any app that has a CMS - currently EVERY SINGLE PAGE, no matter if renders 1 component or 100, gets the same, huge bundle with all components included. Like seriously, using Next stopped to be fun with version 13, as most of the development time is spend on debugging the newly introduced bugs or discovering that core features that worked since v1.0.0 now just don't and no ones gives a s**t about it for half of the year. I don't know what are your processes of development, but would be nice to revisit them, as almost every new update introduces more bugs than it fixes. App router is not stable and shouldn't be used by any project larger than a landing page. PS: code split works fine with pages directory (v14.0.1). |
For me in the pages dir is not working even, or I don't understand something how it is possible that lighthouse is complaining about not used js, if that component is with dynamic import and ssr: false ? |
Experiencing the same issue in app router. It's not possible to use app router for large applications, because pagespeed performance is really bad, when using many components. |
Same issue here. CMS, all content is dynamic, and the page is slow (not just page speed numbers, but visible too for the eyes). We need a solution for dynamic import, suspense, lazy load, file sizes |
Exact same issue here. This is preventing me from using Next in any production site and as I see it, is not fit for purpose. This issue has been open over 6 months now and it would be nice to know if it isn't being worked on so I can look for an alternative framework. If it is then why the lack of communication? |
Hi, sorry for the late response, definitely missed the discussion here as there're too many issues atm. Wanna share a bit more that how can you do code-splitting better. SolutionIf we look at the reproduction case that shared in the issue description, it's using
So you could either add a client component in between the module you're loading or mark the page.js as client component if that works for you. WhyCalling Using We'll improve the education resource to make it more clear and any feedback to it is welcomed, thanks |
When server components are imported via next/dynamic, shouldn't the CSS be split into chunks? The issue is that the CSS of all components is bundled into one CSS file. Thia leads to performance losses in Google PageSpeed Insights, especially in larger projects. |
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Verify canary release
Provide environment information
Operating System: Platform: linux Arch: x64 Version: #22 SMP Tue Jan 10 18:39:00 UTC 2023 Binaries: Node: 18.16.0 npm: 9.5.1 Yarn: 1.22.19 pnpm: N/A Relevant packages: next: 13.4.2-canary.0 eslint-config-next: 13.4.0 react: 18.2.0 react-dom: 18.2.0 typescript: 5.0.4
Which area(s) of Next.js are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue
https://codesandbox.io/p/github/antoineol/repro-next-lazy-build-size/main?layout=%257B%2522activeFilepath%2522%253A%2522%252Fapp%252Fpage.tsx%2522%252C%2522openFiles%2522%253A%255B%255D%252C%2522sidebarPanel%2522%253A%2522EXPLORER%2522%252C%2522gitSidebarPanel%2522%253A%2522COMMIT%2522%252C%2522fullScreenDevtools%2522%253Afalse%252C%2522rootPanelGroup%2522%253A%257B%2522type%2522%253A%2522PANEL_GROUP%2522%252C%2522panels%2522%253A%255B%257B%2522type%2522%253A%2522PANEL%2522%252C%2522panelType%2522%253A%2522TABS%2522%252C%2522id%2522%253A%2522clheryg3i00z3356lq12hxizh%2522%257D%255D%252C%2522direction%2522%253A%2522vertical%2522%252C%2522id%2522%253A%2522DEVTOOLS_PANELS%2522%257D%252C%2522tabbedPanels%2522%253A%257B%2522clheryg3i00z3356lq12hxizh%2522%253A%257B%2522id%2522%253A%2522clheryg3i00z3356lq12hxizh%2522%252C%2522tabs%2522%253A%255B%257B%2522type%2522%253A%2522TASK_LOG%2522%252C%2522id%2522%253A%2522clhes0d6l01go356lvx2x3s0w%2522%252C%2522taskId%2522%253A%2522build%2522%257D%255D%252C%2522activeTabId%2522%253A%2522clhes0d6l01go356lvx2x3s0w%2522%257D%257D%252C%2522showSidebar%2522%253Atrue%252C%2522showDevtools%2522%253Atrue%252C%2522sidebarPanelSize%2522%253A15%252C%2522editorPanelSize%2522%253A41.68257051007683%252C%2522devtoolsPanelSize%2522%253A41.442795629349064%257D
To Reproduce
https://github.com/antoineol/repro-next-lazy-build-size
yarn build
, you will get:Open
app/page.tsx
, comment this line:Then build again. You will get:
Same result if using the
dynamic
wrapper instead oflazy
.Describe the Bug
My understanding is that the "First Load JS" is the minimal bundle size to render the page, excluding lazy-loaded content that are in separate chunks, and counted separately. I expect "First Load JS" to be what matters for a quick initial rendering to improve the lighthouse score.
In this experimentation, lazy does not seem to reduce this initial bundle size. It behaves like a traditional "import" that includes everything in the initial bundle.
Unless I'm missing something?
Expected Behavior
The "First Load JS" remains the same, with or without this line commented:
Since I would expect it to he a separate chunk, not counted in the initial render.
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response
The text was updated successfully, but these errors were encountered: