Nav causing all pages to be SSR instead of Static

[m-j-g]

I'm curious about this behavior I'm seeing. When using this template, I create an about page /about/page.tsx that only has:
export default function About() { return <div>About</div> }

While building it marks this page as SSR. If I remove the nextauth stuff and remove the nav bar from the top level layout:
<Suspense fallback="..."> {/* @ts-expect-error Server Component */} <Nav/> </Suspense>

then it will mark the page as static. Shouldn't the child page be static since this element in the top layout is wrapped in Suspense? I don't understand the behavior.

[m-j-g]

Steven what I'm really curious about here is reducing the horrendous cold start times when deployed on Vercel and using this getServerSession strategy. In my newbie mind, it shouldn't cause such a problem because it is in a Suspense, but it makes a huge difference on the cold start time when I have this Nav logic added to the top layout or not.

[m-j-g]

I've been experimenting with this for a couple of days now. It's really quite interesting, but I'm uncertain if this is just how it is with Vercel hosting and the AWS cloud functions, or if something can be done about it.

If I load the page, and come back 10 minutes later and click a button, it takes several seconds to navigate to the page selected. It's excruciatingly long. When I remove the auth API and elements, there is never a delay. I can load the site on my phone, minimize it, come back to it 10, 20, 30 minutes later and it always responds.

In this case where it's wrapped in suspense I would expect that it would load the page and then when the AWS cloud functions are ready it would load that Nav element with the auth. Instead, it just doesn't server anything until the cloud functions are ready it seems?

[m-j-g]

Further testing brings me back to the initial question about design strategy implemented in this project. I moved the auth api out to make it client side, just to test. Thinking it was because of the server less function that this required. However, the real problem is my initial observation. When I include the <Nav/> object in the root layout, it makes every page SSR. So in the logs on Vercel, I can see when I try to navigate to another page that the type is "Serverless Function". When I remove the <Nav/> from the root layout the types in the logs is simply "request" and it's statically generated.

The behavior of this is that if you leave your page for 5-10 minutes, and then come back and click a link on your page to navigate to a static page on your site, it takes around 5 seconds to navigate to that page.

In the logs it says the serverless function cold boot duration is 164ms, but I can sit there with a stop watch and see it take many seconds. So there is some additional "cold" loading time that isn't accounted for in that measurement. When the page hasn't been idle it's instant when you click around. Also when you remove the <Nav/> from root and the pages become static, it is instant when you click around even if the page has been idle for a long time.

EDIT: Yeah, there is definitely some Vercel cold start delay that is outside the Serverless Function cold boot. I tried it after 8 minutes of not using it, came back and clicked "About" to load the simple about page. It took several seconds to respond, and when I look in the logs it had a cold boot duration of 0ms. But like I said earlier, if this isn't a serverless function type page, if it is static, then when I come back after any amount of time, it will still almost instantly load when I click About.