Core Web Vitals w praktyce: LCP, INP i CLS na zielono

• dane terenowe (CrUX) — Search Console i górna część PageSpeed Insights; to one liczą się w ocenie,
• dane laboratoryjne — Lighthouse, DevTools; służą do diagnozy i porównań przed/po,
• testuj wersję mobilną z ograniczeniem CPU i sieci; dla INP użyj panelu Performance w Chrome DevTools i biblioteki web-vitals do pomiaru u użytkowników.

LCP to zwykle zdjęcie w hero lub duży nagłówek. Rozbij czas na części: odpowiedź serwera (TTFB), opóźnienie zasobu, pobranie i renderowanie.

• serwuj obraz w AVIF lub WebP, w rozmiarach dopasowanych przez srcset i sizes,
• dodaj fetchpriority="high" do obrazu LCP i nie ładuj go leniwie (loading="lazy" tylko poniżej pierwszego ekranu),
• jeśli obraz jest w CSS (tło), dodaj <link rel="preload" as="image">,
• skróć TTFB: cache stron, aktualne PHP, OPcache, cache obiektów, CDN,
• nie blokuj renderowania: krytyczny CSS w <head>, reszta asynchronicznie.

<img src="hero-1200.avif" srcset="hero-800.avif 800w, hero-1200.avif 1200w"
     sizes="(max-width: 800px) 100vw, 1200px" width="1200" height="630"
     fetchpriority="high" decoding="async" alt="Opis zdjęcia">

Słaby INP oznacza, że przeglądarka jest zajęta wykonywaniem JavaScriptu, gdy użytkownik klika. Typowe przyczyny: ciężkie page buildery, slidery, czaty, piksele reklamowe i rozbudowane skrypty zgód.

• usuń nieużywane skrypty i wtyczki, ładuj skrypty z defer,
• skrypty zewnętrzne (czat, mapy, wideo) uruchamiaj po interakcji lub przez fasadę (podgląd zamiast odtwarzacza),
• dziel długie zadania (> 50 ms) — np. scheduler.yield() lub setTimeout między etapami,
• w obsłudze kliknięcia najpierw aktualizuj interfejs, ciężkie obliczenia odkładaj,
• ogranicz rozmiar DOM (cel: poniżej ok. 1500 elementów) i unikaj wymuszonych przeliczeń layoutu.

Przesunięcia układu irytują i powodują przypadkowe kliknięcia. Zasady:

• każdy obraz, wideo i iframe ma atrybuty width i height lub aspect-ratio w CSS,
• banery, reklamy i baner cookies mają zarezerwowane miejsce albo wyświetlają się jako nakładka, nie wypychając treści,
• fonty: font-display: swap plus dopasowanie metryk zastępczych (size-adjust) albo czcionki systemowe,
• animuj transform i opacity, a nie top, height czy margin,
• treści doładowywane dynamicznie wstawiaj poniżej obszaru widocznego lub po akcji użytkownika.

Warstwa dostarczania często daje największy zysk najmniejszym kosztem:

• cache stron (LiteSpeed Cache, WP Rocket lub cache serwera) i cache obiektów (Redis) dla stron dynamicznych,
• kompresja Brotli (lub gzip) i protokół HTTP/2 albo HTTP/3,
• długie nagłówki cache dla statycznych plików z wersjonowaniem nazw (style.css?v=…),
• CDN dla obrazów i plików statycznych, szczególnie przy ruchu z różnych krajów,
• od WordPressa 6.8 rdzeń wspiera Speculation Rules (wstępne pobieranie kolejnych stron) — sprawdź, czy wtyczki cache go nie wyłączają.

Optymalizacja jednorazowa szybko się „rozjeżdża” po kolejnych wtyczkach i skryptach marketingowych. Ustal budżet wydajności:

• maks. waga strony głównej na mobile (np. 1 MB),
• maks. ilość JavaScriptu (np. 200 KB po kompresji),
• wynik Lighthouse mobile ≥ 90 oraz zielone CWV w Search Console.

Sprawdzaj budżet przed każdym wdrożeniem (Lighthouse CI w pipeline albo ręczny test na stagingu) i co miesiąc w raporcie Search Console. Każdy nowy skrypt marketingowy powinien mieć właściciela i uzasadnienie biznesowe.