Super slow page load times in development environment

[arthurva]

I've built an app using Next.js 9.5.5. It works really fast on production (or locally after build=>start).

The problem is with the dev environment - It takes about 30 seconds to do a full reload.

By checking the "Network" tab in the developer tools, I was able to see that it takes 15s-30s to load each of the files main.js, _app.js and index.js.

In the following photo, the download of _app.js took 15.72 seconds, the file size is 1.7MB. Since I'm running it locally, I would expect it to work much faster.

I know I can reduce the file size by using lazy loading modules, but shouldn't it load faster as is?

Would appreciate any help

[holgerw]

@arthurva Did you find an answer to the question if this response time is expected for a full page reload during development?

I am experiencing a similar loading time. Im my case it is 5 seconds, but the resource _app.js is even larger (3.2 MB transferred, 42 MB uncompressed).

I guess this long time goes into bundling. Fast Refresh also exists to have instant feedback when editing a page. But once in a while I prefere to reload the page completely. Like you I also wonder if this long page load time is really expected.

[ellioseven]

I'm experiencing the same result on a large application, it takes minutes on initial boot and then quite some time for the fast refresh to complete. I can't find any output on what's going on behind the scenes, what exactly is being compiled and how long it's taking. Are there any resources I can use to analyse/troubleshoot?

[Ebdulmomen1]

did you find any answer?
having same problem

[ellioseven]

@AbdulmomenAhmed

I managed to get some output by adding the webpack Progress Plugin to next.config.js:

config.plugins.push(
  new webpack.ProgressPlugin((percentage, message, ...args) => {
    // e.g. Output each progress message directly to the console:
    console.info(percentage, message, ...args);
  })
);

[KSrahul]

config.plugins.push(
  new webpack.ProgressPlugin((percentage, message, ...args) => {
    // e.g. Output each progress message directly to the console:
    console.info(percentage, message, ...args);
  })
);

Hey, what is config here?

[insivika]

Are you guys using getStaticProps in conjunction with getStaticPaths on dynamic pages? I experienced the same issues and unfortunately only after converting all dynamic pages to use getServerSideProps the situation improved significantly.

[diyorbek]

I am already using getServerSideProps but pages are still slow. :(

[MonMohon]

me too having same issue in local dev i'm terrifying about server

[nwashangai]

Guys this is the actual solution for this problem, just convert to getServersideProps

[AdamDiament]

I experience this, about 1 min to run next dev and very slow to do link transitions using next/link. It makes developing with vercel quite painful sometimes.

[GGAlanSmithee]

I agree with this sentiment. Both page navigations and api calls to pages/api/.. are painfully slow even in a not to large code base, killing the entire devx. If I understand it correctly next.js loads the pages dynamically, which is nice (I love the server-side hot reload of api pages), but it's just to slow atm. Would the potential upcomming perf improvement (10x? 👍👍) perhaps address this issue?

[timneutkens]

Can you provide an app to look at? There's cases we've seen when a reproduction was provided where fast refresh takes extremely long (more than 2s max), majority of these were related to custom configuration (webpack/babel/postcss customization) especially with TailwindCSS without tailwind-jit.

[GGAlanSmithee]

@timneutkens

In my case, I do have a custom next.js config, but a simple one. I also have a custom server, which slows down the original startuptime, but shouldn't affect hot-reloading, right?

My repo is private, but I sent you an invite if you'd like to have a look.

Thanks in advance!

[GGAlanSmithee]

In my case, the issue was with the custom server. Not exactly sure why though. It was doing some websockets communication, but as far as being a webserver goes it was just the vanilla next.js one.

Anyhow, I split it up into two servers and now next.js is behaving as expected.

[eizo371]

Thnk i like it

…

On Wed, 19 May 2021, 02:07 Alan Smithee, ***@***.***> wrote: @timneutkens <https://github.com/timneutkens> In my case, I do have a custom next.js config, but a simple one. I also have a custom server, which slows down the original startuptime, but shouldn't affect hot-reloading, right? My repo is private, but I sent you an invite if you'd like to have a look. Thanks in advance! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17977 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUDSHSPNOB7HB6HPOOOI7BTTOKUHJANCNFSM4SURSZIQ> .

[tunztunztunz]

Has anyone figured out what causes this? I'm using TailwindCSS and it takes at least 5seconds between pages in development, but it's very snappy when hosted. This site is really small too, so there's really no reason it should be doing this unless there's something adding to the development compile time...or?

[mvmmarcus]

In my case, this problem was solved just clearing my data configs on the tab aplication > storage in Chrome

[mvmmarcus]

Surprisingly this worked for me too, is this something that can occur for users visiting the site once it's live?

And what is causing this to happen?

My suposing is that this error ocurring when i start a production version of my application in localhost (using yarn build, then yarn start) a lot of times. Im doing this because i need to test the getStaticProps Method

[ro0t]

Yeah that's also happening for me, but would be nice to know why it slows down after doing this a couple of times?

The site goes from blazing fast (<1s load) to VEEEERY slow (4-8s page loads). Unacceptable both in dev and in production, imo.

[fanismahmalat]

In my case, this problem was solved just clearing my data configs on the tab aplication > storage in Chrome

This worked for me just a little but did not improve the performance significantly. It still is noticeably slow on first loads.

[dimitur2204]

Works for the first few requests only for me

[ge-infosec]

In my case, this problem was solved just clearing my data configs on the tab aplication > storage in Chrome

Thanks a lot, awesome!

[mxmzb]

I'm experiencing this issue when I'm using Google Chrome. Switching to Firefox (or maybe to another browser, but didn't try), sorted this out for me.

[bobissict]

Make sure you haven't got throttling enabled in your Chrome dev tools, this was my issue 😄

I spent a few hours trying to fix it and this was the solution 🤦🏻‍♂️

[odafeaggreh]

This was also the fix for me. thanks man!

[SawkaDev]

It was opposite for me. Switching from Firefox to Chrome fixed the issue mostly. Not sure what is wrong with my Firefox. Oddly, a different project using the same Skeleton code runs perfectly in Firefox.

[aahmedfaraz]

Oh thanks man

[ricardosc12]

Experienced a 2s average page load, switching to Brave dropped to 100ms

[Amantel]

Any updates on this?

[fhinson]

Also experiencing this with a lightweight application loaded with TailwindUI in Chrome

[f16z]

Painful to develop with this slowness. Any clues to make this faster?

[timneutkens]

Hey please follow these instructions: #29559 (comment). It will allow us to investigate exactly where time is spent in your application.

Do note that "3 minutes of compiling" is unexpected and so far what I've found looking at the apps in #29559 is generally caused by incorrectly configuring TailwindCSS or accidentally importing thousands of modules through a dependency.

We have some big announcements coming up with regards to compiling performance so I'd recommend watching http://nextjs.org/conf on October 26 👍

[MalvinJay]

@timneutkens Thanks for your quick response. I will definitely follow these instructions and provide feedback. I have October 26th saved on my calender as well.

[timneutkens]

Thanks @MalvinJay, looking forward to seeing the trace 🙏

I've added an explanation for @f16z's issue here: #29559 (comment). It's related to an import that causes 5.5K+ icons to be compiled even though they're not used in the app.

[Amantel]

Thanks, @timneutkens !

[MalvinJay]

I've had a huge development performance boost after upgrading to "next": "^11.1.3-canary.84", react to v17.0.2 (together with react-dom) and moving from webpack 4 to 5 (Which was supported by default). Thank you @timneutkens 🚀 for your explanations on issue #29559 (comment) 👍🏾

[Amantel]

I think we should if that will bring attention to this issue.

…

On Wed, Oct 13, 2021 at 10:43 PM Hugo Nogueira ***@***.***> wrote: Agree! Same for our team here. Seems like it's an old issue: #4844 <#4844> Should we comment on the open issue to check if there's any position from the official maintainers? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#17977 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEMS5UY4DSZH6FPPAXREXDUGXOOZANCNFSM4SURSZIQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ro0t]

I managed to solve my issues in two steps:

1. Updating Tailwind to the latest version and using JIT compiling. (Small difference in load time)
2. Updated next-auth to their latest beta version (This made a huge difference for us, weird.)

[timneutkens]

Could you follow the steps in #29559 (comment) to provide a before/after trace?

[kaushalmarakana]

Hello

I was also facing this issue, I noticed that after changing browser from brave to chrome, it is fixed. It seems browser issue. In brave browser I am facing this issue, the main bundle size is 1Mb, but it loads faster in chrome but not in brave. Also hot reloading not working in brave.

[byronlanehill]

For anyone coming to this issue, I think I have the answer!

After looking at these comments and trying all of their solutions, the only one that worked was either switching browsers or clearing my cache for localhost:3000

It appears to me that the browser is storing a bunch of unnecessary data from previous builds (every time you make a change to the code base and reload the webpack bundle changes). I was having to wait minutes for the initial load and upwards of a minute for page transitions, but after clearing cache my initial load is below 10 seconds and page transitions are instant if the page has been cached, if not it is taking 2-3 seconds.

[oalexdoda]

To anybody still facing this issue, it's most likely because of tree shaking. Using libraries like MUI often causes your app to load ALL modules while in development mode. Here's a simple (yet experimental) solution that helps you avoid having to do things like including each component individually.

Add this to your next.config.js, especially for @mui or Lodash:

experimental: {
	modularizeImports: {
		lodash: {
			transform: 'lodash/{{member}}'
		},
		'@mui/material': {
			transform: '@mui/material/{{member}}'
		},
		'@mui/lab': {
			transform: '@mui/lab/{{member}}'
		},
		'@mui/icons-material/?(((\\w*)?/?)*)': {
			transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}'
		}
	}
}

You can use this to transform any module you want, as documented here:
https://nextjs.org/docs/advanced-features/compiler#modularize-imports

I hope this helps and that Next.js figures out a way to automatically modularize imports instead of requiring it to be an opt-in per module.

[oelbaga]

I'm definitely experiencing this slow page load in development with mui modules. Was driving me crazy in Development. I can't wait to try this tomorrow!

[Denis2222]

Big thanks !
Working on Next JS project with Material UI v4.

yarn dev; Document build time :

• Without ~{9s - 15s}
• With ~{2s- 3s}

module.exports = {
  ...
  modularizeImports: {
    lodash: {
      transform: 'lodash/{{member}}'
    },
    '@material-ui/core/': {
      transform: '@material-ui/core/{{member}}'
    },
    '@material-ui/lab/': {
      transform: '@material-ui/lab/{{member}}'
    },
    '@material-ui/icons/?(((\\w*)?/?)*)': {
      transform: '@material-ui/icons/{{ matches.[1] }}/{{member}}'
    }
  },
  ...
}

[phoenixcoded20]

I'm definitely experiencing this slow page load in development with mui modules. Was driving me crazy in Development. I can't wait to try this tomorrow!

@oelbaga Can you share the outcome please, as for me it is not much helpful. I am using MUI 5 packages.

[dimitur2204]

I'm definitely experiencing this slow page load in development with mui modules. Was driving me crazy in Development. I can't wait to try this tomorrow!

@oelbaga Can you share the outcome please, as for me it is not much helpful. I am using MUI 5 packages.

@phoenixcoded20 Check your dev logs again after a page load and see if your compiled modules between page loads are any different than before. They also recently removed it from the experimental features and has now to be directly in the main config objects.

For me it improved a lot after the change from 5-6 seconds to 1-2-3(depending on the page), which is still not good, but at least it's bearable now

[codart1]

Not only nextjs dev is quite slow. It also throws memory-leaking error after a few HMR. I'm using the new app dir.

<--- Last few GCs --->

[72078:0x4efda00]   605248 ms: Mark-sweep (reduce) 2061.6 (2109.8) -> 2059.3 (2087.5) MB, 258.1 / 0.1 ms  (+ 8.6 ms in 11 steps since start of marking, biggest step 6.4 ms, walltime since start of marking 471 ms) (average mu = 0.830, current mu = 0.603) t

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb02960 node::Abort() [node]
 2: 0xa18149 node::FatalError(char const*, char const*) [node]
 3: 0xcdd22e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xcdd5a7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xe94c15  [node]
 6: 0xea48dd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 7: 0xf07aa4 v8::internal::ScavengeJob::Task::RunInternal() [node]
 8: 0xd9b1bb non-virtual thunk to v8::internal::CancelableTask::Run() [node]
 9: 0xb6e104 node::PerIsolatePlatformData::RunForegroundTask(std::unique_ptr<v8::Task, std::default_delete<v8::Task> >) [node]
10: 0xb6ff69 node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node]
11: 0x1547da6  [node]
12: 0x155a4d4  [node]
13: 0x15486f8 uv_run [node]
14: 0xa3fa35 node::SpinEventLoop(node::Environment*) [node]
15: 0xb42c56 node::NodeMainInstance::Run() [node]
16: 0xac89bc node::Start(int, char**) [node]
17: 0x7f4190838083 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
18: 0xa3d03c  [node]
Aborted (core dumped)
/home/codart/Projects/Ringblaze/apps/apps/web-next:
 ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL  web-next@0.0.0 dev: `next dev -p 4000`
Exit status 134

[timneutkens]

Please provide a reproduction, this stack is not enough to be able to investigate.

[codart1]

Please provide a reproduction, this stack is not enough to be able to investigate.

Hi, I just create a discussion that explains my issue here:
#42343

[DenisBessa]

After a few tests, I came with the conclusion that the problem was something in my computer.

I was unable to get a decent performance with Windows or WSL.

The solution was to use a remote server for development with VSCode, and it was surprisingly ease (see how to do it here: https://code.visualstudio.com/docs/remote/ssh#_ssh-host-setup).

Hope you guys get a better devx!

[PedroNunezCode]

Try closing the dev tools if you're on chrome. When I have the network tab open it takes 15+ seconds but whenever I don't have it opened, It instantly loads. None of the ideas on here worked for me. but I hope this helps someone.

[timneutkens]

Make sure you don't have throttling enabled in the network tab.

[umrian]

I have this problem too. For me the loading time was around 40s, and I'm using tailwindcss. The solution for me was the tailwind.config.js.

`/** @type {import('tailwindcss').Config} */
module.exports = {
mode: "jit",

content: ["./src/**/*.{js,ts,jsx,tsx}"],
darkMode: "media",
theme: {
extend: {},
},
plugins: [],
};
`.

I created a src folder and put the pages folder in it. And change the config
from content: ["./pages/**/*.{js,ts,jsx,tsx}"]
to content: ["./src/**/*.{js,ts,jsx,tsx}"].
Neither disble throttling or modularizedImports worked for me. Now my reload time is like 109ms. Hope this help you guys!

[jeffminsungkim]

If anyone using Tailwind v3, JIT is unnecessary.

[Luisdv93]

If anyone using Tailwind v3, JIT is unnecessary.

Why?

[doaortu]

JIT is on by default in v3

[faizov]

Just ran into this problem. Clearing the cache helped

[Auron91]

There is possibility that you are using Babel istead of SWC compiler:
https://nextjs.org/docs/messages/swc-disabled

[s1rd4v3]

Had the same issue with open dev tools and searched for quite some time. In my case disabling a chrome extension helped even though this extension was not actionable within the dev tools (Super Agent)

[ssadler]

In my case I found that the issue is the time it takes the browser to download and parse the dev bundle. I wrote a script to analyze it and found that react-icons was absolutely massive; to fix it, i replaced react-icons with @react-icons/all-icons, and imported the icons individually. This halved the page load time. The python script is below, if anyone else wants to try this.

# Call like: python next-dev-bundle-analyze.py .next/static/chunks/pages/_app.js | sort -n

import sys

mod = ""

prefix = '/***/ "../../node_modules/'

for l in open(sys.argv[1]):

    if l.startswith(prefix):
        mod = l[len(prefix):].strip()
    elif l.startswith('eval('):
        print("%s\t%s" % (len(l), mod))

[dashkevych]

I am also getting slow initial page load but when using @fluentui/react-components and Next.js (App Router).

[denvudd]

Hello, I may have the same issue. I'm using Ant Design on a page that loads slowly. It seems that if I simply output the data, the loading is fast, but if I pass them into an Ant Design component, the initial load becomes slow again. Have you found any reasonable solution or compromise for this?

[dashkevych]

Hi, I have not found any solutions yet :(

[denvudd]

Has anyone found a solution to this problem after all? I'm experiencing the same issue. I have a page that uses dynamic routing and fetches data through RTK Query in getServerSideProps (using next redux wrapper). It takes about 7 seconds to load the page if it's the first time. After the initial load, it loads faster (around 2 seconds). However, once the cache is cleared, it takes a long time to load again. I can't figure out what the problem is. In the DevTools Network tab, during the loading, it simply shows the JSON file in a pending state, nothing unusual. In my case, it's not specific to the development mode either. The page loads slowly on Vercel for the first time as well.

Can anyone at least provide a clue about the cause? :(

My package.json:

{
  "name": "react-tbmovies",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "@ant-design/icons": "^5.0.1",
    "@reduxjs/toolkit": "^1.9.5",
    "@types/node": "20.1.3",
    "@types/react": "18.2.6",
    "@types/react-dom": "18.2.4",
    "ahooks": "^3.7.7",
    "antd": "^5.4.7",
    "classnames": "^2.3.2",
    "clipboard": "^2.0.11",
    "dayjs": "^1.11.7",
    "lodash.debounce": "^4.0.8",
    "next": "13.4.2",
    "next-redux-wrapper": "^8.1.0",
    "numeral": "^2.0.6",
    "react": "18.2.0",
    "react-content-loader": "^6.2.1",
    "react-dom": "18.2.0",
    "react-redux": "^8.0.5",
    "react-youtube": "^10.1.0",
    "sass": "^1.62.1",
    "typescript": "5.0.4"
  },
  "devDependencies": {
    "@types/lodash.debounce": "^4.0.7",
    "@types/numeral": "^2.0.2"
  }
}

Loading results:

[Annukul]

The page loads slowly on Vercel for the first time as well.

This is also mentioned in the docs that first time when you visit the page, after a fresh build, it will load slowly for the first time but after that it will be fast. This is how next js caching works. (can't find the specific portion of the doc for this)

And the slowness issue while development is still there for me. I am also trying to figure out what's wrong or how to improve that.

[denvudd]

Yes, I understand that it initially loads slowly and then becomes normal since the data is being cached. However, 7 seconds is quite long, in my opinion. Especially considering that after some time, the cache gets cleared and the loading time slows again. I would like to somehow reduce this time, but so far, I haven't found a similar solution. The only workaround is to add a loader and show the user that the page is loading. However, this doesn't solve the problem - the user still has to wait for 7 seconds, unfortunately. :(

[Annukul]

The initial loading will always be there whenever there is a new build is created i.e. when you have pushed and deployed a new change. But in your case it's happening even when there is no fresh deployment right? Kind of similar issue was happening with me where it took a lot of time to load pages on development mode. I fixed it by removing react-icons library and instead using svgs. I see that you are using a icons library, I am not sure you might have the same issue but you can give it a shot

[guerjon]

For NextJS 13: add the modularizeImports if you are using material design:

`/** @type {import('next').NextConfig} /
const nextConfig = {
experimental: {
appDir: true,
},
images: {
domains: ['github.com', 'lh3.googleusercontent.com']
},
modularizeImports: {
lodash: {
transform: 'lodash/{{member}}'
},
'@mui/material': {
transform: '@mui/material/{{member}}'
},
'@mui/lab': {
transform: '@mui/lab/{{member}}'
},
'@mui/icons-material/?(((\w)?/?)*)': {
transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}'
}
}
}

module.exports = nextConfig`

[bruno-silva5]

My development enviroment was taking 40s to load. I removed depedencies, switched the browser, cleared the cache, and even download a brand new create-next-app only for testing, and still needed 40s to load.

Then, when I disabled my wi-fi, the application went way too fast, from 40s to ~100ms. So, I connected to another wi-fi (now I am using my phone hotspot mode) and the problem is "gone"

It's a good quick-fix, there's probably some configuation I have to change in my wi-fi, change its channel or something like that, but for now, using my phone as hotspot is way better.

[Annukul]

My dev env was taking around 12-15 seconds to load and fast refresh was also not working whenever I made a change in the code. I had to refresh the whole page in order to see the change.

Now it's working as expected. I was using a icons library react-icons, when I removed that library and used simple SVGs instead the issue was gone. My load time is now reduced to 100ms from 12-15 seconds.

[timneutkens]

I'm consolidating all these reports into a single place, which provides steps on how you can help investigate: #48748 (comment)

Going to lock this thread in favor of that issue.