Slow "> Building page:"

[tashburn]

In dev mode, Next takes 26+ seconds to build a page for me.

DONE Compiled successfully in 26253ms

This has become a major pain during development, each time I change code.

I presume this is because I have lots of npm packages (48), or they are large/complex.

Do others experience this?

Can anything be done to speed this up, besides removing packages?

[arunoda]

Use the webpack analyzer and see what are the packages in your app: https://github.com/zeit/next.js/tree/v3-beta/examples/with-webpack-bundle-analyzer

You may be using some server side NPM modules or some unwanted modules.
Try to get rid of them.

[tashburn]

@arunoda Thanks.

Any idea if incremental webpack compilation is on the horizon?

[arunoda]

@tashburn we already do that.
We only compile only the page you are viewing.

BTW: Double check whether you are using the latest version of Next.js

[brentmclark]

@tashburn I have the same problem. I just started the troubleshooting process today.

[arunoda]

If anyone of you can send me the repo, I can have a look at this.

[tashburn]

@brentmclark Super, thanks!

[chaffeqa]

hey @arunoda wanted to send you a (trimmed down) repo demonstrating what our company (@brentmclark and myself) are experiancing: repo

The part I want to point out is: when running (yarn run dev:start) you will land on a page that has a link to a second page. That is our optimized link.
However, on the second page, if you click on either the root (which is an already built page) or the "third page" which is an unbuilt page, both take event a few seconds to build.

Now those are extremely light pages, our real app has over 600kb of styles, and a ton more components ect for each page, moving the build page time up to 5-10 seconds. However the fact that these trimmed down pages still take few seconds to load is the issue to me.

Any thoughts?

[brentmclark]

@tashburn, FWIW @chaffeqa discovered a config setting that we are trying out coupled with a healthy dose of prefetching. 24 hours may be the wrong length of time; we are fine tuning as we go.

Toss this into a next.config.js (or modify your existing one). onDemandEntries is sibling to the webpack property.

module.exports = {
  onDemandEntries: {
    // on dev, since our pages are so expensive, lets keep them for 24 hours
    maxInactiveAge: 1000 * 60 * 60 * 24,
  },
}

Increasing the maxInactiveAge really only addresses the symptom, not the root problem. however, it had a sizable impact on our developer experience.

---

Also, we hadn't run a yarn install in a while. When I ran one, I found that several of our dependencies had minor and/or patch updates. After running rm -rf ./node_modules && rm yarn.lock && yarn install my compile times dropped by about 50%.

These things are purely anecdotal, but if they can bring you similar results that would be great!

[arunoda]

@chaffeqa The app build time seems pretty standard to me. See:

I checked the bundle and seems like you can get rid of some of the modules which are marked in red. (I assume they are server only modules)

Anyway, try to load those modules as on-demand modules with dynamic imports.

---

As a long term solution we are looking to use the autodll plugin (#2433) or some other caching machanism to make the dev re-build time smaller.

[arunoda]

BTW: Apollo client seems to be pretty big too.

[rauchg]

It's part of our very near-term roadmap to dramatically speed up compilation performance, both for dev and prod. A big part of that is doing less work.

[rauchg]

(e.g..: webpack tends to redo the whole project from scratch every time you start it up. There's a lot of time to save there)

[tashburn]

@brentmclark Thanks for the suggestions. The onDemandEntries setting will just prevent the unmounting of pages within 24h, yes? If so, that will definitely help some.

I tried updating to the very latest version of Next, and i reinstalled all my modules per your suggestion (thanks). My dev build times have not really changed -- startup is still 6-9s (which happens whenever I change server code), and one of my key pages takes 9-29s. Not sure why there's so much variability in the time taken.

@arunoda I used the Webpack Bundle Analyzer and was able to remove maybe 10% of my modules. A modest improvement.

@rauchg said It's part of our very near-term roadmap to dramatically speed up compilation performance, both for dev and prod. Love it! That will make a huge impact.

[arunoda]

My dev build times have not really changed -- startup is still 6-9s (which happens whenever I change server code), and one of my key pages takes 9-29s.

I assume what's happening here is webpack restarts from the scratch.

[chaffeqa]

Thanks @arunoda for looking! So that repo was an copy of our actual project, however I removed all the actual components (pages) and instead made those x3 "mock routes" (I did that to not disclose business data). I left all the dependencies in though that we used, as well as imported them, just to help demonstrate the performance with those dependencies.

Unfortunately most of those dependencies are required in the common chunk since they are consumed by redux, which is required on every page obviously.

So you are correct on the compilation times being "normal", however the main issue I'm referring to with that "sample" app is that: try starting at http://localhost:8000, then click Route Two, then on that click Root. You will see a 404 page for 1 second, then the page loads. No rebuild.

> Building page: /route-one
 DONE  Compiled successfully in 4414ms                                                                                                                                                                                                                                  04:48:05
GET / 200 5202.810 ms - 3329
GET / 200 9.402 ms - 3328
 WAIT  Compiling...                                                                                                                                                                                                                                                     04:48:06
> Building page: /route-two
 DONE  Compiled successfully in 1820ms                                                                                                                                                                                                                                  04:48:08
GET / 200 137.186 ms - 3328
Client pings, but there's no entry for page: /
GET / 200 9.760 ms - 3329
GET / 200 10.049 ms - 3328
Client pings, but there's no entry for page: /
GET / 200 6.781 ms - 3329
GET / 200 10.076 ms - 3328

I think thats a root route issue (route matching?).

The second being: from there, go back to Route Two and click Route Three (which has not been built). That hangs after clicking for ~3 seconds, then renders the page. This is the normal slowness we are all referring to, fixed probably by DLL significantly.

I saw the DLL pull request actually earlier this week and was pumped for that, that's probably the dev experience win. I did want to reach out and mention that my experience with the DLL plugin is that it's got tough edge cases to deal with (much like hot reloader). So I'd advise to do similar to what react-boilerplate did and make it opt-out-able. Mainly for you're own github issue sanity 😉

The last thing I'd like to mention in ideas is: potentially making next-routes a first class citizen of next.js. I say this because we were able to use that plus the preload and dev-prebuild optimizations to make a way more performant and standard router (@tashburn you may want to look into this for your dev issue), not to mention the redirectUrl option that was a huge user experience win, and we used it in our <Link /> component).

PS feel free to use that repo for any ideas/performance testing

[brentmclark]

@tashburn yep, the onDemandEntries change will simply prevent page unmounting for 24 hours.

[marbemac]

Our two cents - now that we're fully migrated over to next, we're seeing issues similar to @chaffeqa - particularly since every page requires most of our JS because of our mobx stores (like what is described above with redux).

In addition, we get the memory fault described in #282 at least a few times a day (much more for team members with less powerful computers).

We moved from base webpack + dll plugin, which did not have any of these issues. There was a longer startup cost (60s), but subsequent pages did not have to rebuild, and we did not run into memory leaks. This is a MUCH nicer dev experience imho, since we only really need to do a cold start once or twice a day, but we're constantly navigating pages.

Question 1: is there a way to compile all the pages on server start (to disable the on demand page fetching)?

Question 2: If there is anything that we can try to help this situation and speed up our development? DDL plugin sounds promising (and helped us before) - particularly since we load heavy dependencies like https://github.com/codemirror/CodeMirror, https://github.com/jpuri/react-draft-wysiwyg, and https://github.com/Semantic-Org/Semantic-UI-React.

Above complaints aside, thanks for all the hard work that's been put into next - it's a fantastic library :).

[pruhstal]

Any progress towards this?

Just started with next, myself, and noticed this same pattern.

Initial load is long (along with any loads to subsequent routes), but afterwards navigating to any route that has already loaded previously is pretty quick.

If you idle on the site for awhile, the pattern repeats itself.

[pruhstal]

@tashburn @chaffeqa @brentmclark I think I've narrowed this down to the postcss-import and postcss-easy-import being the bottleneck.

Can you try removing that and tell me if it's faster?

[chaffeqa]

Maybe, its tough for me to tell if its much faster, but it may be!

[tashburn]

@pruhstal I'm not using postcss

[pruhstal]

@tashburn @chaffeqa that was a red herring for me. At this point, it's almost unusable.

[timneutkens]

We're going to integrate webpack dll in Next v5

[ianregister]

I was suffering long full page refreshes. Turned out to be an issue with OSX and IPv6 and resolving addresses in the hosts file.

The issue was around using .local as an extension on my ... local ... machine. The DNS resolver would time out after 20+ seconds. Something to do with .local being reserved by the OS.

This hit me recently as my local Next.js site is pulling from a locally hosted API.

This is the first part of my hosts file. Adding entries to the ::1 line removed the long wait.

# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost example.local
fe80::1%lo0 localhost

127.0.0.1 example.local