Massively inflated bundle size with pages #47
Milestone
Comments
|
I maintain a Next.js application with 600 pages... (600 * 370kb = 222mb) |
Merged
|
I just got hit by this error and not clear on what to do. |
|
Same here. I have a really simple app, but the pages are 3-5MB. Why are the sizes so inflated? |
|
Yup, same, we only have 2 pages, and over 1mb Edit @dario-piotrowicz / @james-elicx , sorry for the ping, is there any solution to use Nextjs on Pages? Something is not adding up :/ Edit 2: This is the result from Nextjs build: |
Yes. Use Vercel like they want you to do, or host it yourself on a VPS. It's extortion. |
|
Hello @Richard87 @HenrijsS, are either of you able to share your applications so that we can see what is leading to such a large bundle size in them, and see if there is other deduping we can do for them? It's possible that you may have rather beefy dependencies that are massively inflating the bundle size, but it's also possible that there could be another reason. Without seeing what's going on in your application, it's very hard for us to tell or help. Please also make sure that you are using the latest version of |
|
Hi @james-elicx ! I uploaded a copy of our app and wired it up to cloudflare and invited you to the repo (since it will be the copmany app I don't want to publish it :) ) Link to Cloudflare project: https://dash.cloudflare.com/f593c3a9731a785a4623f24946748032/pages/view/cloudflare-test/a1600a52-da2b-4d6b-8e92-75324c16b155 Deploutlog of richard87/cloudflare-test
|
|
Thank you @Richard87. Looking at this, I actually believe Clerk is causing your issues. It kind of explains something that I wasn't able to explain when I was looking at a reproduction for a Clerk issue the other day. I didn't understand why I was seeing wasm files in the reproduction, but I see the same ones in your project. I looked at the differences when adding Clerk in a plain app. Without Clerk:
With Clerk sign-out component, context provider, and middleware:
To me, it seems like Clerk is using things that it has no need to, and, as such, it is resulting in big wasm files (1.4mb total) and webpack chunks that don't need to be there. In your repo for instance, the unzipped middleware function goes from 30kb -> 800kb after our deduping, just because it uses clerk - for some reason it has chunks that are of no relevance, like all of reactjs. When I look at the chunks that use the Wasm files, and the font, they actually look like they're coming from So, to summarise, it appears that Clerk is adding all this unnecessary code that shouldn't be there and thereby is massively inflating your bundle size. |
|
Thanks for doing looking into it! I'm opening an issue at Clerk side ASAP! |
20 tasks
@Richard87, I'd also like to point out that the numbers above are JS payload size for the client-side code and not for the server-side code. I suspect that if you were to look at the build output Vercel CLI provides you with, you'd find that the vercel output is actually several times the size of what @cloudflare/next-on-pages is pushing to Pages. |
|
Yup, absolutley, but basically 2 wasm files, one small(less than 100kb), and one big(1mb+). And a bunch of other stuff |
|
I suspect that you will find more in the Vercel CLI output. By design next-on-pages aggressively dedupes and optimizes the output Vercel CLI produces to the extent it is safe to do so without breaking the app. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following the installation guide in this repo, my initial
_worker.jsoutput is 370KB.If I then simply duplicate
pages/index.tstopages/index2.ts, and rebuild, I get over 750KB. And then if I do the same thing withindex3.ts, I get over 1MiB. This is adding around 300KB for every single page.Any real-world site loading some other dependencies, component libraries, etc. is going to rapidly exceed Workers limits, even with the increase to 5MiB. We've seen multiple people in Discord report hitting this limit with sites that had as little as 7 pages!
Here are some numbers for the generated
_worker.jswhen using the experimental minify option, and when not:using
--experimental-minify1 page site: 370KB output
2 page site: 750KB output
3 page site: 1MiB output
without
--experimental-minify1 page site: 333KB output
2 page site: 622KB output
3 page site: 911KB output
That's not a typo - the
--experimental-minifyoption appears to make the output larger.The text was updated successfully, but these errors were encountered: