Next.js Discord

Discord Forum

Improve NextJS Compilation Time (Development)

Answered
Pyramid ant posted this in #help-forum
Open in Discord
Pyramid antOP
Hey guys I am currently working on a simple NextJS project, with Typescript, that displays a list of lectures and their details. I use tailwindcss for most of my styles to improve performance and Chakra-UI for some parts of my NavigationBar. In Addition, I use DaisyUI for its themes (dark and light mode).

For some reason the compilation time of my project is pretty high, for example, while running 
npm run dev
the compilation time for a page is about ~5 seconds according to the terminal. For the user, in this case, me, it sometimes takes around 9 seconds to load a simple page, that only shows a staticly inserted text. (route: /secureAuth, branch: next-auth-setup) Below I will provide some screenshots of both the terminal-logs and the page in question.

My question is whether this compilation time is considered to be normal and or how to lower the compilation to increase performance?
(Side question in case someone has done this, can I only use the themes provided by daisyUI, and exclude its components to reduce the amount of modules that are compiled?)

Repository / Codebase: https://github.com/Marty-Byrde/PublicServices

Thanks in advance
Answered by European sprat
that's the initial dev server start
View full answer

90 Replies

Asian black bear
That does seem pretty long!
Is there a reason you are using an ancient version of next?
Also, it might be worth stronly considering using WSL to develop on Windows instead of running it directly
Pyramid antOP
The version of next is that low because I it was the first version I used, given that it is beta some things may change, thats why I haven't upgraded for now.
As for running it on windows, thats only the case for running it as a dev, when its running on production, then its run on a linux machine on my server.
@Asian black bear That does seem pretty long!
Pyramid antOP
Thats what I thought, my first guess on how to solve this was to reduce the daisyUI package, as I essentially only use its themes and functionality to style elements for light and darkmodes on the server (e.g. text-sky-700 dark:text-sky-400). However, I haven't yet figured out how to do so...
European sprat
there has been improvements to dev compilation time in newer versions so i'd suggest trying to upgrade
Pyramid antOP
That's good to know thanks. I will try to do upgrade and report back once I did.
Tramp ant
Yes @Pyramid ant , either run the upgrade command in terminal in current project, or even better to truly view the problem side by side, quickly clone your repo to a separate project and try running your existing compiler against the one in latest 13.4, etc.
Pyramid antOP
So i have updated next to 19.4.19 locally. Opening the same page results in nearly the same compilation time of about 4.5 seconds based on the terminal and about 7 seconds in the browser.
aardani
is /secureAuth/page async?
Pyramid antOP
Yes, but it only awaits the 'fetch' request of the current session from next-auth.
aardani
ok run a timer on that fetch request / getServerSession
class Audit {
  private _start: number = performance.now()
  private _end: number | null = null
  getSec() {
    this._end = performance.now()
    return ((this._end - this._start) / 1000)
  }
}
also what codelens are you using? its cute looking
Pyramid antOP
It takes about 239ms
aardani
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
thats odd
what about app/secureAuth/layout.tsx
and app/layout.tsx
(any parent layout)
Pyramid antOP
So the secureAuth page it self does not have a layout file but the RootLayout /parent layout looks like this:
https://github.com/Marty-Byrde/PublicServices/blob/main/app/layout.tsx
aardani
didnt see anything that would block the render so we can rule out async/await loads
Pyramid antOP
So I have set the root layout to:
export default async function RootLayout({ children, }: { children: React.ReactNode }) {
  const background = 'bg-stone-100/90 dark:bg-base-100'

  return (
    <html lang='en' data-theme='halloween' className='dark '>
      <body>
      {children}
      </body>
    </html>
  )
}

To check whether it impacts the performance. And the compilation time is a bit lower at ~4.5 seconds. But I'd say this is still too long, isnt it?
aardani
does it only apply to this particular route?
Pyramid antOP
No it applies to all routes, in fact the compilation time increases on my other routes that are "more complex", that means display actual data
aardani
oh
try reproducing the bug without daisy UI?
is the package that you sent complete? i didnt see /secureAuth/page.tsx
Pyramid antOP
Its on a seperate branch called 'next-auth-setup". The current changes, Next 13.4.19, are not yet pushed
aardani
if you're ready to send a reproduction repository maybe i can set it up on my machine and see if it still persist
Pyramid antOP
I will push the current changes to separate branch with a template .env file, so you are able to run it on your maschine
aardani
thank you
Pyramid antOP
I have now pushed all the recent changes to github into the 'Debug-Main' Branch. Note, that the compilation time bug occours when the secureAuth page is opened for the first time.
https://github.com/Marty-Byrde/PublicServices/tree/Debug-Main
Asian black bear
Can you try something like this to see if next-auth is being slow? 
console.time('getServerSession')
const session = await getServerSession(options)
console.timeEnd('getServerSession')
Asian black bear
@aardani Are you reproducing the long build time at all? It might be something unusually about their next-auth configuration
aardani
I can't reproduce the issue
i updated next.js to latest and removed "campus-scraper": "^1.0.8", and "mongodb_handler": "^1.0.9", since i can't install it
@aardani i updated next.js to latest and removed "campus-scraper": "^1.0.8", and "mongodb_handler": "^1.0.9", since i can't install it
Pyramid antOP
Sorry didnt think about those two packages, they are on a private npm registry. I will remove them so that you can install the remaining packages
Pyramid antOP
I have now pushed the project without the campus-scraper and mongodb-handler packages to the 'Debug-Main' Branch. I have also updated the package-lock to no longer use my private-registry server, but instead use the npm-registry. I have also tested the behaviour of the project on a newly cloned directory and i think it should be now possbiel to easily reproduce the issue in question. If you face any difficulties please let me know
European sprat
everything seems fine to me?
Pyramid antOP
yes, I am confused too, but the compilation time is still pretty high at around 4 seconds at the moment
European sprat
are you talking about the initial compliation when you start the dev server?
compiling the /secureAuth page takes 0-6ms for me
Pyramid antOP
I tried to remove all the imports (layout and the opened page), and got the compilation time down to 700ms but thats just a naked nextjs app
@European sprat are you talking about the initial compliation when you start the dev server?
Pyramid antOP
When I start the development server, wait for it to fully start and then open the /secureAuth page for the first time, then I get a compilation time of ~4seconds even though it only displays a simple text
European sprat
[00:43:23] aaaaaa@work:~/dev/PublicServices: pnpm run dev

> public-services@0.1.0 dev /home/aaaaaa/dev/PublicServices
> next dev

- info Loaded env from /home/aaaaaa/dev/PublicServices/.env
- ready started server on [::]:3000, url: http://localhost:3000
- event compiled client and server successfully in 161 ms (20 modules)
- wait compiling...
- event compiled client and server successfully in 94 ms (20 modules)
- info Loaded env from /home/aaaaaa/dev/PublicServices/.env
- info Loaded env from /home/aaaaaa/dev/PublicServices/.env
- wait compiling /secureAuth/page (client and server)...

🌼 daisyUI components 2.51.6  https://daisyui.com
  ✔︎ Including:  base, components, 2 themes, utilities
  ❤︎ Support daisyUI:  https://opencollective.com/daisyui 
  
- event compiled client and server successfully in 2.1s (2636 modules)
- wait compiling...
- event compiled successfully in 197 ms (1273 modules)
SecureAuth: 51.786ms
SecureAuth: 1.235ms
SecureAuth: 3.656ms
SecureAuth: 1.408ms
SecureAuth: 2.08ms
Pyramid antOP
In your case its 2.1 seconds, is this a resonable time for such a simple page?
European sprat
and when i clear browser cache and reload it's still like 2ms
European sprat
that's the initial dev server start
Answer
aardani
^
i thought so too
European sprat
unless i'm missing something there's nothing wrong or slow here
aardani
even after making change to the file, rerendering page does not take that long
@aardani even after making change to the file, rerendering page does not take that long
Pyramid antOP
yeah thats true for this page. So my inital question was regarding my project's actual core idea, that is to display a set of lectures. The initial loading page the was also around ~5 seconds, which can be attributed to the dev-server start, but whenever I made changes to that page, the compilation time for the changes to take effect was also around 3 seconds. That's why I though that the reload-compilation is in direct relation to the now known initial-server-compilation
But just for my understanding, the initial compilation-time of in your case 2.1 seconds, cannot be lowered or is considered to be normal?
European sprat
have you tested the prod build?
aardani
I think the issue is specifically geared towards development
@European sprat have you tested the prod build?
Pyramid antOP
Yes, the initial load-time for users is also quite high, talking about multiple seconds. Some users reported back to me that they waited 15 seconds for anything to show.
European sprat
where/how are you running the prod build?
Pyramid antOP
Once the page has been opened on the user's maschine, future requests are much faster
If you open this page for the first time you should experience a quite high 'wait' time
European sprat
seems to load instantly for me
@aardani maybe only first time render?
Pyramid antOP
yes, when the page is opened for the first-first time
aardani
try using generateStaticParam() to prerender all static pages
so that it wont take that long
@European sprat seems to load instantly for me
Pyramid antOP
Thats surprising but great
@aardani try using `generateStaticParam()` to prerender all static pages so that it wont take that long
Pyramid antOP
The problem i see there is that I don'tt have static pages, as each page fetches data directly from an external endpoint and thus its contents change, so that they remain up-to-date?
European sprat
one initial load was 6 seconds, another time was about 2 sec
where is this hosted?
Pyramid antOP
On a private server with an exposed port
@European sprat one initial load was 6 seconds, another time was about 2 sec
Pyramid antOP
My initial guess was that the delay occurs due to the bandwidth limitations of our network. But the page-size is not that big so that it could have an impact, right? (upload speed: ~5Mb)
European sprat
almost every hit is fast but the odd one takes 5 or more seconds
@European sprat almost every hit is fast but the odd one takes 5 or more seconds
Pyramid antOP
Which one do you mean?
European sprat
no the duckdns one
Pyramid antOP
yeah sorry, I meant the route
European sprat
just /lectures with the list view
Pyramid antOP
So both pages /lectures and /lectures/[id] fech the data from an external endpoint and whats important to note is that the fetch-result is not cached. This is because I tried to display a bigger collection of items and got the error that the fetch-result is to big to be cached, which is why i disabled the caching of that fetch-request altogether, which obviously impacts the performance to some degree. For me personally the production page is quite alright. I just received reports from other users that they faced long-wait times.
@aardani I think the issue is specifically geared towards development
Pyramid antOP
Yes this is true, I believe that the core issue, being the high compilation for the initial-page-load after the dev-server has been started, is somewhat solved by the fact that a compilation time of ~2 seconds is normal? In case that this delay is as low as it can be, then I am very satisfied.
Maybe as a small side-question what would be the best practice to reduce the compilation-time to a minimum?

In regard to the reload compilation-times, I believe that the upgrade to the newer Next version (13.4.19) has reduced the compilation-time. Given that the reload compilation time was previously also way above 1 second.
@Pyramid ant It takes about 239ms
Pyramid antOP
Yes, this was for the initial-compilation when the dev server was started
(in this context: reload = browser-page-refresh)
Asian black bear
Ok, another question. What happens if you clear the browser data?
Does it take a long time again or go fast?
@Asian black bear Ok, another question. What happens if you clear the browser data?
Pyramid antOP
including cookies or just the cached data?
Asian black bear
The cookies
Pyramid antOP
Now the session retrieval is way lower, (but I am also no longer signed in using the previously selected next-auth-provider)
Pyramid antOP
Note I have renamed the 'Debug-Main' branch to 'Debug-Main-Compilation-Reproduction'