Do you optimize web performance in Next.js?

Next.js is a popular and powerful framework built on top of React, designed to help teams build fast, scalable web applications.

Without a performance-first approach, applications can quickly become slow due to excessive client-side Javascript, inefficient data fetching or incorrect rendering strategies. Out of the box, Next.js gives you powerful performance tools.

Factors That Affect Web Performance

Web performance in Next.js is commonly the result of multiple choices made throughout the application:

• Rendering strategy - Choosing between static, server-rendered or dynamic pages directly impacts load time and responsiveness
• Client side scripts - Larger client bundles increase parse and execution time, delaying interactivity
• Data fetching patterns - Client-side fetching often causes request waterfalls, while server-side fetching enables faster initial renders
• Caching and revalidation - Explicit caching reduces repeated work and improves response time
• Images, fonts, and media - Unoptimized assets are frequently the largest contributor to slow page loads (Impacts Core Web Vitals such as Largest Contentful Paint)
• Layout stability - Unexpected layout shifts degrade user experience and negatively impact Cumulative Layout Shift metrics
• Hydration and interactivity - Hydrating more UI than necessary increases CPU cost and delays interaction

Optimizing Web Performance

1. Display Images with the built in Next.js Component

Next.js provides an inbuilt <Image/> component, which extends the native HTML <img> element for optimization.

The next/image component automatically optimizes image size, format, and delivery, helping reduce page weight and improve load times. Offscreen images are deferred automatically (lazily loaded), reducing LCP. The Next.js image component also constrains your image dimensions, preventing layout shifts from occurring when the image loads on the client.

Out of the box, the <Image/> component is pretty straight forward to use.

<Image
  src="..."
  alt="..."
  width={x-Pixels}
  height={y-Pixels}
  
  //or use fill
  fill
/>

Several optional props can further enhance perceived performance and visual stability:

• placeholder - Displays a temporary image while the full asset loads (using blur provides a smoother experience for slower networks
• quality - controls compression level to reduce file size
• priority - Marks critical above-the-fold images for preloading, improves LCP

2. Default to Server Components

Next.js allows the user to control the environment where application code can be executed in: the server and the client.

Server-side rendering reduces the amount of JavaScript sent to the browser, improves initial load performance and keeps sensitive logic and credentials out of the client bundle.

Client components ('use client') should only be introduced when the UI requires browser only functionality, such as:

• Hooks - useState, useEffect, useContext etc.
• Event Handlers - onClick , onChange
• Direct access to browser APIs - window, document, localStorage

When introducing a Client Component, ensure that you're keeping the client boundary as small as possible and isolate interactivity into focused components.

3. Minimize JavaScript shipped to the browser

The fastest JavaScript is the JavaScript you don't need to send. Large client bundles increase download size, parse time and execution cost. All of which delays interactivity and Core Web Vitals

1. Use the @next/bundle-analyzer to get a visual map of everything bundled in your project - this will help identify suspiciously large or necessarily installed dependencies
2. Use dynamic imports - these let you load code only when it's needed. This is great for charts, maps, modals and rich-text editors
3. Avoid heavy dependencies - do you really need to bundle the entirety of lodash? or can it be replaced with one fn import?
4. Keep heavy code on the Server - tying in with our previous major point, reduce the usage of the client.

4. Fetch on the server side and prevent fetch waterfalls

Waterfalls are usually beautiful… but for React developers they can be quite scary. A fetch waterfall is a performance issue that occurs when multiple API calls or fetch requests are chained together, and executed one after another (as opposed to completing them concurrently.

This generally will occur when the page loads first, then data fetching begins, then the UI updates. This effect can be compounded if there are many child components on one page fetching data.

Consequently, this delays page loads 😓

❌ Figure: Bad example - Fetch Waterfall

So how do I avoid recreating Niagara Falls?

1. Fetch data on the server - only fetch on the browser when data is truly user-specific
2. Parallelize requests where possible - don't let independent requests block each other
3. Cache and revalidate intentionally - don't force per-request fetching unless its required

5. Choose the correct rendering strategy

Selecting the appropriate rendering strategy is one of the biggest determinants of performance in Next.js.

The easiest way to think about these strategies is on an axis of when the HTML is created

Build -------- Request -------- Browser
  |               |                |
 SSG           SSR, ISR           CSR  

Next.js supports multiple rendering approaches, each suited to a different use case:

• Recommended: Static-Site Generation (SSG) - HTML is generated at build time. Client is provided with static files. HTML is reused for every user. Does not have access to request information.
• Server-Side Rendering (SSR) - The server generates the HTML at the moment a client requests a page. Every request can produce different HTML.

• Incremental Static Regeneration (ISR) - A combination of SSR and SSG, ISR controls how long a page stays “fresh”, and when a stale page gets rebuilt. It allows static generation on a per-page basis without needing to rebuild the entire site (this is what we use for SSW Rules!)
• Client Side Rendering (CSR) - The browser takes the load of rendering a UI using JavaScript. After a request for a site is made, the browser will parse HTML, construct the DOM, and then download the JS to be executed.