Fixing Page Speed in Next.js: Server Response and Load Time

Why Next.js pages get slow at the server

In Next.js, every route ends up as one of three things. It can be built once at build time and served as a file. It can be built, cached, and rebuilt in the background after a set time. Or it can be rendered on the server for each request. The first two are about as fast as a web page can be served. The third is only as fast as the slowest thing the server waits for while rendering.

The trouble is that a route can move from the first group to the third without anyone deciding it should. Reading a cookie in a shared layout, reading the query string, or a data request marked as uncached is enough. Once that happens, every visit waits for the server to render the page, and if the render waits for an API or database, the visitor waits too.

The other common causes sit around the rendering itself:

• Data requests one after another. Several await calls in a row, each waiting for the previous one, add their times together.
• Distance. A serverless function in one region calling a database in another pays the round trip on every query.
• Middleware on every request. Code that runs before each request, including requests for images and scripts, adds time even to cached pages.
• Missing or wrong cache headers. A self-hosted app behind a proxy or CDN that sends no-store on everything will never be served from the edge.
• Cold starts. On serverless hosting, a function that has not run recently needs time to start, which shows up as occasional slow responses.

These are mostly problems of Time to First Byte, which is not one of the Core Web Vitals but delays everything that follows it, including the main content. For the front-end side of the framework, such as image and font components and hydration cost, see Core Web Vitals in Next.js and Nuxt.

Measuring server response per route

Start with the Page Speed Analyzer on one URL for each route type: the home page, a content page, an article, a product or listing page, and any search or account pages. Note the server response time for each. Then check each route from the command line so you can see the cache headers alongside the timing:

for u in / /about /blog/spring-update /products/oak-table; do
  curl -s -o /dev/null -D /tmp/h.txt \
    -w "$u  first byte: %{time_starttransfer}s  total: %{time_total}s\n" \
    "https://www.example.co.uk$u"
  grep -iE "^(cache-control|x-nextjs-cache|x-vercel-cache|age):" /tmp/h.txt
done

Run it two or three times. The first request may miss the cache; later ones should hit it. What the headers tell you:

A route that should be the same for every visitor but shows no cache hit and a slow first byte is your first target. A route that must be dynamic but is slow needs its data work examined instead.

The fix, step by step

Code patterns that keep routes fast

Before: a route that renders on every request

// app/(site)/layout.tsx - shared by every marketing page
import { cookies } from 'next/headers';

export default async function SiteLayout({ children }) {
  const session = (await cookies()).get('session');   // makes every page dynamic
  const nav = await fetch('https://cms.example.com/api/nav').then(r => r.json()); // uncached
  const footer = await fetch('https://cms.example.com/api/footer').then(r => r.json()); // waits for nav
  return (
    <>
      <Header nav={nav} signedIn={!!session} />
      {children}
      <Footer data={footer} />
    </>
  );
}

After: cached, parallel, with the per-visitor part split out

// app/(site)/layout.tsx
import AccountLink from './account-link'; // 'use client'; reads session in the browser

async function getNav() {
  return fetch('https://cms.example.com/api/nav', {
    next: { revalidate: 3600, tags: ['nav'] },
  }).then(r => r.json());
}
async function getFooter() {
  return fetch('https://cms.example.com/api/footer', {
    next: { revalidate: 86400, tags: ['footer'] },
  }).then(r => r.json());
}

export default async function SiteLayout({ children }) {
  const [nav, footer] = await Promise.all([getNav(), getFooter()]);
  return (
    <>
      <Header nav={nav}><AccountLink /></Header>
      {children}
      <Footer data={footer} />
    </>
  );
}

The layout no longer reads cookies on the server, so pages beneath it can be static. The two CMS requests are cached for an hour and a day, run at the same time, and can be refreshed early from a CMS webhook that calls revalidateTag. Check the exact arguments for your version, as the revalidation API has changed between releases.

Middleware that skips static files

// middleware.ts (proxy.ts in Next.js 16 and later)
export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico|images/|robots.txt|sitemap.xml).*)'],
};

Fixed redirects in config

// next.config.js
module.exports = {
  async redirects() {
    return [
      { source: '/old-services', destination: '/services', permanent: true },
      { source: '/blog/:slug/amp', destination: '/blog/:slug', permanent: true },
    ];
  },
};

Caching changes between Next.js versions

Caching behaviour is the part of Next.js that has changed most between major versions, which is why advice copied from older articles often does not work. Confirm the behaviour in the documentation for the version you run.

• Next.js 14. In the App Router, fetch requests were cached by default unless opted out, and GET route handlers were cached by default. Many sites that upgraded found pages became slower because they relied on this.
• Next.js 15. fetch requests and GET route handlers are no longer cached by default, and request APIs such as cookies(), headers() and params became asynchronous. Pages still prerender where they use no dynamic APIs, but data they fetch at request time is fetched fresh unless you say otherwise.
• Next.js 16. Introduces an opt-in caching model built around the use cache directive and cache lifetime profiles, and renames middleware to proxy. If you enable the new model, the older route segment options such as revalidate are replaced by it, so follow the upgrade guide rather than mixing the two.

The Pages Router works differently. getStaticProps with a revalidate value gives incremental regeneration. getServerSideProps runs for every request and sends no shared cache header unless you set one, for example with res.setHeader('Cache-Control', 'public, s-maxage=60, stale-while-revalidate=300') when the page is the same for all visitors.

Self-hosting and platform notes

Vercel

Static and revalidated pages are cached at the edge automatically. The main settings to check are the function region, which should be near your database, and whether routes you expected to be cached show x-vercel-cache: HIT. Functions that run rarely can start slowly; keeping pages static avoids that for most visitors.

Node server behind nginx

Build with output: 'standalone' for a smaller deployment and run it with a process manager. Next.js compresses responses with gzip by default; if nginx or your CDN handles compression, set compress: false so the work is not done twice and Brotli can be used at the proxy. Let nginx serve /_next/static directly from disk with a long lifetime if you prefer, and make sure it passes the app's cache-control headers through for HTML.

More than one instance

Each self-hosted instance keeps its own cache of rendered and revalidated pages by default. Behind a load balancer this means different visitors may hit cold caches, and revalidation on one instance does not update the others. Configure a shared cache handler, for example backed by Redis, when you run several instances.

Images

The built-in image optimisation resizes images on the server the first time each size is requested, which can make first requests slow and uses processor time on your server. Make sure its cache persists between deployments, or use an external image service or CDN with the image component's loader option.

Keeping a Next.js site fast

• Check the route table in review. Save the next build route table in your pull request or deployment log, and flag any route that changes from static to rendered on demand.
• Set lifetimes deliberately. Give every data source an explicit cache lifetime and a tag, rather than relying on defaults that change between versions.
• Test first byte after deployment. Run the curl loop against production after each release and compare with the previous result.
• Read the upgrade guide for caching changes. Before each major upgrade, read the caching section of the release notes and re-test the routes that matter most.
• Keep the Page Speed Analyzer running on key routes. A regular check on one URL per route type catches a slow template before it affects every page built on it.