Composition, Caching, and Architecture in modern Next.js

Aurora introduces the talk on composition, caching, and architecture in modern Next.js, focusing on scalability and performance. She refreshes the concepts of static and dynamic rendering, explaining that static rendering offers faster websites, global distribution, reduced server load, and better SEO, using the Next.js Conf website as an example. Dynamic rendering, conversely, enables real-time, frequently updated, or personalized content, such as the Vercel dashboard. Key APIs like `params`, `search params`, cookies, headers, and `fetch` with `no-store` are highlighted as triggers for dynamic rendering.

In previous Next.js versions, a single dynamic API call on a page would force the entire page into dynamic rendering, even if most content was static. This 'all or nothing' approach led to redundant server processing for content that rarely changes, impacting performance. While React Server Components with Suspense allowed streaming dynamic content, multiple async components on a dynamic page would still run at request time. This often resulted in extra development work like creating skeletons and managing cumulative layout shifts, especially for applications with a mix of static and user-dependent data.

To solve the rigid static/dynamic rendering problem, the `use cache` directive was announced and is now available in Next.js 16. This directive allows pages to be both static and dynamic, eliminating the need for Next.js to guess a page's rendering type. By default, everything is dynamic, and `use cache` explicitly opts components or functions into caching. This enables composable caching, allowing specific React components or functions, like a 'feature products' component, to be pre-rendered and included in the static shell through partial pre-rendering, making content available on page load.

The speaker introduces a demo e-commerce application, intentionally slowed down to showcase common Next.js issues. The app features a mix of static pages (e.g., About) and dynamic, user-dependent content (e.g., personalized dashboard, product pages). The identified problems in the codebase include deep prop drilling, making features hard to maintain and refactor. Additionally, there is excessive client-side JavaScript and large components with multiple responsibilities, alongside a general lack of static rendering, leading to increased server costs and degraded performance. The goal of the demo is to improve this app using smart patterns for composition, caching, and architecture.

The first issue addressed is deep prop drilling, specifically with a `loggedIn` variable passed through multiple component levels. The solution involves pushing data fetching down into the components that actually use the data, resolving promises deeper in the component tree. For client components, an `AuthProvider` is created in the root layout to pass the `loggedIn` promise, which is then consumed locally using `useAuth` and `use`. This pattern, combined with React Cache for deduplication, makes components like the `WelcomeBanner` more composable and reusable, eliminating unnecessary prop dependencies and allowing for suspense boundaries.

The speaker tackles excessive client-side JavaScript and large components by introducing the 'donut pattern.' This involves extracting minimal interactive UI logic into a client-side wrapper component, while keeping the core content as a server component. For instance, a `WelcomeBanner` that was entirely client-side due to a simple dismissible state is refactored; its interactive part becomes a client wrapper, and the data fetching and main display become a server component. This approach allows for server-side data fetching with type safety, significantly reduces the client-side bundle, and maintains a clear separation of concerns. The pattern is also applied to other components, including those using animation libraries like Framer Motion.

The demo application initially shows all pages as dynamically rendered, leading to performance issues and increased server costs. This is traced to a `UserProfile` component in the root layout that uses cookies, forcing dynamic rendering across the entire application. The speaker discusses traditional workarounds like creating route groups to split static and dynamic sections, which might work for simple static pages but fails for critical dynamic pages like the product page. Another complex strategy, the 'precompute pattern' involving URL state encoding and `generate static params` with client-side fetching, is also mentioned but deemed too intricate for the current application, highlighting the need for a simpler solution.

The speaker enables `cache components` in `next.config.js`, which defaults all asynchronous calls to dynamic and provides the `use cache` directive. This feature also helps identify unsuspended asynchronous calls, guiding developers to optimize. On the homepage, components like `Hero`, `FeatureCategories`, and `FeatureProducts`, which do not rely on dynamic APIs, are marked with `use cache`. This allows these segments to be statically pre-rendered and included in the static shell via partial pre-rendering, eliminating the need for suspense boundaries and skeletons. The result is a page where only truly user-specific content is dynamic, while the rest is instantly available.

On the Browse All page, a blocking route error is identified due to top-level fetching of categories without a suspense boundary. Initially, a `loading.tsx` is added, but it blocks the entire page, limiting interactivity. The preferred solution involves pushing the category data fetching deeper into the `ResponsiveCategoryFilters` component and applying `use cache` to it, making it part of the static shell. For dynamic `search params`, the data is resolved deeper down and passed as a promise to the `ProductList`, which is then suspended. This approach allows most of the UI to be static and interactive, with only the product list dynamically loading based on search parameters, demonstrating the flexibility of the static/dynamic scale.

The critical product page, initially very slow, is optimized by marking the `Product` and `ProductDetails` components with `use cache` for static rendering. An error arises in `ProductDetails` due to the `SaveProductButton` using dynamic APIs, which is resolved by applying the donut pattern: wrapping the dynamic button with a client component while keeping the rest of the `ProductDetails` cached. For dynamic `params`, `generate static params` is used to pre-render a few predefined product pages, with the rest cached as users generate them. This results in an almost entirely available UI, with only small, truly dynamic chunks like the save button and reviews loading separately.

The deployed, refactored application on Vercel demonstrates remarkable performance improvements. Despite intentionally slowed data fetches, initial page loads are nearly instantaneous, with only truly user-specific dynamic segments loading separately. Cached segments are included in the static shell via partial pre-rendering and can be prefetched by the Next 16 client router, resulting in extremely fast navigations. The application achieved perfect 100 Lighthouse scores on key pages like the home, product, and product list, as verified by Vercel Speed Insights, showcasing the tangible benefits of the applied patterns.

The speaker summarizes that modern Next.js eliminates the rigid static vs. dynamic distinction, allowing developers to choose the desired level of static content. Key patterns include refining architecture by resolving promises deep in the tree and using React Cache to deduplicate work, avoiding prop drilling with context providers and React Use, and composing server and client components with the donut pattern to reduce client-side JS and enable caching. Finally, `use cache` allows granular caching and partial pre-rendering, with Suspense for truly dynamic content. The better the architecture, the easier it is to compose and cache, leading to performant, composable, and scalable applications by default.