Unzipping is 50x times slower in NextJS compared to Gatsby or other platform

[ingun37]

What version of Next.js are you using?

10.0.5

What version of Node.js are you using?

12.0.0

What browser are you using?

Safari, Chrome

What operating system are you using?

macOS, Windows

How are you deploying your application?

next start

Describe the Bug

Unzipping a zip file using JSZip is 50x slower in NextJS than in Gatsby.
I made a sample app that unzips a zip file on both NextJS and Gatsby. It took for 162647.844ms for NextJS while it only took for 3091.979ms in Gatsby.

I believe it's not only unzipping but execution of javascript (especially cjs modules) is generally slow in NextJS. The whole reason I've done it in the first place was because my js library was significantly slow only when it was used on NextJS app. Unzipping is just the most extreme case that I've observed. My library, which is primarily WebGL, becomes about 2~10x slower (depending on the kind of job) in NextJS compared to Gatsby or other platforms.

Expected Behavior

I expect no runtime performance difference to Gatsby.

To Reproduce

Here's the sample app
https://github.com/ingun37/nextjs-bug-reproduce-sample

NextJS

• location: /nextjs
• How to run
  1. yarn run dev or yarn run build && yarn run start
  2. Click Unzip and measure the time button and check the console.

Gatsby

• location: /gatsby
• How to run
  1. npm i && npm run develop
  2. Click Unzip and measure the time button and check the console.

[ingun37]

And the problem occurs only for cjs modules. It works fine when I use the same library imported by <script> tag.

[timneutkens]

Had a look into this issue through profiling and debugging. As it turns out this has nothing to do with commonjs or even Next.js execution and it's certainly not "every library":

The particular library that you're using jszip uses a non-standard JavaScript method called setImmediate: https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate. When I say non-standard it's related to this particular message:

This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user

Webpack 4 automatically polyfilled browser modules to match the Node.js environment, this includes crypto, process, setImmediate, and others. Ballooning bundle size in the process. In Next.js this polyfilling is disabled for setImmediate because it's non-standard. In Gatsby it's enabled, allowing for non-standard behavior.

Webpack 5 disables all automatic polyfilling behavior, in Next.js we still provide backwards compat for cases like crypto/process to make sure you can use webpack 5 in a backwards compatible way.

In case of jszip this means that jszip will automatically fall back to a setImmediate polyfill. However the polyfill that is used in jszip is slow by design: sindresorhus/set-immediate-shim#4.

There are multiple open PRs on jszip to fix the issue in a way that is supported by all browsers, but it seems that none have landed yet:

• Improve better performance Stuk/jszip#702
• Use "immediate" instead of "set-immediate-shim" Stuk/jszip#716
• Fix performance issue with setImmediate Stuk/jszip#619

My library, which is primarily WebGL, becomes about 2~10x slower (depending on the kind of job)

Because of jszip or because of this other library that you're using? I'd be happy to have a look into that particular library as well if needed.

---

So TLDR: Next.js is not slow, the particular library is incorrectly being polyfilled in the case where you're building the library using Gatsby and the setImmediate usage should be fixed inside of the jszip library.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.