Performance optimalisatie in Next.js: van 4s naar 0.8s

Vorige maand deed ik een performance audit op een Next.js productie-app. De Largest Contentful Paint (LCP) was 4.1 seconden op mobiel. Na een week optimalisatie: 0.8 seconden. Hier zijn de exacte stappen die ik heb genomen.

De uitgangssituatie

De app was een dashboard met ~15 pagina's, gebouwd met Next.js 16 en Tailwind CSS. De Core Web Vitals waren:

Stap 1: Image optimalisatie (-0.9s)

De homepage had een hero image van 2.4MB als PNG. De eerste fix was de makkelijkste:

// ❌ Voorheen
<img src="/hero.png" alt="Dashboard preview" />
 
// ✅ Na optimalisatie
<Image
  src="/hero.png"
  alt="Dashboard preview"
  width={1200}
  height={630}
  priority
  sizes="(max-width: 768px) 100vw, 80vw"
/>

De priority prop voorkomt lazy loading voor above-the-fold images. De sizes prop zorgt ervoor dat Next.js de juiste afbeeldingsgrootte stuurt per viewport.

Resultaat: 2.4MB → 180KB WebP. LCP van 4.1s naar 3.2s.

Stap 2: Font optimalisatie (-0.6s)

De app laadde drie fonts via Google Fonts — elk met een render-blocking request. De fix:

// next.config.ts
import { Inter, DM_Serif_Display, JetBrains_Mono } from 'next/font/google';
 
const inter = Inter({ subsets: ['latin'], display: 'swap' });
const dmSerif = DM_Serif_Display({ weight: '400', subsets: ['latin'], display: 'swap' });

next/font host de fonts lokaal, elimineert de DNS lookup naar Google, en voegt font-display: swap toe.

Resultaat: 3 externe requests geëlimineerd. LCP naar 2.6s.

Stap 3: JavaScript bundle verkleinen (-0.8s)

Met @next/bundle-analyzer ontdekte ik twee problemen:

1. Chart.js werd volledig geïmporteerd (210KB) terwijl ik alleen bar charts gebruikte
2. date-fns importeerde de hele library (75KB) in plaats van individuele functies

// ❌ Import alles
import { format, parseISO, differenceInDays } from 'date-fns';
 
// ✅ Tree-shakeable imports
import format from 'date-fns/format';
import parseISO from 'date-fns/parseISO';

En voor Chart.js: registreer alleen de modules die je gebruikt (zie mijn BlogChart component).

Resultaat: Totale JS bundle van 485KB naar 220KB. LCP naar 1.8s.

Stap 4: Server-side caching (-0.6s)

De pagina deed 4 database queries bij elk request. Twee daarvan veranderden zelden:

// Layout data cached voor 1 uur
const navigation = await unstable_cache(
  () => getNavigationItems(),
  ['nav-items'],
  { revalidate: 3600 }
)();
 
// User-specifieke data altijd vers
const dashboardData = await getDashboardData(userId);

Resultaat: TTFB van 1.2s naar 0.4s. LCP naar 1.2s.

Stap 5: Streaming met Suspense (-0.4s)

De dashboard pagina wachtte tot alle data geladen was voordat er iets werd getoond. Met Suspense boundaries stream je de snelle content eerst:

export default function Dashboard() {
  return (
    <div>
      {/* Snel: uit cache */}
      <DashboardHeader />
 
      {/* Langzaam: database query */}
      <Suspense fallback={<ChartSkeleton />}>
        <RevenueChart />
      </Suspense>
 
      <Suspense fallback={<TableSkeleton />}>
        <RecentOrders />
      </Suspense>
    </div>
  );
}

Resultaat: LCP naar 0.8s. De gebruiker ziet direct content terwijl charts laden.

Eindresultaat

Bronnen

De tools die ik gebruikte:

• Lighthouse voor de initiële audit
• @next/bundle-analyzer voor bundle analyse
• WebPageTest voor real-world metingen op verschillende verbindingen
• Chrome DevTools Performance tab voor waterfall analyse