DEV Community

pante5ter
pante5ter

Posted on

How I get Next.js sites to load almost instantly — a practical checklist

#nextjs #performance #react #javascript

Speed isn't a vanity metric. On real projects, shaving load time directly moves conversion and Google rankings — Core Web Vitals are a ranking signal, and users bounce before a slow page even paints. Here's the checklist I actually run through on Next.js builds, in the order that gives the biggest wins first.

1. Ship less JavaScript to the client

The single biggest lever. Most "slow React site" problems are really "we hydrated 400KB of JS the user never needed" problems.

  • Keep components as Server Components by default (App Router). Only add 'use client' where you genuinely need state or browser APIs.
  • Push 'use client' down the tree, not up. A whole page doesn't need to be client just because one button is interactive.
  • next/dynamic for anything heavy and below-the-fold (charts, editors, 3D, modals): 
const GalaxyScene = dynamic(
  () => import('@/components/GalaxyScene').then((m) => m.GalaxyScene),
  { ssr: false, loading: () => null },
);
Enter fullscreen mode Exit fullscreen mode

2. Stop layout shift before it starts

CLS is the easiest Vital to wreck and the easiest to fix.

  • Always give next/image explicit width/height (or fill + a sized container).
  • Reserve space for anything async — ads, embeds, banners.
  • Load fonts with next/font so the swap doesn't reflow text: 
import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'], display: 'swap' });
Enter fullscreen mode Exit fullscreen mode

3. Treat images like the heaviest thing on the page (they are)

  • Use next/image — it gives you AVIF/WebP, correct sizing, and lazy loading for free.
  • Mark the hero image priority so it isn't lazy-loaded; lazy-load everything else.
  • Serve dimensions that match the rendered size. A 4000px photo in a 400px slot is wasted bytes.

4. Render on the server, cache aggressively

  • Prefer static rendering / ISR for anything that isn't per-request personalized. A pre-rendered page paints almost instantly.
  • Use fetch caching and revalidate instead of refetching on every hit.
  • Move third-party scripts to next/script with strategy="lazyOnload" so analytics and chat widgets don't block your main thread.

5. Measure on a throttled mobile, not your laptop

Your machine on fiber lies to you. Run Lighthouse in mobile mode with CPU throttling, and watch the field data in Search Console (CrUX) — that's what Google actually ranks on, not your local numbers.

A useful habit: set a performance budget (e.g. < 150KB JS on first load) and let CI fail the build if a PR blows past it. It stops slow creep before it ships.

None of this is exotic. It's just doing the boring things consistently — and the payoff is a site that feels instant, ranks better, and converts more.

I build Next.js sites, Telegram bots and AI automation as a freelancer — if you want a fast, SEO-ready site, you can see my work at vengstudio.online. Happy to answer Next.js performance questions in the comments.

Top comments (0)