Closed tomscript closed 1 year ago
can second this, been taking forever to switch routes and 30s compiles out of the blue, can't seem to find a fix
@ChristopherTrimboli just curious, could you share your dependencies? mine are:
"@emotion/styled": "^11.8.1",
"@google-cloud/error-reporting": "^2.0.5",
"@mui/icons-material": "^5.10.9",
"@mui/joy": "^5.0.0-alpha.65",
"@mui/material": "^5.11.7",
"@mui/x-data-grid": "^5.17.21",
"agora-access-token": "^2.0.4",
"agora-rtc-sdk-ng": "^4.11.0",
"authorizenet": "^1.0.8",
"colors": "^1.4.0",
"encoding": "^0.1.13",
"firebase": "^9.6.11",
"firebase-admin": "^10.0.2",
"firebaseui": "^6.0.1",
"image-size": "^1.0.1",
"mandrill-api": "^1.0.45",
"next": "^13.1.6",
"next-redux-wrapper": "^7.0.5",
"react": "^18.2.0",
"react-creditcard-validator": "^1.0.6",
"react-dom": "^18.2.0",
"react-firebase-hooks": "^5.0.3",
"react-google-recaptcha": "^2.1.0",
"react-hook-form": "^7.40.0",
"react-minimal-side-navigation": "^1.9.2",
"react-otp-field": "^2.1.0",
"redux": "^4.2.0",
"redux-thunk": "^2.4.1",
"sass": "^1.49.11",
"sharp": "^0.31.1",
"short-time-ago": "^2.0.0",
"swr": "^1.3.0",
"useragent": "^2.3.0"
Same. 30s compile/refresh times, navigating is also super slow. I have to hard-reload the page many times because the refresh doesn't work or is too slow. Sometimes I also have to kill and restart the next dev
server (not using --turbo
because it doesn't work with my Next.js configuration).
Uploaded build trace: trace.txt
Dependencies:
"dependencies": {
"@radix-ui/react-checkbox": "1.0.1",
"@radix-ui/react-dropdown-menu": "2.0.2",
"@radix-ui/react-switch": "1.0.1",
"@sentry/nextjs": "7.35.0",
"@sentry/react": "7.35.0",
"@sentry/tracing": "7.35.0",
"@tippyjs/react": "4.2.6",
"await-to-js": "3.0.0",
"clsx": "^1.2.1",
"color": "4.2.3",
"d3": "7.8.2",
"d3-bboxCollide": "1.0.4",
"date-fns": "2.29.3",
"framer-motion": "9.0.0",
"graphql": "16.6.0",
"graphql-request": "5.1.0",
"immutable": "4.2.2",
"iso8601-duration": "2.1.1",
"lodash-es": "4.17.21",
"mixpanel-browser": "2.45.0",
"next": "13.1.6",
"numbro": "2.3.6",
"react": "18.2.0",
"react-beforeunload": "2.5.3",
"react-dropzone": "14.2.3",
"react-icons": "4.7.1",
"react-wrap-balancer": "0.4.0",
"server-only": "0.0.1",
"transform-parser": "1.0.1",
"vega": "5.22.1",
"vega-embed": "6.21.0",
"vega-lite": "5.6.0"
},
"devDependencies": {
"@next/eslint-plugin-next": "13.1.6",
"@types/node": "18.11.18",
"@types/react": "18.0.27",
"@typescript-eslint/eslint-plugin": "5.50.0",
"@typescript-eslint/parser": "5.50.0",
"auto-changelog": "2.4.0",
"autoprefixer": "10.4.13",
"depcheck": "1.4.3",
"eslint": "8.33.0",
"eslint-config-next": "13.1.6",
"eslint-config-prettier": "8.6.0",
"eslint-plugin-jsx-a11y": "6.7.1",
"eslint-plugin-react": "7.32.2",
"eslint-plugin-react-hooks": "4.6.0",
"node-jq": "2.3.5",
"npm-check-updates": "16.6.3",
"postcss": "8.4.21",
"prettier-plugin-tailwindcss": "0.2.2",
"sharp": "0.31.3",
"source-map-explorer": "2.5.3",
"tailwindcss": "3.2.4",
"typescript": "4.9.5"
},
Looking at the dependency list both have either react-icons
or @mui/icons-material
installed which have known slowdowns. Can you provide the .next/trace
file following the instructions here: https://github.com/vercel/next.js/issues/29559#issuecomment-938431883. That issue might also be useful for tracking down known slowdowns from using certain dependencies.
In this case can you make sure to delete .next
before collecting the trace in order to make sure all modules are listed? In @mpereira case it's only showing restoring modules from cache and not exactly which modules.
Additionally: Are you referring to the app
directory or using pages
?
@timneutkens thanks for taking a look. Here's a new trace following your instructions: trace.txt
My application is app
-directory based.
@mpereira Could you share the output of next info
? I'm seeing 8.7s spent on server compilation and 8 seconds spent on client compilation. Part of this is react-icons
but a lot of the overhead seems to be reading files that is slow so I'm curious if you're on Windows and if so if you have Windows defender enabled, this has a known filesystem reading overhead (for any file reading, not Next.js specific).
You can visualize the trace yourself using https://github.com/vercel/next.js/blob/canary/scripts/trace-to-tree.mjs node scripts/trace-to-tree.mjs /path/to/trace
if you're curious.
@timneutkens I'm on macOS:
$ npx next info
Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64
Binaries:
Node: 18.12.1
npm: 8.19.2
Yarn: 1.22.18
pnpm: N/A
Relevant packages:
next: 13.1.6
eslint-config-next: 13.1.6
react: 18.2.0
react-dom: 18.2.0
warn - Latest canary version not detected, detected: "13.1.6", newest: "13.1.7-canary.5".
Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
Read more - https://nextjs.org/docs/messages/opening-an-issue
I don't know if it's incidental, but I also noticed that the dev server was faster after nuking the build directory and restarting it (reflected in the last trace file I attached).
also on macOS, what I found:
import { MoreVertRounded } from '@mui/icons-material';
instead of
import MoreVertRoundedIcon from '@mui/icons-material/MoreVertRounded';
As is recommended in https://mui.com/material-ui/icons/#usage. TIL ! I also had a bunch of places where I did the same with mui such as import { IconButton } from '@mui/material';
instead of import IconButton from '@mui/material/IconButton';
I then compared a trace before and after, here's a snippet from before:
├─ module /Users/tomfitzgerald/Documents/projects/auction/live/nextjs/app/admin/Sidebar.tsx 2.4s (total 597 ms, self 18 ms) [next-swc-loader 17 ms]
[...]
├─ module @mui/icons-material (@mui/icons-material/Edit.js + 1) 2.4s (total 41 ms, self 89 ms) [read-resource 88 ms]
2.4s to load an icon. Seems awfully unusual since that page was already in the recommended import import EditIcon from '@mui/icons-material/Edit';
.
in the after trace
├─ module /Users/tomfitzgerald/Documents/projects/auction/live/nextjs/app/admin/Sidebar.tsx 292 ms (total 216 ms, self 6.1 ms) [next-swc-loader 5.2 ms]
[...]
├─ module @mui/icons-material (@mui/icons-material/Edit.js + 1) 213 ms (total 39 ms, self 64 ms) [read-resource 63 ms]
I did take this opportunity to fix all the other recommendations for the imports I had wrong with @mui/material. The speed is certainly much better! I wonder if all the inefficient imports were just slowing things down overall which would cause seeming
ly unrelated icon imports to take longer.
The trace and the next.js script to visualize it is incredibly helpful! I see a few other things that take > 1s so I can dive into those.
Curious if other folks encounter the same findings.
Here's a project-wide grep for react-icons
, fwiw:
import { AiOutlineFundView, AiOutlineLineChart } from 'react-icons/ai';
import { AiTwotoneEdit } from 'react-icons/ai';
import { BiExport } from 'react-icons/bi';
import { CgArrowsBreakeH, CgArrowsMergeAltH } from 'react-icons/cg';
import { CgHeart } from 'react-icons/cg';
import { CgLock } from 'react-icons/cg';
import { FaRegSave } from 'react-icons/fa';
import { FaRetweet } from 'react-icons/fa';
import { FaUserCircle } from 'react-icons/fa';
import { FiDatabase } from 'react-icons/fi';
import { GiHamburgerMenu } from 'react-icons/gi';
import { GiPartyPopper } from 'react-icons/gi';
import { HiCheck } from 'react-icons/hi';
import { ImEmbed2 } from 'react-icons/im';
import { IoAnalyticsSharp } from 'react-icons/io5';
import { IoIosEye } from 'react-icons/io';
import { MdPublic } from 'react-icons/md';
import { MdVerified } from 'react-icons/md';
import { RiTeamLine } from 'react-icons/ri';
import { SiOpenai } from 'react-icons/si';
import { SlSupport } from 'react-icons/sl';
import { TbReplace } from 'react-icons/tb';
import { TiChartLine } from 'react-icons/ti';
import { VscChromeClose } from 'react-icons/vsc';
I have the same problem.
> export NODE_OPTIONS='--max_old_space_size=6096' && next dev
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
warn - No utility classes were detected in your source files. If this is unexpected, double-check the `content` option in your Tailwind CSS configuration.
warn - https://tailwindcss.com/docs/content-configuration
event - compiled client and server successfully in 2.2s (165 modules)
#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 169220804
#
#
#
#FailureMessage Object: 0x7ff7b44351d0
1: 0x10bbfbd22 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/usr/local/bin/node]
2: 0x10cde8a83 V8_Fatal(char const*, ...) [/usr/local/bin/node]
3: 0x10bead8b6 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArray(int, v8::internal::AllocationType) [/usr/local/bin/node]
4: 0x10c08ab74 v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/usr/local/bin/node]
5: 0x10c2df1f7 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
6: 0x10c6e1f79 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/usr/local/bin/node]
npx next info
Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 22.3.0: Thu Jan 5 20:53:49 PST 2023; root:xnu-8792.81.2~2/RELEASE_X86_64
Binaries:
Node: 18.13.0
npm: 8.19.3
Yarn: 1.22.10
pnpm: 6.7.4
Relevant packages:
next: 13.1.6
eslint-config-next: 13.1.6
react: 18.2.0
react-dom: 18.2.0
warn - Latest canary version not detected, detected: "13.1.6", newest: "13.1.7-canary.17".
Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
Read more - https://nextjs.org/docs/messages/opening-an-issue
node trace-to-tree.mjs .next/trace
Explanation:
module /Users/next-user/src/magic-ui/pages/index.js 24s (total 33s, self 163 ms) [read-resource 873 µs, next-babel-turbo-loader 135 ms]
════════╤═══════════════════════════════════ ═╤═ ═╤═ ═╤════ ═══════════╤════════════════════════════════════════
└─ name of the processed module │ │ │ └─ timings of nested steps
│ │ └─ building the module itself (including overlapping parallel actions)
│ └─ total build time of this modules and all nested ones (including overlapping parallel actions)
└─ how long until the module and all nested modules took compiling (wall time, without overlapping actions)
module lodash (lodash/camelCase.js + 281) 295 ms (self 958 ms) [read-resource 936 ms]
═╤════ ══════╤════════════ ═╤═
│ │ └─ number of modules that are merged into that line
│ └─ first module that is imported
└─ npm package name
hot reloader
├─ start 65 ms (self 3 µs)
│ ├─ clean 4.9 ms
│ └─ get-webpack-config 59 ms
│ ├─ get-page-paths 1.5 ms
│ ├─ create-pages-mapping 550 µs
│ ├─ create-entrypoints 2.9 ms
│ └─ generate-webpack-config 54 ms
├─ client compilation 2.5s
│ ├─ entry _next@13.1.6@next/dist/compiled/@next/react-refresh-utils/dist/runtime.js
│ ├─ entry _next@13.1.6@next/dist/client/dev/amp-dev
│ ├─ entry _next@13.1.6@next/dist/client/next-dev.js
│ ├─ entry next-client-pages-loader?absolutePagePath=private-next-pages%2F_app&page=%2F_app!
│ ├─ entry _next@13.1.6@next/dist/client/router.js
│ ├─ entry next-client-pages-loader?absolutePagePath=private-next-pages%2F_error&page=%2F_error!
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/build/webpack/loaders/next-client-pages-loader.js?absolutePagePath=private-next-pages%2F_app&page=%2F_app!) 2.1s (total 1.9s, self 22 ms) [next-client-pages-loader 883 µs]
│ │ └─ module /Users/yunfeng/code/media-part/clipmedias.tools/src/pages/_app.tsx 1.9s (total 1.9s, self 13 ms) [next-swc-loader 4.8 ms]
│ │ ├─ module _react@18.2.0@react (_react@18.2.0@react/jsx-dev-runtime.js + 1) 30 ms (self 102 ms) [read-resource 80 ms]
│ │ └─ module /Users/yunfeng/code/media-part/clipmedias.tools/src/styles/globals.css 1.1s (total 1.9s, self 4.2 ms) [next-style-loader 889 µs]
│ │ ├─ module /Users/yunfeng/code/media-part/clipmedias.tools/src/styles/globals.css 1.1s (total 974 ms, self 971 ms) [read-resource 22 ms, postcss-loader 890 ms, css-loader 34 ms]
│ │ │ └─ module _next@13.1.6@next (_next@13.1.6@next/dist/build/webpack/loaders/css-loader/src/runtime/api.js) 2.7 ms [read-resource 1.9 ms]
│ │ └─ module _next@13.1.6@next (_next@13.1.6@next/dist/build/webpack/loaders/next-style-loader/runtime/injectStylesIntoStyleTag.js) 904 ms [read-resource 902 ms]
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/build/webpack/loaders/next-client-pages-loader.js?absolutePagePath=private-next-pages%2F_error&page=%2F_error!) 4 ms [next-client-pages-loader 430 µs]
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/compiled/@next/react-refresh-utils/dist/runtime.js + 3) 180 ms (self 344 ms) [read-resource 330 ms]
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/client/next-dev.js + 48) 2.1s (total 420 ms, self 4.5s) [next-swc-loader 3s, read-resource 1.1s]
│ │ ├─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_interop_require_wildcard.js) 78 ms [read-resource 77 ms]
│ │ ├─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_extends.js) 78 ms [read-resource 78 ms]
│ │ ├─ module _react-dom@18.2.0@react-dom (_react-dom@18.2.0@react-dom/client.js) 26 ms [read-resource 25 ms]
│ │ ├─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_object_without_properties_loose.js) 27 ms [read-resource 27 ms]
│ │ └─ module _react-dom@18.2.0@react-dom (_react-dom@18.2.0@react-dom/index.js + 1) 1.2s (total 55 ms, self 216 ms) [read-resource 59 ms]
│ │ └─ module _scheduler@0.23.0@scheduler (_scheduler@0.23.0@scheduler/index.js + 1) 662 µs (self 4.1 ms) [read-resource 497 µs]
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/client/dev/amp-dev.js + 3) 776 ms (total 279 ms, self 194 ms) [next-swc-loader 67 ms]
│ │ ├─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_async_to_generator.js) 77 ms [read-resource 77 ms]
│ │ └─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_interop_require_default.js) 77 ms [read-resource 76 ms]
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/client/router.js + 31) 789 ms (total 189 ms, self 1.2s) [next-swc-loader 947 ms, read-resource 101 ms, build-module 1.1 ms]
│ │ └─ module _react@18.2.0@react (_react@18.2.0@react/index.js + 1) 30 ms (self 135 ms) [read-resource 102 ms]
│ ├─ webpack-compilation-seal 247 ms
│ ├─ webpack-compilation-chunk-graph 7.1 ms
│ ├─ webpack-compilation-optimize 1.3 ms
│ ├─ webpack-compilation-optimize-modules 38 µs
│ ├─ webpack-compilation-optimize-chunks 452 µs
│ ├─ webpack-compilation-optimize-tree 155 µs
│ ├─ webpack-compilation-hash 29 ms
│ ├─ NextJsBuildManifest-createassets 2 ms
│ └─ NextJsBuildManifest-generateClientManifest 1.2 ms
├─ make 2.2s
├─ emit 79 ms
├─ server compilation 135 ms
│ ├─ entry private-next-pages/_app
│ ├─ entry private-next-pages/_document
│ ├─ entry private-next-pages/_error
│ ├─ module /Users/yunfeng/code/media-part/clipmedias.tools/src/pages/_document.tsx 53 ms (total 6.4 ms, self 5 ms) [next-swc-loader 3.7 ms]
│ │ └─ module _next@13.1.6@next (_next@13.1.6@next/document.js + 3) 42 ms (total 1.3 ms, self 30 ms) [read-resource 2.2 ms, next-swc-loader 14 ms]
│ │ ├─ module ../shared/lib/constants 22 µs
│ │ ├─ module ../shared/lib/html-context 14 µs
│ │ ├─ module ../server/get-page-files 24 µs
│ │ ├─ module ../server/htmlescape 48 µs
│ │ ├─ module ../server/utils 17 µs
│ │ └─ module ../shared/lib/is-plain-object 33 µs
│ ├─ module /Users/yunfeng/code/media-part/clipmedias.tools/src/pages/_app.tsx 15 ms (total 4.4 ms, self 2.2 ms) [next-swc-loader 991 µs]
│ │ ├─ module react/jsx-dev-runtime 199 µs
│ │ └─ module /Users/yunfeng/code/media-part/clipmedias.tools/src/styles/globals.css 2 ms [read-resource 1.4 ms]
│ ├─ module _next@13.1.6@next (_next@13.1.6@next/dist/pages/_error.js + 1) 37 ms (total 11 ms, self 9.5 ms) [next-swc-loader 4.4 ms]
│ │ ├─ module react 34 µs
│ │ ├─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_interop_require_default.js) 693 µs [read-resource 206 µs]
│ │ ├─ module ./side-effect 33 µs
│ │ ├─ module ./head-manager-context 18 µs
│ │ ├─ module ./amp-context 12 µs
│ │ ├─ module ./amp-mode 30 µs
│ │ ├─ module ./utils/warn-once 14 µs
│ │ ├─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_extends.js) 2.6 ms [read-resource 2.1 ms]
│ │ └─ module _@swc_helpers@0.4.14@@swc (_@swc_helpers@0.4.14@@swc/helpers/lib/_interop_require_wildcard.js) 3.2 ms [read-resource 2.5 ms]
│ ├─ webpack-compilation-seal 19 ms
│ ├─ webpack-compilation-chunk-graph 582 µs
│ ├─ webpack-compilation-optimize 473 µs
│ ├─ webpack-compilation-optimize-modules 7 µs
│ ├─ webpack-compilation-optimize-chunks 122 µs
│ ├─ webpack-compilation-optimize-tree 43 µs
│ └─ webpack-compilation-hash 2.1 ms
├─ make 114 ms
├─ emit 4.2 ms
├─ edge-server compilation 6.2 ms
│ ├─ webpack-compilation-seal 1.1 ms
│ ├─ webpack-compilation-chunk-graph 35 µs
│ ├─ webpack-compilation-optimize 111 µs
│ ├─ webpack-compilation-optimize-modules 6 µs
│ ├─ webpack-compilation-optimize-chunks 11 µs
│ ├─ webpack-compilation-optimize-tree 8 µs
│ └─ webpack-compilation-hash 93 µs
├─ make 2.3 ms
└─ emit 22 ms
Hi everyone! Having the same problem.
I use react-icons
and the "app folder approach", and curiously enough I have almost exactly the same results as @mpereira.
event - compiled client and server successfully in 8.1s (4209 modules)
I don't experience just slow build, but also very slow navigation between pages. Everything is fine on production however.
Situation slightly improved for me when I've changed the method of importing the react-icons
.
Before: import { IoMdClose } from 'react-icons';
After: import { IoMdClose } from @react-icons/all-files/io/IoMdClose
After thus change my build time decreased to approx 1.5s (much better, even though still not ideal), navigating between the pages also feel a bit faster.
The react-icons
documentation is a bit mysterious about why this should be used and what does it achieve:
If your project grows in size, this option is available. This method has the trade-off that it takes a long time to install the package.
I'm also encountering super slow build times and page transitions with the app
dir.
My site is only 2 static pages and one dynamic slug page. I'm on a 2021 M1 Macbook with 32gb of ram:
@timneutkens here's my trace: trace.txt
I'm not using react-icons
. I am using react-feather
which could have a similar issue but it's not a massive icon set.
Thanks for the help!!
Same when using @icon-park/react
@jamesvclements try adding a next.config like below, (this helped me reduce from 20k modules to 500):
module.exports = {
modularizeImports: {
'@mui/icons-material/?(((\\w*)?/?)*)': {
transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}'
}
},
I'm having a similar situation. We've migrated from v12 to v13 and now the compile times became really long.
I takes more than 60 secs to compile a page.
Using app dir.
Here I have a the trace trace.txt.
Dependencies:
"pnpm": {
"overrides": {
"@walletconnect/ethereum-provider": "2.7.4",
"@walletconnect/universal-provider": "2.7.6"
}
},
"dependencies": {
"@headlessui/react": "^1.7.2",
"@next/env": "^12.2.2",
"@pushprotocol/restapi": "^0.3.1",
"@svgr/webpack": "^6.2.1",
"@walletconnect/encoding": "^1.0.2",
"alchemy-sdk": "^2.1.0",
"classnames": "^2.3.1",
"encoding": "^0.1.13",
"eslint": "8.40.0",
"eslint-config-next": "13.4.1",
"ethers": "5.6.9",
"lodash": "^4.17.21",
"lokijs": "1.x",
"next": "13.4.5-canary.2",
"next-auth": "^4.22.1",
"pino-pretty": "^10.0.0",
"react": "18.2.0",
"react-device-detect": "^2.2.2",
"react-dom": "18.2.0",
"react-icons": "^4.4.0",
"react-jazzicon": "^1.0.4",
"react-swipeable": "^7.0.0",
"react-use": "^17.4.0",
"siwe": "^2.1.4",
"wagmi": "0.12.13"
},
"devDependencies": {
"@portabletext/react": "^1.0.6",
"@types/node": "20.1.0",
"@types/react": "18.2.6",
"autoprefixer": "^10.4.7",
"cross-env": "^7.0.3",
"postcss": "^8.4.13",
"postcss-import": "^14.1.0",
"tailwindcss": "^3.0.24",
"typescript": "^4.5.3"
}
}
Anyone could solve this?
@federicolopezeikilis had a look at the trace for your application. The main cause seems to be two issues:
.css
files to take over 10 seconds to compile. Potentially this is related to the filesystem slowness though because tailwind will also read files.Some observations:
react-use
is imported which seems to be a barrel file with 113 re-exports which are all compiled regardless of if you're using a single method. Because of the filesystem slowness this amounts to 113*50ms (5.6 seconds at least)@jamesvclements had a look at your trace.
Observations:
generateWebpackConfig
, takes 13.67s
react-feather
, will likely want to use modularizeImports
for thismedia-chrome
Hello @timneutkens I turned off the windows defender and changed the postcss to the default file provided by create-next-app boilerplate, but it still take a long time to compile.
Here you have the new trace: trace.txt
Regarding the react-use issue you mentioned ("react-use is imported which seems to be a barrel file with 113 re-exports which are all compiled regardless of if you're using a single method"), what do you propose to solve it?
We used next12 for a long time before in this project and we hadn't had any problem like this with the compiling time. What's your take on this?
let's hope that 13.4.5 fixes it, I see lots of performance commits coming in Canary: https://github.com/vercel/next.js/pull/50792
hi @timneutkens
i am a colleague of @federicolopezeikilis and i have brand new macbook pro. and i experience a similar abnormal compiling time. no so much, but around 30s or even more. here is the trace file: trace.txt
as @federicolopezeikilis stated, this was not happening in next 12, so we understand that there is something else (maybe something not detected yet?) in the next 13 building process that is causing this long delays in the building / compiling times. we can see in the console that apparently compiling is short (in my mac), but when if first load a page in the app, it takes very long to be processed and consequently shown on screen.
we appreciate your help on this topic, as for us is right now a noticeable inconvenient for the development team.
I'm going to consolidate all of these issues into one issue given that they're all roughly the same.
Closing in favor of https://github.com/vercel/next.js/issues/48748. Please see this comment: https://github.com/vercel/next.js/issues/48748#issuecomment-1578374105
@federicolopezeikilis @manuelbarzi I'll reply to both of your comments over there.
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
App directory (appDir: true)
Link to the code that reproduces this issue
https://github.com/auction-engine/live
To Reproduce
npm run dev
then attempt to navigate to pags using will take on average 10 seconds.Describe the Bug
Basically when I develop locally with
npm run dev
I get long compile times (10s+) [0] and very slow route change times (click a link, wait 10s before route changes.) This all has happened since migrating to the new apps directory with NextJS 13. I also recently had several "JavaScript heap out of memory" crashes [1], all is well with prod.I have repo in a private repository I'm happy to share access
[0]
[1]
Expected Behavior
Would expect fast load times and navigation as I see in prod and how it was locally prior to NextJS 13.
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response