Jak optymalizować wydajność i Core Web Vitals w Next.js?

Question

Accepted Answer

Next.js daje ci wiele narzędzi wydajnościowych; ich prawidłowe użycie celuje w Core Web Vitals — LCP (ładowanie), CLS (stabilność układu) i INP (interaktywność).

Zminimalizuj kod JavaScript klienta (największa dźwignia)

tsx

// ✅ Keep components as Server Components; ship "use client" only at interactive leaves
// A Server Component sends ZERO JS for itself → smaller bundle → better INP/load

Supermocą App Router jest wysyłanie mniejszej ilości JS. Ciężka logika i formatowanie danych pozostają na serwerze; tylko naprawdę interaktywne "wyspy" stają się Client Components.

// priority = load eagerly (don't lazy-load the LCP image); width/height prevent CLS ``` ## Optymalizuj czcionki (CLS + ładowanie) ```tsx import { Inter } from "next/font/google"; const inter = Inter({ subsets: ["latin"], display: "swap" }); // self-hosted, no layout shift ``` ## Podziel kod ciężkich komponentów klienta ```tsx import dynamic from "next/dynamic"; const Chart = dynamic(() => import("./Chart"), { ssr: false }); // load only when needed ``` Opóźnij ładowanie dużych, niekrytycznych komponentów klienta (wykresy, edytory, modalne) aby nie powiększały początkowego pakietu. ## Przesyłaj strumieniowo powolną zawartość ```tsx }> // ship the shell instantly, stream slow data → better TTFB/FCP ``` ## Cachuj agresywnie, rewaliduj precyzyjnie ```tsx fetch(url, { next: { revalidate: 3600, tags: ["x"] } }); // static speed + controlled freshness ``` ## Lista kontrolna mapowana na metryki ```text LCP ↓ : next/image + priority, streaming, CDN/static caching, preconnect CLS ↓ : image width/height, next/font, reserve space for dynamic content INP ↓ : less client JS (Server Components), code-splitting, avoid heavy effects ``` ## Mierz, nie zgaduj ```text next build → see per-route JS sizes Lighthouse / PageSpeed Insights, the Web Vitals lib, Vercel Analytics → real metrics @next/bundle-analyzer → find what's bloating the bundle ``` ## Dlaczego to ważne Wydajność Next.js dotyczy głównie **wysyłania mniej kodu JavaScript** (Server Components, code-splitting) i użycia wbudowanych optymalizatorów (`next/image`, `next/font`, streaming, caching) — każdy bezpośrednio powiązany z Core Web Vital. Wiedzieć, które narzędzie naprawia którą metrykę (i mierzyć za pomocą `next build`/Lighthouse zamiast zgadywać) to sposób, w jaki systematycznie osiągasz dobre wyniki LCP/CLS/INP.

Zminimalizuj kod JavaScript klienta (największa dźwignia)

Optymalizuj obraz LCP

Optymalizuj czcionki (CLS + ładowanie)

Podziel kod ciężkich komponentów klienta

Przesyłaj strumieniowo powolną zawartość

Cachuj agresywnie, rewaliduj precyzyjnie

Lista kontrolna mapowana na metryki

Mierz, nie zgaduj

Dlaczego to ważne