Development performance improvements

[vjpr]

After discussions with @timneutkens, here are several ways to make Next.js faster to work with during development.

• hard-source-webpack-plugin
• resolve.unsafeCache
• autodll-webpack-plugin - Share common deps with disk caching.
• Webpack@5 module disk cache ([spec: webpack 5] - A module disk cache between build processes webpack/webpack#6527)
• cache-loader - Caches the result of following loaders on disk
• Prebuild next.js pages on server start
• Allow multiple pages in the same bundle
• Reduce size of common deps
  • Lodash = babel-plugin-lodash + lodash-webpack-plugin + https://medium.com/making-internets/why-using-chain-is-a-mistake-9bc1f80d51ba

Metrics

• Server start time.
• Incremental build time for changes on same page (HMR).
• Direct page visit (typing in url).
• Navigating to new page via a link.
• SSR of React Component

Profiling tools

• Chrome DevTools --inspect - profile any part of the app (including flamecharts with a slightly easier workflow than ProfilerPlugin I think)
• ProfilerPlugin in Webpack@4 - generates flamecharts for builds
• webpackDevMiddleware.stats = 'verbose'
• Monkey-patch next build to show stats.toString()
• WebpackAnalyzePlugin
• require('perf_hooks') - https://nodejs.org/api/perf_hooks.html

[vjpr]

autodll-webpack-plugin

I tried this and it works quite well out of the box. The website says it will become obsolete soon because of hard-source and webpack@5, but its still quite useful today, especially for sharing deps between Next.js page bundles.

[timneutkens]

autodll-webpack-plugin has been implemented for react and react-dom at least 👍

[timneutkens]

resolve.unsafeCache is true by default apparently, so there's no gain there, unfortunately.

[timneutkens]

Implemented hard-source-webpack-plugin in #5181. Releasing it on canary right now.

[vjpr]

@timneutkens We should try webpack 5 with built-in disk cache https://twitter.com/TheLarkInn/status/1069246795031576576

[timneutkens]

@divmain is working on build optimizations, starting with this PR: #5810

[bz-stripe]

Have there been any updates on this work? Especially #4843

[kachkaev]

Possibly related issue (still needs investigation): #9153

[timneutkens]

We're investigating other optimizations currently.

[glopezep]

@timneutkens is it will be possible Allow multiple pages in the same bundle for development performance improvement #4843 ? because navigating is really slowly but only on development

[glopezep]

Does someone know what happened to this?

After discussions with @timneutkens, here are several ways to make Next.js faster to work with during development.

• hard-source-webpack-plugin

• resolve.unsafeCache

• autodll-webpack-plugin - Share common deps with disk caching.

• Webpack@5 module disk cache (webpack/webpack#6527)

• cache-loader - Caches the result of following loaders on disk

• Prebuild next.js pages on server start

• Allow multiple pages in the same bundle

• Reduce size of common deps

  • Lodash = babel-plugin-lodash + lodash-webpack-plugin + https://medium.com/making-internets/why-using-chain-is-a-mistake-9bc1f80d51ba

Metrics

• Server start time.
• Incremental build time for changes on same page (HMR).
• Direct page visit (typing in url).
• Navigating to new page via a link.
• SSR of React Component

Profiling tools

• Chrome DevTools --inspect - profile any part of the app (including flamecharts with a slightly easier workflow than ProfilerPlugin I think)
• ProfilerPlugin in Webpack@4 - generates flamecharts for builds
• webpackDevMiddleware.stats = 'verbose'
• Monkey-patch next build to show stats.toString()
• WebpackAnalyzePlugin
• require('perf_hooks') - https://nodejs.org/api/perf_hooks.html