Core Web Vitals 2024
LCP, INP i CLS — metryki wydajności Google, optymalizacja obrazów, Long Tasks, layout shift i monitoring w CI/CD.
6 metryk wydajności web
LCP, INP, CLS (Core Web Vitals) i FCP, TTFB, TBT (dodatkowe) — cele, co mierzą, jak optymalizować i jakich narzędzi używać.
| Metryka | Cel (dobry) | Co mierzy | Optymalizacja | Narzędzia |
|---|---|---|---|---|
| LCP (Largest CP) | poniżej 2.5s | Szybkość ładowania widocznej treści | Obrazy WebP/AVIF, preload, CDN, TTFB | Lighthouse, PageSpeed, CrUX |
| INP (Interaction NP) | poniżej 200ms | Responsywność na interakcje | Long Tasks, React memo, Web Workers | Chrome DevTools, LoAF API |
| CLS (Cumulative LS) | poniżej 0.1 | Wizualna stabilność layoutu | width/height obrazów, font-display, skeleton | Lighthouse, Layout Shift Regions |
| FCP (First CP) | poniżej 1.8s | Pierwszy render treści | Krytyczny CSS inline, brak render-blocking | Lighthouse, WebPageTest |
| TTFB (Time to FB) | poniżej 800ms | Czas odpowiedzi serwera | Edge functions, CDN, server cache | WebPageTest, Network tab |
| TBT (Total BT) | poniżej 200ms | Main thread blocking (proxy INP) | Code splitting, defer JS, lazy load | Lighthouse (lab data) |
Często zadawane pytania
Co to są Core Web Vitals i dlaczego wpływają na SEO?
Core Web Vitals: metryki wydajności web zdefiniowane przez Google (2020). Od 2021 — czynnik rankingowy Google (Page Experience signal). Trzy metryki: LCP (Largest Contentful Paint): szybkość ładowania głównej treści. Dobry: poniżej 2.5s. Wymaga poprawy: 2.5-4s. Zły: powyżej 4s. INP (Interaction to Next Paint): responsywność na interakcje użytkownika (zastąpił FID w 2024). Dobry: poniżej 200ms. Wymaga poprawy: 200-500ms. Zły: powyżej 500ms. CLS (Cumulative Layout Shift): wizualna stabilność (elementy nie przeskakują). Dobry: poniżej 0.1. Wymaga poprawy: 0.1-0.25. Zły: powyżej 0.25. Dodatkowe metryki: FCP (First Contentful Paint) — pierwszy render. TTFB (Time to First Byte) — czas do pierwszego bajtu od serwera. TBT (Total Blocking Time) — czas blokowania main thread. Narzędzia pomiarowe: PageSpeed Insights (Google). Lighthouse (Chrome DevTools). Chrome User Experience Report (CrUX — rzeczywiste dane). Search Console (Core Web Vitals report). WebPageTest. DebugBear. Dane field vs lab: Field data (CrUX) — rzeczywiste dane użytkowników (warunki różne). Lab data (Lighthouse) — kontrolowane środowisko (laptop, cable). Google ranking używa Field data.
LCP — jak optymalizować Largest Contentful Paint?
LCP element: największy widoczny element (obraz, video poster, tekst, background-image). Najczęstsze LCP elementy: hero image, H1, logo. Przyczyny złego LCP: wolny serwer (TTFB). Render-blocking resources (CSS, JS). Wolne ładowanie LCP zasobu. Slow resource load (obrazy bez optymalizacji). Optymalizacja LCP: 1. Priorytet LCP zasobu: fetchpriority='high' na LCP image. Preload: link rel='preload' as='image'. Eliminuje waterfall. 2. Optymalizacja obrazów: format WebP/AVIF (40-60% mniejszy od JPEG). next/image — automatyczna optymalizacja. Responsive images (srcset, sizes). Lazy loading tylko non-LCP (loading='lazy' NIE na LCP). 3. CDN i caching: statyczne zasoby przez CDN (CloudFront, Cloudflare). cache-control: max-age=31536000 (immutable). 4. TTFB: server-side caching (Redis, Varnish). Database query optimization. Edge functions (Vercel, Cloudflare). 5. CSS optimization: krytyczny CSS inline (Critical CSS). defer non-critical CSS. Usunięcie unused CSS (Tailwind PurgeCSS robi to automatycznie). Font optimization: font-display: swap. Preload Google Fonts lub self-host. Subset fonts (tylko potrzebne znaki). 6. Eliminacja render-blocking JS: defer, async scripts. Module scripts domyślnie defer.
INP — jak optymalizować Interaction to Next Paint (zastępca FID)?
INP (Interaction to Next Paint): mierzy czas od interakcji użytkownika do następnego wyrenderowania. Zastąpił FID (First Input Delay) w marcu 2024. Typy interakcji: click, keydown, keypress. INP = najgorszy percentyl (98th) interakcji na stronie. Przyczyny złego INP: długie JavaScript tasks (Long Tasks). Main thread blocking. Nadmierne re-rendery React. Zbyt dużo danych w render. Sync API calls blokujące. Optymalizacja INP: 1. Long Tasks: podziel na mniejsze chunki (scheduler.yield()). Time slicing — yield co N ms. setTimeout(fn, 0) — oddaj kontrolę na chwilę. requestIdleCallback — nieistotne zadania w idle. 2. React optymalizacje: useDeferredValue — odrocz render niestotnych części. startTransition — nie pilne aktualizacje. useTransition — pending state. React.memo, useMemo, useCallback — unikaj zbędnych re-renderów. Virtualizacja długich list (react-window, react-virtual, TanStack Virtual). 3. Web Workers: przenieś intensywne obliczenia poza main thread. Comlink — prosty API dla Web Workers. 4. Profiling: Chrome DevTools Performance tab. React DevTools Profiler. 'Interactions' timeline. Long tasks (>50ms) oznaczone czerwono. INP attribution: LoAF (Long Animation Frames) API. element-timing. 5. Lighthouse: TBT (Total Blocking Time) jako proxy dla INP w lab.
CLS — jak eliminować layout shift i zapewnić wizualną stabilność?
CLS (Cumulative Layout Shift): suma nieoczekiwanych przesunięć layoutu podczas ładowania strony. Jak obliczany: impact fraction (% ekranu przesunięty) * distance fraction (% ekranu, o który przesunięty). Przyczyny CLS: obrazy bez wymiarów (width, height lub aspect-ratio). Reklamy, embeds, iframes bez zarezerwowanego miejsca. Dynamicznie wstrzykiwane treści (bannery, cookies). Fonty powodujące FOUT/FOIT. Animacje wyzwalające layout. Optymalizacja CLS: 1. Zawsze określaj width i height obrazów: img width='800' height='600'. CSS: aspect-ratio: 800/600. Zapobiega layout shift przy ładowaniu. 2. Fonty: font-display: optional (najlepszy CLS, ryzyko niewidoczności). font-display: swap (dobry UX, gorszy CLS). Preload fonts. size-adjust, ascent-override, descent-override. f-mods (Font Metric Overrides) — dopasowanie fallback do custom font. 3. Reklamy i dynamic content: min-height dla placeholdera. Ładuj na dole strony lub poza viewport. 4. Animacje bez layout trigger: używaj transform i opacity (nie zmień margin, padding, top, left). will-change: transform (GPU acceleration). 5. Skeleton loading: placeholder o tych samych wymiarach co content. Zapobiega CLS gdy content się ładuje. 6. Scroll anchoring: overflow-anchor (domyślnie włączone). content-visibility: auto — wirtualizacja off-screen content (uwaga: może powodować CLS). 7. Chrome DevTools Layout Shift Regions (fioletowe).
Performance budgeting i monitoring Core Web Vitals w CI/CD?
Performance Budget: zdefiniowane limity metryk. Lighthouse CI: sprawdza metryki w CI. Blokuje PR jeśli przekroczone. GitHub Action: Lighthouse CI GitHub Action. lhci autorun — pełne portfolio stron. assertions w lighthouserc.json. Bundlephobia: rozmiar dependencji przed instalacją. Bundlemon: monitoring rozmiaru bundle w CI. size-limit: limit rozmiaru bundle (JS). Webpack Bundle Analyzer: wizualizacja bundles. @next/bundle-analyzer — Next.js. Vite Visualizer: rollup-plugin-visualizer. import cost (VSCode extension) — inline rozmiar importu. Real User Monitoring (RUM): Google Analytics 4 (Core Web Vitals w GA4 Events). Vercel Analytics — wbudowane RUM. Sentry Performance — transaction monitoring. Datadog RUM. web-vitals library: onLCP, onINP, onCLS, onFCP, onTTFB. Wysyłanie do Google Analytics: sendBeacon API. Ciągłe monitorowanie: CrUX API (Chrome User Experience Report). DebugBear — automated monitoring. SpeedCurve — advanced performance monitoring. Ahrefs / Semrush — CWV per strona. Search Console — Core Web Vitals report (field data). Recomendacje Next.js: next/image (LCP optimization). next/font (font optimization). Turbopack (szybszy dev build). Optimistic UI (INP). PPR (LCP via streaming).
Powiązane artykuły
Skontaktuj się z nami
Porozmawiajmy o Twoim projekcie. Bezpłatna wycena w ciągu 24 godzin.
Wyślij zapytanie
Telefon
+48 790 814 814
Pon-Pt: 9:00 - 18:00
adam@fotz.pl
Odpowiadamy w ciągu 24h
Adres
Plac Wolności 16
61-739 Poznań
Godziny pracy
Wolisz porozmawiać?
Zadzwoń teraz i porozmawiaj z naszym specjalistą o Twoim projekcie.
Zadzwoń teraz