## Why Core Web Vitals Actually Matter Google's Core Web Vitals (CWV) are three measurable signals that capture real user experience: | Metric | Measures | Good threshold | |---|---|---| | **LCP** (Largest Contentful Paint) | How fast the main content loads | ≤ 2.5s | | **INP** (Interaction to Next Paint) | How fast the page responds to input | ≤ 200ms | | **CLS** (Cumulative Layout Shift) | How stable the layout is | ≤ 0.1 | Since 2021, CWV have been a ranking signal in Google Search. Since March 2024, **INP replaced FID** as the responsiveness metric — a change that blindsided teams who optimized for the wrong number. Next.js is exceptionally well-equipped to hit "Good" on all three — but only if you don't actively work against its defaults. These are the ten mistakes that do exactly that. ## Mistake #1: Ignoring `next/image` and Rolling Your Own `` ### What goes wrong Nothing destroys LCP faster than a raw `` tag for your hero image. Without `next/image`, you get no automatic WebP/AVIF conversion, no lazy loading by default, no responsive `srcset`, and — critically — no size reservation that prevents layout shift. ```jsx // ❌ The CLS and LCP killer Hero

``` ### What to do instead ```jsx // ✅ Correct: use next/image with priority for above-the-fold images import Image from "next/image"; Hero

``` The `priority` prop is crucial. It tells Next.js to preload the image with a `` tag, directly reducing LCP. **Only use it for the one or two images visible above the fold** — overusing it defeats the purpose. ### CWV impact - **LCP**: `priority` images can reduce LCP by 0.5–1.5s on cold loads - **CLS**: explicit `width`/`height` reserves space, eliminating layout shift from images ## Mistake #2: Over-fetching with Client Components When Server Components Suffice ### What goes wrong A common pattern in Next.js App Router codebases: wrapping entire page trees in `"use client"` because one leaf component needs `useState`. This sends unnecessary JavaScript to the browser, inflating the bundle and delaying interactivity. ```jsx // ❌ Entire page is client-side because of one interactive widget "use client"; export default function BlogPost({ params }) { const [likes, setLikes] = useState(0); // ... entire page rendered client-side } ``` ### What to do instead Push interactivity down to the smallest possible component. Keep the page shell, data fetching, and static markup as Server Components. ```jsx // ✅ page.tsx — Server Component, fetches data, no JS sent import LikeButton from "./LikeButton"; // only this is "use client" export default async function BlogPost({ params }) { const post = await getPost(params.slug); // runs on server return (

{post.title}

{post.content}

{/* isolated client island */}

); } ``` ### CWV impact - **INP**: smaller client bundles mean less main thread work during hydration - **LCP**: server-rendered HTML arrives faster; no waterfall of JS → fetch → render ## Mistake #3: Not Streaming Long Server-Side Renders ### What goes wrong If your page fetches data from a slow API, the entire HTML response blocks until that fetch resolves. Users stare at a blank screen. ```jsx // ❌ Blocks the entire page response until the API responds export default async function Dashboard() { const analytics = await fetchAnalytics(); // slow: 1.2s const reports = await fetchReports(); // slow: 0.9s — sequential! return ; } ``` This is doubly wrong: the fetches are sequential when they could be parallel. ### What to do instead Use `React.Suspense` for streaming and `Promise.all` for parallel fetches: ```jsx // ✅ Streams shell immediately; deferred sections load as data arrives import { Suspense } from "react"; export default function Dashboard() { return (

Dashboard

}> {/* streams when ready */} }> {/* streams independently */}

); } // Inside AnalyticsSection (Server Component) async function AnalyticsSection() { const data = await fetchAnalytics(); // only blocks this section return ; } ``` ### CWV impact - **LCP**: the page shell (including hero content) reaches the browser immediately - **INP**: less JavaScript executes at once since hydration is phased ## Mistake #4: Misusing `useEffect` for Data That Should Come from the Server ### What goes wrong ```jsx // ❌ Classic waterfall: HTML loads → JS loads → effect fires → fetch → render "use client"; export default function ProductList() { const [products, setProducts] = useState([]); useEffect(() => { fetch("/api/products").then(r => r.json()).then(setProducts); }, []); return

{p.name}

; } ``` This creates a **three-stage waterfall**. The user sees nothing meaningful until all three stages complete. ### What to do instead Fetch on the server. If the component truly needs to be interactive, pass server-fetched data as props: ```jsx // ✅ Data is available on first byte of HTML export default async function ProductList() { const products = await getProducts(); // server-side, no waterfall return

{p.name}

; } ``` If you need client-side revalidation, reach for **SWR** or **TanStack Query** with `fallbackData` populated from server props — you get the best of both worlds. ### CWV impact - **LCP**: eliminates the fetch waterfall; content is in the initial HTML - **INP**: no hydration stall waiting for effect-triggered data ## Mistake #5: Shipping Unoptimized Third-Party Scripts ### What goes wrong Analytics, chat widgets, A/B testing tools, and tag managers are among the heaviest contributors to poor INP and LCP. Loaded naively, they block the main thread during the critical load window. ```jsx // ❌ Render-blocking; blocks parser and main thread ``` | Strategy | When it runs | Use for | |---|---|---| | `beforeInteractive` | Before page hydration | Theme init, cookie consent | | `afterInteractive` | After hydration | Analytics, tag managers | | `lazyOnload` | Browser idle time | Chat widgets, social embeds | ### CWV impact - **INP**: main thread freed during critical load window - **LCP**: parser unblocked; resources fetched sooner ## Mistake #6: Not Setting Proper `Cache-Control` and Revalidation ### What goes wrong Developers either cache nothing (every request hits the origin) or cache everything forever (stale data in production). Both extremes hurt performance. ```jsx // ❌ No caching directive — every user triggers a full database query export async function generateStaticParams() { ... } export default async function BlogPost({ params }) { const post = await fetch(`/api/posts/${params.slug}`, { cache: "no-store" // fine for truly dynamic data; overkill for blog posts }); } ``` ### What to do instead Use Next.js's granular caching controls: ```jsx // ✅ Revalidate every 60 seconds — fresh enough, cached enough const post = await fetch(`https://cms.example.com/posts/${slug}`, { next: { revalidate: 60 } // ISR: Incremental Static Regeneration }); // ✅ Tag-based invalidation for on-demand revalidation const post = await fetch(`https://cms.example.com/posts/${slug}`, { next: { tags: [`post-${slug}`] } }); // In your webhook handler: import { revalidateTag } from "next/cache"; revalidateTag(`post-${slug}`); // instant invalidation when content changes ``` For Route Handlers, set explicit `Cache-Control` headers: ```jsx // app/api/products/route.ts export async function GET() { const products = await getProducts(); return Response.json(products, { headers: { "Cache-Control": "public, s-maxage=300, stale-while-revalidate=600", }, }); } ``` ### CWV impact - **LCP**: cached responses arrive orders of magnitude faster than origin fetches - **INP**: reduced API latency means faster client-side state updates ## Mistake #7: Dynamic Imports Without Thought — or Without Them at All ### What goes wrong Two opposite mistakes live here: **Mistake 7a**: Importing heavy client-side libraries at the top level, bloating the initial bundle. ```jsx // ❌ Ships entire chart library to every user, even those who never see the chart import { LineChart } from "recharts"; ``` **Mistake 7b**: Using `next/dynamic` without `ssr: false` for components that cause hydration mismatches, or using it for tiny components where the overhead isn't worth it. ### What to do instead Dynamic-import genuinely heavy, non-critical components. Disable SSR only when the component is truly client-only (e.g., depends on `window`): ```jsx import dynamic from "next/dynamic"; // Heavy chart — load only when needed const LineChart = dynamic(() => import("@/components/charts/LineChart"), { loading: () => , ssr: false, // only if it accesses browser APIs }); // Rich text editor — definitely client-only, definitely heavy const RichTextEditor = dynamic(() => import("@/components/RichTextEditor"), { ssr: false, loading: () => , }); ``` Use the **Next.js Bundle Analyzer** to identify targets: ```bash npm install @next/bundle-analyzer ANALYZE=true next build ``` Anything over 50kb that isn't needed on initial render is a dynamic import candidate. ### CWV impact - **INP**: smaller initial JS bundle means faster Time to Interactive - **LCP**: main thread unblocked sooner; browser can paint earlier ## Mistake #8: Rendering Fonts in a Way That Causes FOUT or Layout Shift ### What goes wrong Loading fonts from Google Fonts directly, or loading them without `font-display: swap` and size adjustments, causes two problems: a flash of unstyled text (FOUT) and layout shift as the font loads and changes element dimensions. ```jsx // ❌ External font request, no preconnect, no size adjustment // In _document.tsx or layout.tsx ``` ### What to do instead Use `next/font`, which automatically self-hosts fonts, eliminates the external network request, and applies `size-adjust` to prevent layout shift: ```jsx // app/layout.tsx import { Merriweather, JetBrains_Mono } from "next/font/google"; const merriweather = Merriweather({ subsets: ["latin"], weight: ["400", "700"], display: "swap", // show fallback font immediately variable: "--font-body", adjustFontFallback: true, // auto size-adjust to minimize CLS }); const jetbrainsMono = JetBrains_Mono({ subsets: ["latin"], variable: "--font-mono", display: "swap", }); export default function RootLayout({ children }) { return ( {children} ); } ``` For local fonts: ```jsx import localFont from "next/font/local"; const brandFont = localFont({ src: "./fonts/BrandFont-Variable.woff2", variable: "--font-brand", display: "swap", }); ``` ### CWV impact - **CLS**: `adjustFontFallback` is the single most impactful CLS fix for text-heavy pages - **LCP**: self-hosted fonts eliminate DNS lookup + TCP handshake to Google's CDN ## Mistake #9: Not Using `generateStaticParams` and `generateMetadata` Correctly ### What goes wrong Teams either skip static generation entirely for dynamic routes (missing a huge performance win) or generate too many static pages at build time (causing 30-minute builds). Equally common: metadata is hardcoded or missing, which affects how social previews and search snippets render — and Open Graph images are served as huge, unoptimized PNGs. ```jsx // ❌ Every blog post hits the database on every request export default async function BlogPost({ params }) { const post = await db.post.findUnique({ where: { slug: params.slug } }); return

; } ``` ### What to do instead Use `generateStaticParams` for your most-visited pages, with fallback for the long tail: ```jsx // app/blog/[slug]/page.tsx // Pre-render only the 100 most popular posts at build time export async function generateStaticParams() { const topPosts = await db.post.findMany({ orderBy: { views: "desc" }, take: 100, select: { slug: true }, }); return topPosts.map(p => ({ slug: p.slug })); } // Other slugs render on-demand and are cached (ISR) export const dynamicParams = true; export const revalidate = 3600; // Dynamic, accurate metadata export async function generateMetadata({ params }) { const post = await getPost(params.slug); // cached — same fetch is deduplicated return { title: post.title, description: post.excerpt, openGraph: { title: post.title, description: post.excerpt, images: [`/api/og?title=${encodeURIComponent(post.title)}`], }, }; } ``` Use `@vercel/og` for dynamically generated Open Graph images that are served as optimized PNGs from the edge: ```jsx // app/api/og/route.tsx import { ImageResponse } from "next/og"; export async function GET(request) { const { searchParams } = new URL(request.url); const title = searchParams.get("title"); return new ImageResponse(

{title}

, { width: 1200, height: 630 } ); } ``` ### CWV impact - **LCP**: statically generated pages are served from CDN edge nodes in ~10ms - **CLS**: proper `` metadata prevents layout recalculations on link unfurls ## Mistake #10: Ignoring the React Compiler and Premature `useMemo`/`useCallback` ### What goes wrong Two opposite but equally damaging patterns appear in Next.js codebases: **Pattern A**: Sprinkling `useMemo` and `useCallback` everywhere "for performance," without profiling. This adds overhead (the memoization itself has a cost), increases code complexity, and often memoizes values that change on every render anyway. ```jsx // ❌ Memoizing a cheap operation — pure overhead const greeting = useMemo(() => `Hello, ${name}!`, [name]); // ❌ useCallback on a function passed to a non-memoized child — no effect const handleClick = useCallback(() => setCount(c => c + 1), []); ``` **Pattern B**: Not memoizing genuinely expensive computations or referentially unstable objects that cause child components to re-render. ```jsx // ❌ New object on every render → child re-renders every time parent renders const config = { theme: "dark", locale: "en" }; // declared inline return ; ``` ### What to do instead **First**: Enable the React Compiler (stable in React 19, supported in Next.js 15+). It automatically applies memoization where it's beneficial: ```js // next.config.ts const nextConfig = { experimental: { reactCompiler: true, }, }; ``` With the React Compiler enabled, manual `useMemo`/`useCallback` becomes largely unnecessary for render optimization. The compiler statically analyzes your components and memoizes them correctly. **Second**: When you do memoize manually, profile first. Use React DevTools Profiler to identify which components actually re-render unnecessarily, then target those specifically. ```jsx // ✅ Memoize genuinely expensive computations const sortedData = useMemo( () => data.slice().sort(complexComparator), [data] // only re-sort when data actually changes ); // ✅ Stable reference for objects/arrays passed as props const chartConfig = useMemo( () => ({ theme, locale, formatters }), [theme, locale] ); ``` ### CWV impact - **INP**: fewer unnecessary re-renders means less main thread work during interactions - React Compiler can reduce re-render counts by 30–60% in complex UIs without any manual annotation ## Putting It Together: A CWV Audit Checklist Before shipping, run through this checklist: **Images** - [ ] All `` tags replaced with `next/image` - [ ] LCP image has `priority` prop - [ ] All images have explicit `width` and `height` **JavaScript** - [ ] No unnecessary `"use client"` at page level - [ ] Heavy libraries are dynamically imported - [ ] Third-party scripts use `next/script` with appropriate `strategy` - [ ] React Compiler enabled (Next.js 15+) **Data fetching** - [ ] No `useEffect` data fetches for data that can come from the server - [ ] Slow data sections wrapped in `` - [ ] Fetches use `Promise.all` or `Promise.allSettled` for parallelism **Caching** - [ ] Static routes use `generateStaticParams` - [ ] Dynamic routes have appropriate `revalidate` values - [ ] API routes have explicit `Cache-Control` headers **Fonts and metadata** - [ ] All fonts loaded via `next/font` (no Google Fonts `` tags) - [ ] `generateMetadata` implemented for all dynamic routes - [ ] Open Graph images generated with `@vercel/og` ## Measure, Don't Guess No performance work should begin without measurement. Use: - **[PageSpeed Insights](https://pagespeed.web.dev)** — real-world CrUX data + Lighthouse in one place - **[web.dev/measure](https://web.dev/measure)** — historical tracking - **Chrome DevTools Performance panel** — trace main thread activity during interactions - **`next build` output** — watch for large bundle warnings - **`ANALYZE=true next build`** with `@next/bundle-analyzer` — visualize what's in your bundles The CrUX (Chrome User Experience Report) data in Search Console is the ground truth Google uses for ranking. Lab scores matter for debugging; field scores matter for SEO. ## Conclusion Next.js gives you an extraordinary set of performance primitives out of the box: Server Components, streaming, image optimization, font optimization, ISR, edge caching. The framework's defaults are, in most cases, the right choice. The mistakes in this article share a common thread: they're all cases of **working against the framework's design** — reaching for client-side patterns when server-side is available, skipping built-in abstractions in favor of manual implementations, or optimizing by intuition rather than measurement. Fix these ten issues and you're not just chasing a score. You're delivering a meaningfully faster experience to real users — users who, according to Google's data, convert better, bounce less, and return more often when pages load fast and respond instantly. That's what Core Web Vitals are really measuring. *Related reading: [Next.js Performance Docs](https://nextjs.org/docs/app/building-your-application/optimizing) · [web.dev Core Web Vitals](https://web.dev/explore/learn-core-web-vitals) · [React Compiler Docs](https://react.dev/learn/react-compiler) · [Chrome CrUX Dashboard](https://developer.chrome.com/docs/crux)*

Articles tagged “Core Web Vitals”

10 Next.js Performance Mistakes Killing Your Core Web Vitals