← All posts

Near-instant Next.js: a practical App Router checklist

Server Components by default, less client JS, next/image, no CLS, caching, next/script, and measuring on throttled mobile—not your laptop.

Tags
NewsfrontendPerformance
Near-instant Next.js: a practical App Router checklist
Contents

In brief

A practical checklist on Dev.to for speeding up Next.js App Router sites: less client JavaScript, stable layout without CLS, image optimization, server rendering with cache, and measuring on throttled mobile—not a dev laptop. The author ties speed to conversion and Core Web Vitals as a Google ranking signal.

What happened

The article walks from the biggest lever to infrastructure habits.

1. Ship less JS to the client. Most “slow React sites” hydrate hundreds of kilobytes of JS the user never needed. The fix: Server Components by default, 'use client' only where state or browser APIs are required, and push the client boundary down the tree, not up to the whole page. Heavy blocks (charts, 3D, modals) via next/dynamic with ssr: false.

2. Stop layout shift before it starts. Explicit width/height on next/image (or fill + a sized container), reserved space for async content, fonts via next/font with display: 'swap'.

3. Treat images as the heaviest asset. next/image delivers AVIF/WebP, sizing, and lazy loading; mark the hero with priority, lazy-load the rest; do not serve 4000px photos in a 400px slot.

4. Render on the server, cache aggressively. Static/ISR for anything not personalized per request; fetch caching and revalidate; third-party scripts through next/script with strategy="lazyOnload".

5. Measure correctly. Lighthouse in mobile mode with CPU throttling; field data in Search Console (CrUX). Optionally—a performance budget in CI (e.g. < 150 KB JS on first load).

Why it matters

The checklist is not exotic—it is consistent App Router hygiene. Server Components are the default; every extra 'use client' on a layout pulls the whole subtree into the bundle.

Core Web Vitals affect SEO and bounce rate; local runs on a MacBook over fiber systematically overstate performance. Throttled mobile plus CrUX is closer to what Google and real users see.

A CI performance budget catches slow regressions at PR time—cheaper than debugging conversion drops after release.

In practice

Run through the checklist before a production Next.js release:

  1. Audit 'use client': can the component stay server-only?
  2. Hero and above-the-fold—no lazy load; below-the-fold charts—dynamic(..., { ssr: false }).
  3. Every <Image> with dimensions; fonts only via next/font.
  4. Catalog/blog pages—static or ISR; do not mix personalization with public cache without reason.
  5. Analytics/chat widgets—lazyOnload, do not block the main thread.
  6. Lighthouse mobile plus CrUX check; fail the build on budget if JS grows.

If the site feels fast only for you, retest on Slow 4G and a mid-tier Android device.

Takeaway

Near-instant Next.js is App Router done right: server-first, minimal client JS, discipline with media and cache, honest metrics. The Dev.to checklist works well as a runbook before every major frontend release.