Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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.

Sign up for GitHub

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

Jump to bottom

Dev Server Eagerly Compiles Dynamic Imports #18819

Closed
ddgromit opened this issue Nov 4, 2020 · 10 comments
Closed

Dev Server Eagerly Compiles Dynamic Imports #18819

ddgromit opened this issue Nov 4, 2020 · 10 comments
Assignees
@jankaifer
Labels
Webpack Related to Webpack with Next.js.
Milestone
backlog

Comments

@ddgromit
Copy link

ddgromit commented Nov 4, 2020 •
edited
Loading

Bug report

Describe the bug

The dev server is eagerly following dynamic imports in a page and compiling them before they are requested.

One of my pages does one of a few dynamic imports depending on the type of object its viewing. Each dynamic import in the page is reasonably sized but put together they cover almost the entire codebase. Since the dev server is compiling them all on the first page load, just to build that page (even before the page loads and can do the import) the dev server takes about 2-3 minutes of compilation time and node racks up over 4gb of memory.

The bundle chunks are actually generated correctly both in dev and production, and the code isn't actually loaded by the browser until the dynamic import is called. However it seems the dev server has to compile or process the entire tree of dynamic imports just to display the page for the first time.

To Reproduce

Requesting this page responds in seconds:

export default function TinyPage() { return <div>Hello</div>; }

Whereas this page takes minutes, even though the dynamic import is never called:

import dynamic from 'next/dynamic';
const SomeBigComponent = dynamic(() => import('./some-big-component'), { ssr: false });

export default function TinyPage() { return <div>Hello</div>; }

Expected behavior

Dynamically imported files should not be compiled by the dev server until the client requests them.

Screenshots

Screen Shot 2020-11-04 at 3 28 05 PM

System information

  • OS: mac
  • Browser (if applies) chrome
  • Version of Next.js: 9.5.5
  • Version of Node.js: 12.13.1
@ddgromit ddgromit added the bug Issue was opened via the bug report template. label Nov 4, 2020
@ddgromit ddgromit changed the title Dev Server Compiles Dynamic Imports Dev Server Eagerly Compiles Dynamic Imports Nov 4, 2020
@timneutkens
Copy link
Member

This is how dynamic imports work in webpack unfortunately. cc @sokra

@ddgromit
Copy link
Author

ddgromit commented Nov 5, 2020

I was afraid of that. Any idea if Webpack 5 changes this behavior? I can't find anything that specifically references it in their changelog.

@awareness481
Copy link
Contributor

Webpack will always compile dynamic imports at build time and that behavior will probably never change. On dev mode however the bundles are less optimized.

The name dynamic comes from the behavior of the imports, where the file is only imported on demand. In reality, there is not such thing as a dynamic export in Webpack (and probably most other bundlers). All exports are static, meaning they happen at build time.

@ddgromit
Copy link
Author

ddgromit commented Nov 9, 2020

It sounds like the only way to reduce load times is to reduce the amount of dynamic imports used by each page. I'll focus on splitting this very large page up into multiple smaller NextJS pages.

Thank you for your feedback! Closing this issue since the dev server load times are inherent to Webpack rather than NextJS.

@ddgromit ddgromit closed this as completed Nov 9, 2020
@timneutkens timneutkens reopened this Nov 10, 2020
@timneutkens
Copy link
Member

Going to keep this open as we can potentially tackle it in the future.

@timneutkens timneutkens added template: story and removed bug Issue was opened via the bug report template. labels Nov 10, 2020
@timneutkens timneutkens added this to the iteration 13 milestone Nov 10, 2020
@awareness481
Copy link
Contributor

awareness481 commented Nov 16, 2020 •
edited
Loading

FWIW this seems to be on the roadmap for Webpack 5.

This webpack/webpack#8644 discussion has some interesting information. Including an npm package which I haven't tested, that defaults all dynamic imports to eager mode (no extra chunk). Obviously that should be used only for dev.

Ideally, if native support for webpackMode configuration is implemented that should be implementantion Next.js follows.

@ddgromit
Copy link
Author

I don't think webpackMode: eager solves this issue.

Tagging an import as webpackMode: eager tells Webpack to always include the file in the current entry point rather than generate a separate chunk. Either way, Webpack is still parsing the dynamically imported file when the dev server starts.

The performance gains in the linked issue involve chunk-creation overhead, not the time necessary to actually parse the files that make up the chunk in the first place.

@Timer Timer added the point: 3 label Nov 17, 2020
@timneutkens timneutkens modified the milestones: iteration 13, iteration 14 Dec 1, 2020
@Timer Timer modified the milestones: 10.x.x, backlog Jan 6, 2021
@timneutkens timneutkens added Webpack Related to Webpack with Next.js. and removed priority: stretch labels Nov 17, 2021
@jankaifer jankaifer self-assigned this Dec 1, 2022
@jankaifer jankaifer added the please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity label Dec 1, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Dec 1, 2022

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

@shehi
Copy link

shehi commented Dec 20, 2022 •
edited
Loading

Still happening (on latest Next 13.0.7 with classic pages setup, not app directory), something similar to this question on SO. It seemingly happens only on dev-env, causing worries. On dev, it only happens once when you first npm run dev. Consequitive attempts to replicate fail - the problem seemingly disappears.

Good question at this point is: Is it fixed with Turbopack? Or with the latest app directory of Next 13?

@jankaifer jankaifer removed the please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity label Dec 21, 2022
@fikrikarim fikrikarim mentioned this issue Jan 10, 2023
Merged
@jandylove
Copy link

same issue, how do you solve this now? @ddgromit

@vercel vercel locked and limited conversation to collaborators Apr 17, 2024
@balazsorban44 balazsorban44 converted this issue into discussion #64655 Apr 17, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Assignees

@jankaifer jankaifer

Labels
Webpack Related to Webpack with Next.js.
Projects
None yet
Milestone
backlog
Development

No branches or pull requests
7 participants
@ddgromit @Timer @shehi @timneutkens @awareness481 @jankaifer @jandylove