Why is Next.js so slow??

Next.js “server component” apps feel slow when navigation waits on server work without giving users immediate feedback. The core issue isn’t that server components are inherently sluggish; it’s that teams often treat server-rendered navigation like client-side data fetching—showing nothing (or relying on browser loading) until the server finishes generating the next route. That creates a long “time to first bite” window where users click and nothing visibly happens, which the brain reads as unresponsiveness.

To explain why, the transcript walks through how web performance expectations formed. Traditional multi-page apps (MPAs) load new HTML from the server on every navigation. That can be fast to complete, but users typically see no meaningful change until the full response arrives. Single-page apps (SPAs) flip the model: the browser loads one HTML shell and JavaScript once, then client-side routing updates the UI instantly on clicks. SPAs often take longer overall to show fully correct content because data still comes from APIs, but the interaction feels immediate because the app can react within milliseconds.

Server components introduce a hybrid: route-specific HTML can be generated on the server, with caching for static cases, and streaming for dynamic ones. That means the URL again matters—unlike SPAs where the same shell HTML serves every route. But the hybrid behavior only delivers SPA-like “instant navigation” if the build and runtime can produce a static shell (or partial pre-render) and then fill in dynamic parts later. Without the right caching layer (e.g., a CDN smart enough to serve cached route output and fall back to the origin), server component apps can behave like “server-first” pages: first loads may be acceptable, but navigations can require a round trip before anything changes.

The transcript then demonstrates the failure mode with a mock dashboard. Some routes appear to navigate instantly because they’re effectively static and already present in the client bundle. Another route is forced dynamic, and navigation to it stalls: the UI doesn’t update immediately, so the sidebar highlight waits, producing a dead-feeling gap around ~600ms—enough to cross the threshold where users start to doubt the site is responding. The fix is surprisingly specific to Next.js’s server component rendering pipeline: add a route-level `loading.tsx` (or equivalent Suspense boundary) so Next.js can ship a static “loading shell” immediately, then stream the dynamic content when ready. The key is placing the loading boundary above the dynamic async work so the route can render something right away.

The transcript also highlights gotchas: Suspense placement in layouts may not trigger the desired static fallback because layouts don’t rerun on the client. Moving Suspense to the page component (or using `loading.tsx`, which Next.js wires automatically) restores immediate navigation feedback. It further mentions newer Next.js mechanisms like Partial Pre-Rendering (PPR) and Dynamic IO, which aim to make dynamic routes render static HTML up to the first async boundary, then stream the rest.

Ultimately, the argument is about balancing two user-perceived metrics: “time to first bite” (TTFB) and “full content paint” (FCP). Server components done right can reduce the bad loading window (where users see nothing) while still getting the benefits of server-side data fetching. Done wrong, they collapse TTFB and FCP into the same slow moment—recreating the unpleasant navigation delay seen in older server-rendered patterns. The transcript closes by contrasting this with HTMX: server round trips are normal, but UX improves when the app controls click-local loading states instead of relying on browser loading behavior.