← All Notes
05 Engineering Note

From 60 to 98: Practical Next.js Performance Engineering

A playbook for slashing bundle size, optimizing SSR data waterfalls, and improving Core Web Vitals on content-heavy web applications.

Published
Read Time ~2 min read
Author Muhammad Anwar
Topics
#Performance#Nextjs#Engineering

Lighthouse performance scores are not vanity metrics. On consumer and B2B web applications, a drop from 95 to 65 directly correlates with higher bounce rates and degraded SEO rankings.

During my work on client e-commerce platforms and marketing engines at Buildmatiq and mahv.io, we took several heavy web apps from failing Core Web Vitals to consistent 95+ Lighthouse scores. Here is the concrete checklist we used.

1. Eliminate Client-Side Data Waterfalls

The single biggest source of slow Time to Interactive (TTI) is nested useEffect hooks fetching dependent data after initial render.

  • Colocate Data in Server Components: Fetch data at the root layout or server component level in parallel using Promise.all().
  • Stream Below-the-Fold UI: Wrap heavy secondary sections (testimonials, complex charts) in <Suspense fallback={<Skeleton />}> so the main Hero paints instantly.

2. Aggressive Font & Asset Strategy

Fonts and layout shifts (CLS) often ruin mobile experiences.

  • Self-host web fonts in WOFF2 format with font-display: swap;.
  • Always declare explicit width and height ratios or aspect boxes on image wrappers to reserve space before images decode.
  • Use modern formats (WebP / AVIF) with automatic responsive srcset generation.

3. Bundle Audit & Code Splitting

Every kilobyte of unused JavaScript increases CPU parsing time on lower-end mobile devices.

  • Run @next/bundle-analyzer to spot massive third-party dependencies.
  • Dynamically import heavy libraries (such as charting libraries, markdown parsers, or 3D canvas viewers) with next/dynamic so they only load when triggered by user interaction.
  • Replace monolithic utility libraries (like lodash or moment) with native ES6 methods or modular alternatives like date-fns.

4. Edge Caching & Stale-While-Revalidate

Static and content-heavy pages should rarely compute on every single incoming HTTP request.

  • Utilize Incremental Static Regeneration (ISR) or stale-while-revalidate HTTP cache headers with a CDN (Cloudflare or Vercel Edge).
  • Cache warm pages globally so response TTFB (Time to First Byte) drops below 80ms worldwide.

Result

Applying these four principles eliminated render blocking, lowered Cumulative Layout Shift to 0.00, and moved key landing page Lighthouse scores above 98 across desktop and mobile.