Google cały czas grzebie w metrykach, a w 2025 roku wprowadził spore zmiany, które każdy szanujący się web developer powinien mieć w małym palcu.
Najważniejsza zmiana? Usunięcie First Input Delay (FID) i zastąpienie go czymś, co nazywa się Interaction to Next Paint (INP). Brzmi skomplikowanie? Spokojnie - w tym wpisie rozłożę wszystko na czynniki pierwsze i pokażę, jak je optymalizować, aby każda strona działała jak szwajcarski zegarek.
Co się zmieniło w Core Web Vitals w 2025?
Żegnaj FID, witaj INP
12 marca 2024 roku Google oficjalnie wyrzuicił FID do kosza i zastąpił go INP-em. W 2025 roku jest to już pełna zmiana, więc można stwierdzić, że FID jest pieśnią przeszłości.
Dlaczego pożegnaliśmy FID?
FID sprawdzał tylko pierwsze kliknięcie użytkownika - reszta się nie liczyła.
INP patrzy na WSZYSTKIE interakcje podczas całej wizyty na stronie.
INP lepiej pokazuje, jak naprawdę frustrujące może być doświadczenie użytkownika na źle zoptymalizowanej stronie.
Nowa metryka na horyzoncie: Engagement Reliability
Google testuje też nową metrykę - Engagement Reliability Score (ER). Na razie to eksperyment, ale warto mieć na niego oko. ER sprawdza, jak często użytkownicy mogą normalnie klikać i używać strony bez problemu.
Trzy filary Core Web Vitals
1. Largest Contentful Paint (LCP) - czyli "kiedy coś się pojawia"
LCP mierzy, ile czasu trwa, zanim największy element na stronie (zazwyczaj duży obrazek na górze strony lub obszerny blok tekstu) wyrenderuje się do końca.
Jak to oceniać:
Super wynik: do 2,5 sekundy 😎
Do poprawki: 2,5 do 4 sekund 🤨
Koszmar: powyżej 4 sekund 😫
Przykład kodu, który nie psuje LCP:
<!-- Obrazek typu Hero, z odpowiednimi atrybutami -->
<img src="hero-image.webp"
width="1200"
height="600"
fetchpriority="high"
loading="eager"
alt="Główny obraz strony"><link rel="preload" href="hero-image.webp" as="image">
<link rel="preload" href="main-font.woff2" as="font" type="font/woff2" crossorigin>Jak poprawić LCP - konkretne techniki
1. Optymalizacja obrazków
Zadbajmy o to, aby nasze obrazki, które wyświetlamy na konkretnej stronie, były zoptymalizowane. Dzięki narzędziom takim, jak TinyPNG lub Squoosh, możemy znacząco zmniejszyć ich wagę bez drastycznego wpływu na jakość.
Dla obrazków, które muszą być zawsze widoczne zaraz po załadowaniu strony i jeszcze przed jakąkolwiek interakcją użytkownika (zwłaszcza związaną ze scrollowaniem), zawsze korzystajmy ze specjalnego atrybutu HTML: fetchpriority="high", który sprawi, że przeglądarka spróbuje pobrać ten konkretny zasób w pierwszej kolejności i z najwyższym priorytetem. Skrócenie czasu pobierania takiego zasobu można skrócić nawet o 55%!
2. Lazy loading treści, które nie są widoczne od razu
Stosując techniki takie, jak lazy loading, możemy zadbać o to, żeby obrazki, które nie są potrzebne od razu, a dopiero po przescrollowaniu w dół, ładowały się z opóźnieniem i na żądanie. Dzięki temu urządzenia i łącza naszych użytkowników zaoszczędzą trochę przepustowości i zasobów na renderowanie strony, dzięki czemu najważniejsze treści above the fold wyrenderują się sprawniej i szybciej.
W obencych czasach wprowadzenie lazy loadingu dla obrazków jest niezwykle proste i obsługiwane natywnie przez większość popularnych przeglądarek. Zobacz artykuł na MDN poświęcony dokładnie temu zagadnieniu.
3. Optymalizacja Time To First Byte, czyli szybki serwer i dobry cache
Im szybsza odpowiedź serwera i przesyłanie z niego zasobów, tym lepsze czasy ładowania i tym lepszy LCP.
Używaj CDN do serwowania treści ze swojej strony - na rynku istnieje kilka serwisów, oferujących darmowe usługi w tym zakresie. Osobiście korzystam z Cloudflare, którego używam do zarządzania moimi domenami i jednocześnie jako proxy z uruchomionym CDN. Dzięki temu zasoby z moich stron automatycznie lądują na serwerach krańcowych, skąd trafiają do użytkowników po najkrótszej trasie.
Spośród innych darmowych opcji, są do wyboru jeszcze Amazon CloudFront oraz jsDelivr. Więcej niestety nie znam, ale nie oznacza to, że nie istnieją - jeśli aktualnie szukasz czegoś dla siebie, to warto się rozejrzeć. ☺️
4. Fonty nieblokujące renderowania
Jeśli na swojej stronie korzystamy z niestandardowych fontów, w swoim CSS deklarującym ich źródło warto dodać taki wiersz:
@font-face {
...
font-display: swap;
}Dzięki temu fonty, które załadują się nieco później, nie zablokują renderowania bloków tekstu.
2. Interaction to Next Paint (INP) - jak szybko coś się zmienia, gdy klikasz
INP patrzy na to, jak długo trzeba czekać po wykonaniu przez użytkownika interakcji, do momentu, aż coś w wyglądzie strony się zmieni. I to nie tylko przy pierwszej interakcji, ale każdej.
Jak ocenić wyniki:
Świetnie: do 200 ms 😎
Średnio: między 201 a 500 ms 🤨
Tragedia: powyżej 500 ms 😫
Jak poprawić INP
1. Eliminuj czasochłonne zadania z wątku głównego
Korzystaj z dobrodziejstw tworzenia kodu asynchronicznego w JavaScript, aby oddelegowywać czaso- i zasobochłonne zadania do kolejki asynchronicznych mikrozadań w Event Loopie (opisałem to szerzej we wpisie o Event Loop).
Źle:
// ❌ Długie zadanie blokujące główny wątek
function processLargeArray(items) {
for (let i = 0; i < items.length; i++) {
// Ciężkie operacje
processItem(items[i]);
}
}Dobrze:
// ✅ Podział na mniejsze zadania:
// każda iteracja wypchnięta do kolejki mikrozadań
async function processLargeArrayOptimized(items) {
const batchSize = 50;
for (let i = 0; i < items.length; i += batchSize) {
const batch = items.slice(i, i + batchSize); // Przetwarzaj batch
batch.forEach(item => processItem(item)); // Oddaj kontrolę przeglądarce
await new Promise(resolve => setTimeout(resolve, 0));
}
}2. Stosuj techniki debounce oraz throttling
Debounce oraz throttling to znane od zarania dziejów techniki opóźniania wykonywania akcji po interakcji.
Debouncing polega na tym, że opóźniamy wykonanie akcji do momentu, aż użytkownik skończy wykonywać wiele interakcji szybko i pod rząd. Przykładowo: kiedy użytkownik wpisuje frazę w pole tekstowe z podpowiedziami, to nie bombardujemy bazy danych zapytaniami po każdym wciśnięciu klawisza. Zamiast tego, wykonujemy zapytanie na spokojnie, kiedy już skończy wpisywać frazę, na przykład po 300 milisekundach od wciśnięcia ostatniego klawisza.
Debouncing łatwo zaimplementować samemu, ale możemy skorzystać z gotowych implementacji np. w bibliotece lodash:
const searchInput = document.getElementById('search');
const debouncedSearch = debounce(searchInDatabase, 300);
searchInput.addEventListener('input', debouncedSearch);Throttling z kolei to technika, która "przepuszcza" interakcje tylko raz na X czasu. Wyobraź sobie bramkę, która otwiera się i przepuszcza jedną piłkę co sekundę, zatrzymując wszystkie pozostałe - dopiero w następnej sekundzie zostanie przepuszczona kolejna piłka.
Throttlingu warto używać, jeśli na swojej stronie wprowadzamy interakcje związane ze scrollowaniem, ruchem myszy, zmianą rozmiaru okna lub viewportu. Wówczas możemy ograniczyć wykonanie się kodu np. raz na 16 milisekund (co równa się 60 klatkom na sekundę - powszechnie akceptowana wartość, zapewniająca płynność animacji i interakcji).
Funkcja throttle jest również dostępna w bibliotece lodash, podobnie jak debounce:
// console.log wykona się WYŁĄCZNIE raz na 100 ms,
// niezależnie od tego, jak długo użytkownik scrolluje
const throttledScroll = throttle(
() => {
console.log('Scroll position:', window.scrollY);
},
100
);
window.addEventListener('scroll', throttledScroll);Te techniki to podstawa optymalizacji wydajności - pomagają uniknąć niepotrzebnych wywołań funkcji i poprawiają reakcje strony na działania użytkownika.
3. Cumulative Layout Shift - żeby stronka nie skakała i nóżki nie złamała
CLS mierzy, jak bardzo elementy strony przesuwają się po ekranie podczas ładowania. Na pewno zdarzyło Ci się spróbować kliknąć jakiś przycisk na stronie - na przykład krzyżyk przy wnerwiającej reklamie - tylko po to, żeby na ułamek sekundy przed kliknięciem, cała reklama przesunęła się o kilka pikseli w dół? To właśnie przez złe CLS.
Jak oceniać:
Świetnie: poniżej 0,1 😎
Średnio: między 0,1 a 0,25 🤨
Tragedia: powyżej 0,25 😫
Stabilne ładowanie obrazków
Aby zapobiegać "skakaniu" elementów na stronie, nasze obrazki powinny zawsze mieć jasno zdefiniowane wymiary w kodzie HTML, jeszcze zanim zaczną się wczytywać. Popularne CMS dostarczają informacje o wymiarach dla frontendu, razem z jego adresem URL.
Źle:
<!-- obrazek wstępnie zajmie zero pikseli szerokości,
spowoduje "przeskok" po załadowaniu -->
<img src="image.jpg" alt="Opis" />Dobrze:
<!-- jasno zdefiniowane wymiary i opcjonalnie współczynnik proporcji -->
<img src="image.jpg"
width="400"
height="300"
style="aspect-ratio: 4/3;"
alt="Opis obrazu" />Stabilne ładowanie fontów
Tutaj działamy zupełnie tak, jak przy optymalizacji LCP w punkcie 1. powyżej.
Narzędzia do testowania Core Web Vitals
Google PageSpeed Insights
To jest Twój główny przyjaciel, jeśli chodzi o mierzenie CWV - mierzy i pokazuje dane rzeczywiste (na podstawie doświadczeń prawdziwych użytkowników) oraz laboratoryjne (z testów własnych). Najlepszy do ogólnej oceny sprawności naszej strony.
Google Lighthouse
Najszybszy w codziennym użyciu, bo wbudowany w Chrome DevTools. Super do debugowania podczas kodowania strony. Pokazuje tylko surowe dane laboratoryjne, ale za to można testować na żywo.
Google Search Console
Mierzy i pokazuje dane z ostatnich 28 dni od prawdziwych użytkowników. Dane z tego narzędza są najistotniejsze, gdy dopracowujemy nasze SEO, bo to właśnie te dane Google bierze pod uwagę w swoim rankingu stron.
Dlaczego wyniki różnią się między narzędziami?
To normalne, że różne narzędzia pokazują różne wyiki. Dzieje się tak przez:
Różne serwery testowe, położone w różnych miejscach na Ziemi - jeden w Ameryce, drugi w Europie, trzeci gdzieś w Azji.
Różną moc urządzeń testowych - narzędzia mogą testować na prawdziwych komputerach i telefonach, albo symulowanych i wirtualnych.
Różne wersje Chrome i Lighthouse.
Jako użytkownicy i klienci tych platform możemy natomiast bezpiecznie założyć, że ich dostawca robi wszystko, aby nasze wyniki były miarodajne i jak najbliższe rzeczywistości. Rezultaty testów między narzędziami mogą się różnić, ale nie będą to raczej nigdy dramatyczne różnice.
Wpływ Core Web Vitals na biznes - konkretne liczby
Wpływ na konwersje
Badania nie kłamią - Core Web Vitals mają całkowicie realny wpływ na wyniki naszych produktów i stron internetowych:
Strony ładujące się szybciej mają 60% więcej odsłoni i 35% niższy bounce rate - metryka sprawdzająca, jaki procent użytkowników wychodzi ze strony przed dokładnym zapoznaniem się z ofertą.
53% użytkowników ucieka ze strony, jeśli ładuje się dłużej, niż 3 sekundy.
Przykład sukcesu - liczby mówią same za siebie
Firma SiteCare przeprowadziła kompleksowy projekt optymalizacji Core Web Vitals dla witryny WordPress jednego ze swoich klientów - fundacji non-profit działającej na rzecz wczesnej edukacji dzieci, której priorytetem były kluczowe wskaźniki użytkowe i finansowe. Poniżej szczegóły działań oraz mierzalne efekty.
Stan wyjściowy oraz diagnoza problemów
Przed rozpoczęciem prac (luty-marzec 2023), wskaźniki Core Web Vitals wyglądały następująco:
LCP - 4,6s (o 2,1s powyżej progu "Świetnie"),
FID - 420ms (o 320ms powyżej progu)
CLS - 0,08 (w granicach normy)
INP - 230 ms (przekroczony próg)
Dodatkowe metryki wydajności:
TBT (Total Blocking Time, całkowity czas blokowania renderowania strony): 7,3 s
Rozmiar strony: 5,33 MB (w tym 3 MB samego kodu JS)
Fully Loaded Time: 28,9 s
Plan optymalizacji
Zespół SiteCare wdrożył zestaw działań technicznych:
Usunięto kod JS blokujący renderowanie (zamiana wtyczek, porządkowanie Google Tag Manager),
Zoptymalizowano DNS i wczesne zaczytywanie oraz kolejność wtyczywania zasobów,
Wprowadzono minifikację i bundlowanie kodu CSS i JS,
Wdrożono lokalne hostowanie fontów wraz z fallbackami,
Użyto obrazów w formacie WebP i zoptymalizowano je przez Cloudflare Polish & Mirage,
Usunięto zbędne skrypty firm trzecich,
Wykonano migrację na lżejsze wersje wtyczek (HelloBar, ConvertPro zamiast SUMO).
Wyniki Core Web Vitals po optymalizacji
Po wdrożeniu optymalizacji w okresie od czerwca do października 2023, zmierzono i zaraportowano nowe wyniki Core Web Vitals:
LCP: 2,3 ms ✅
FID: 57 ms ✅
INP: 133 ms ✅
CLS: 0 ‼️ ✅
Total Blocking Time: 0,3 s (spadek o 7 s‼️)
Fully Loaded Time: 3,4 s (poprawa o 1000%!)
Rozmiar strony: 602 KB (poprawa o 800%!)
Google Search Console od 8 września automatycznie walidowało wszystkie URL-e strony klienta jako "Good", zarówno na komputerach, jak i urządzeniach mobilnych.
Wzrosty ruchu i zaangażowania
Porównanie wyników sześć miesięcy przed i sześć miesięcy po optymalizacji CWV:
Użytkownicy (sesje):
Luty-czerwiec 2023: 645 tys.
Czerwiec-październik 2023: 820 tys. (+27,1%)
Wyświetlenia w wyszukiwarkach:
Luty-czerwiec 2023: 28,2 mln
Czerwiec-październik 2023: 36,6 mln (+29,8%)
Kliknięcia w wyszukiwarkach:
Luty-czerwiec 2023: 513 tys.
Czerwiec-październik 2023: 628 tys. (+22,4%)
Efekt w konwersji biznesowej
Odbudowana wydajność strony przełożyła się bezpośrednio na wzrost ruchu i darowizn. Dzięki zwiększonemu ruchowi i lepszym wskaźnikom CWV, partnerzy fundacji odnotowali wzorst liczby i wartości darowizn, dotrzymując progrnoz finansowych, a klient potwierdził, że dzięki pracy SiteCare jego komunikacja z darczyńcami odzyskała skuteczność.
Rezultatem kompleksowej optymalizacji było przywrócenie strony do pozycji lidera w wynikach wyszukiwania, a wzrost statystyk ruchu osiągnął aż 25%.
Mobile vs Desktop - różne podejścia
Na co zwrócić uwagę przy urządzeniach mobilnych?
Przy optymalizowaniu pod urządzenia mobilne należy pamiętać o pewnych szczegółach:
Google traktuje mobile i desktop jako osobne byty
Telefony mają typowo mniej mocy niż komputery (procesor, pamięć, internet)
Elementy UI obsługujące dotyk są kluczowe
CLS na mobile jest często gorsze o ok. 10 punktów procentowych, niż na desktopach
Optymalizacja desktopowa:
Większe ekrany i rozdzielczości mogą wymagać stosowania większych obrazów (i cięższych = większy wpływ na LCP)...
...ale jednocześnie, zapewniać więcej zasobów systemowych i po prostu szybszy sprzęt
Różne zachowania użytkowników, chcących wykonywać wiele zadań jednocześnie, co nie zawsze jest możliwe na telefonach
Większa stabilność połączenia internetowego
Najczęstsze błędy przy optymalizacji
1. Branie pod uwagę tylko wyników z Lighthouse'a
Wiele zespołów skupia się tylko na wynikach Lighthouse, ignorując rzeczywiste doświadczenia użytkowników. Bardziej odpowiednie wyniki możemy wyczytać możemy w Search Console.
2. Optymalizacja wyłącznie pod desktop
Google używa podejścia mobile-first do oceny tego, jak ocenić i indeksować daną stronę w Internecie, więc priorytetem musi być wersja mobilna.
3. Brak rezerwacji miejsca dla dynamicznych elementów
Tutaj pomoże wspomniana już technika nadawania obrazkom konkretnych wartości szerokości i wysokości z góry, zamiast polegać na załadowaniu.
To samo możemy robić z blokami tekstu - jeśli wiemy, ile mniej-więcej miejsca zajmą, w czasie wczytywania możemy skorzystać z tzw. skeletonów, które stanowią (często animowany) placeholder, który częściowo może zapobiegać przesuwaniu się zawartości i wpływaniu na LCP, a także dać znać użytkownikowi, czego może się spodziewać w konkretnym miejscu na stronie. Możliwość optymalizacji wydajności i wyników CWV, a jednocześnie ulepszenie doświadczenia użytkownika - to coś, z czego grzech nie skorzystać.
4. Nieodpowiednie użycie lazy loadingu
Techniki lazy loadingu powinniśmy używać wyłącznie wobec treści below the fold - czyli tej, którą użytkownik zobaczy dopiero po umyślnym zescrollowaniu w dół. Stosowanie jej wobec treści widocznych above the fold, czyli pierwszej części strony, którą zobaczy zaraz po załadowaniu, może niepotrzebnie opóźnić jej wczytanie i wyrenderowanie, w efekcie niegatywnie pływając na metryki CWV.
5. Zbyt wiele skryptów firm trzecich
Jeśli musimy stosować skrypty pochodzące z zewnątrz - upewnijmy się, że ładujemy je za pomocą lazy loadingu i opóźniajmy ich załadowanie zawsze tam, gdzie to tylko możliwe. Dzięki temu unikniemy wpływu ich na renderowanie i pobieranie plików strony.
Lista kontrola optymalizacji Core Web Vitals
Optymalizacja LCP
Optymalizuj największy element (obraz lub tekst) w obrębie viewportu.
Użyj atrybutu
fetchpriority="high"dla najważniejszych obrazków, które mają być widoczne od razu po wstępnym załadowaniu strony.Zaimplementuj preloading dla kluczowych zasobów.
Optymalizuj serwer (TTFB poniżej 600 ms).
Używaj CDN dla statycznych zasobów (obrazki, skrypty, pliki HTML).
Zminifikuj CSS i JS.
Usuwaj nieużywany kod.
INP
Dziel długie zadania JS i oddelegowuj te najbardziej złożone do zadań asynchronicznych.
Używaj debounce/throttling.
Korzystaj z dzielenia kodu i lazy loadingu zasobów, które nie są potrzebne natychmiastowo.
Przenoś ciężkie działania i obliczenia do Web Workerów.
Ogranicz JavaScript, który jest ładowany od razu razem ze stroną.
Optymalizuj nasłuchiwanie na eventy w kodzie.
CLS
Pamiętaj o ustawianiu wymiarów obrazków i elementów video z góry, nie polegaj na dynamicznym dopasowywaniu.
Zarezerwuj konkretne miejsca z odgórnie wydzieloną przestrzenią dla reklam.
Używaj
font-display: swap.Nie wstrzykuj treści nad istniejącymi elementami.
Testuj animacje CSS.
Korzystaj ze skeletonów do rezerwowania przestrzeni na tekst i inne elementy.
Monitorowanie
Skonfiguruj Google Search Console i korzystaj z niego do testowania Core Web Vitals na produkcji.
Regularnie testuj PageSpeed Insights.
Wdróż Real User Monitoring.
Testuj na prawdziwych urządzeniach, a nie tylko w symulowanych trybach w przeglądarce w komputerze.
Podsumowanie
Core Web Vitals w 2025 roku to nie żadna fanaberia. To absolutna podstawa udanych działań w Internecie. Zastąpienie FID przez INP oznacza, że teraz Google bierze pod uwagę cały czas trwania wizyty użytkownika na stronie, a nie tylko początkowe kilkadziesiąt sekund podczas pierwszego ładowania i renderowania.
Klucz do sukcesu? Optymalizuj wszystkie trzy najważniejsze metryki, pamiętaj o różnicach między mobile i desktop, a także monitoruj na bieżąco i unikaj typowych błędów.
Firmy, które serio podchodzą do CWV, zyskują przewagę nie tylko w Google, ale też w sercach użytkowników i swoich wynikach biznesowych. Szybka strona to zadowoleni użytkownicy, a zadowoleni użytkownicy to więcej kasy wpadającej do kieszeni.