#Improve NextJS Compilation Time (Development)

92 messages · Page 1 of 1 (latest)

livid yew
#

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

GitHub

Contribute to Marty-Byrde/PublicServices development by creating an account on GitHub.

past kestrelBOT
#

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

grand heart
#

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

livid yew
#

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.

livid yew
# grand heart That does seem pretty long!

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...

final kernel
#

there has been improvements to dev compilation time in newer versions so i'd suggest trying to upgrade

livid yew
#

That's good to know thanks. I will try to do upgrade and report back once I did.

tacit solstice
#

Yes @livid yew , 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.

livid yew
#

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.

acoustic zinc
#

is /secureAuth/page async?

livid yew
#

Yes, but it only awaits the 'fetch' request of the current session from next-auth.

acoustic zinc
#

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

livid yew
#

It takes about 239ms

acoustic zinc
#

hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm

#

thats odd

#

what about app/secureAuth/layout.tsx
and app/layout.tsx
(any parent layout)

livid yew
acoustic zinc
#

didnt see anything that would block the render so we can rule out async/await loads

livid yew
#

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?

acoustic zinc
#

does it only apply to this particular route?

livid yew
#

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

acoustic zinc
#

oh

#

try reproducing the bug without daisy UI?

#

is the package that you sent complete? i didnt see /secureAuth/page.tsx

livid yew
#

Its on a seperate branch called 'next-auth-setup". The current changes, Next 13.4.19, are not yet pushed

acoustic zinc
#

if you're ready to send a reproduction repository maybe i can set it up on my machine and see if it still persist

livid yew
#

I will push the current changes to separate branch with a template .env file, so you are able to run it on your maschine

acoustic zinc
#

thank you

livid yew
grand heart
#

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')
grand heart
#

@acoustic zinc Are you reproducing the long build time at all? It might be something unusually about their next-auth configuration

acoustic zinc
acoustic zinc
#

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

livid yew
livid yew
#

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

final kernel
#

everything seems fine to me?

livid yew
#

yes, I am confused too, but the compilation time is still pretty high at around 4 seconds at the moment

final kernel
#

are you talking about the initial compliation when you start the dev server?

#

compiling the /secureAuth page takes 0-6ms for me

livid yew
#

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

livid yew
final kernel
#
[00:43:23] aaaaaa@work:~/dev/PublicServices: pnpm run dev

> [email protected] 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
livid yew
#

In your case its 2.1 seconds, is this a resonable time for such a simple page?

final kernel
#

and when i clear browser cache and reload it's still like 2ms

#

that's the initial dev server start

acoustic zinc
#

^

#

i thought so too

final kernel
#

unless i'm missing something there's nothing wrong or slow here

acoustic zinc
#

even after making change to the file, rerendering page does not take that long

livid yew
# acoustic zinc even after making change to the file, rerendering page does not take that long

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?

final kernel
#

have you tested the prod build?

acoustic zinc
#

I think the issue is specifically geared towards development

livid yew
final kernel
#

where/how are you running the prod build?

livid yew
#

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

final kernel
#

seems to load instantly for me

acoustic zinc
livid yew
acoustic zinc
#

try using generateStaticParam() to prerender all static pages
so that it wont take that long

livid yew
livid yew
final kernel
#

one initial load was 6 seconds, another time was about 2 sec

#

where is this hosted?

livid yew
#

On a private server with an exposed port

livid yew
final kernel
#

almost every hit is fast but the odd one takes 5 or more seconds

livid yew
final kernel
#

no the duckdns one

livid yew
#

yeah sorry, I meant the route

final kernel
#

just /lectures with the list view

livid yew
#

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.

livid yew
# acoustic zinc I think the issue is specifically geared towards development

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.

grand heart
livid yew
#

(in this context: reload = browser-page-refresh)

grand heart
#

Ok, another question. What happens if you clear the browser data?

#

Does it take a long time again or go fast?

livid yew
grand heart
#

The cookies

livid yew
#

Now the session retrieval is way lower, (but I am also no longer signed in using the previously selected next-auth-provider)

livid yew
#

Note I have renamed the 'Debug-Main' branch to 'Debug-Main-Compilation-Reproduction'