Core Web Vitals – jak poprawić wydajność strony?

Siedzisz przed komputerem po 21:00.
Odliczasz minuty do pełnej godziny. Start sprzedaży biletów. Ten jeden koncert w Polsce. Okazja, która może się nie powtórzyć.

21:59:58. Odświeżasz stronę.

22:00.  Pojawia się przycisk „Kup”. Klikasz.

W tym samym momencie nad przyciskiem doczytuje się baner. Cały interfejs przesuwa się o kilka pikseli w dół. Kliknąłeś już nie „Kup”, tylko pustą przestrzeń.

Klikasz drugi raz. Nic się nie dzieje. Klikasz mocniej, szybciej. Jakby to miało przyspieszyć serwer.

Strona przez chwilę „myśli”. Brak jakiejkolwiek informacji zwrotnej. Nie wiesz, czy system przyjął kliknięcie, czy je zignorował.

Po kilku sekundach pojawia się komunikat: „Bilety wyprzedane”.

I wtedy pojawia się frustracja.

Internet działa. Komputer jest szybki. Strona przecież „się wczytała”.

Taka sytuacja to nie pech, ale połączenie kilku rzeczy, które zawiodły w zaplanowaniu i zoptymalizowaniu strony. Wszystkie te elementy można nazwać i wymienić:

• opóźnione pojawienie się kluczowej treści,
• przesunięcie interfejsu w trakcie ładowania,
• brak natychmiastowej reakcji na kliknięcie.

Te trzy elementy są kluczowymi wskaźnikami, które zostały zebrane przez Google pośród kilkuset do tych kluczowych i są częścią Core Web Vitals.

Są one po to, aby jak najlepiej dostosować stronę, żeby użytkownik otrzymał natychmiastową, stabilną i przewidywalną reakcję.

I właśnie dlatego Core Web Vitals stało się jednym z podstawowych metryk oceny jakości witryn od strony technicznej.

Co to jest core web vitals? I dlaczego mogą pomóc?

Podstawowe wskaźniki internetowe (Core Web Vitals) - to zestaw danych zebranych przez Google. Pochodzą one z rzeczywistych wizyt użytkowników (Chrome User Experience Report), a nie wyłącznie z testów laboratoryjnych.

To oznacza, że Google analizuje faktyczne zachowanie stron na prawdziwych urządzeniach, w realnych warunkach sieciowych.

Pokazują one doświadczenia użytkowników związane z szybkością wczytywania danych, interaktywnością i stabilnością wizualną strony.

Oceniają trzy kluczowe obszary:

• szybkość pojawienia się głównej treści,
• stabilność wizualną interfejsu,
• czas reakcji na interakcję użytkownika.

W kontekście sytuacji z zakupem biletu oznacza to bardzo konkretne rzeczy.

Gdyby strona była poprawnie zoptymalizowana pod Core Web Vitals:

• interfejs nie przesunąłby się w momencie wczytywania banera (problem stabilności layoutu),
• kliknięcie w przycisk zostałoby przetworzone bez zauważalnego opóźnienia (problem reakcji na interakcję),
• użytkownik otrzymałby natychmiastową informację zwrotną, że system przyjął akcję.

Core Web Vitals nie naprawią same strony, ale wskażą obszary wymagające poprawy tak, aby aby uniknąć sytuacji jak z zakupem biletu. Aby prawidłowo wykorzystać dobre praktyki i wytyczne Google’a, konieczna jest wiedza o tym, jak zaplanować i wdrożyć stronę internetową technicznie.

Jakie wskaźniki są ujmowane w Core Web Vitals?

Core Web Vitals skupia się na trzech obszarach, które bezpośrednio wpływają na doświadczenie użytkownika: szybkości wyświetlania kluczowej treści, stabilności interfejsu oraz reakcji na interakcję.

Każdy z nich można przełożyć na bardzo konkretną sytuację - taką jak próba zakupu biletu o 22:00.

1. LCP – Largest Contentful Paint

LCP mierzy czas, w którym na ekranie pojawia się największy, najważniejszy element widoczny dla użytkownika. Najczęściej jest to sekcja hero, duży obraz lub nagłówek.

Jeśli przycisk „Kup” pojawia się dopiero po kilku sekundach, użytkownik już czuje opóźnienie.

W praktyce podczas audytów najczęściej problemem są:

• nieoptymalne obrazy (2–4 MB bez kompresji),
• blokujący CSS,
• nadmiar fontów,
• skrypty marketingowe ładowane przed treścią.

Dobry wynik LCP to poniżej 2,5 sekundy. Powyżej 4 sekund użytkownik zaczyna tracić cierpliwość, choć może nawet nie zdaje sobie z tego sprawy.

2. CLS - Cumulative Layout Shift

CLS mierzy stabilność wizualną strony. Innymi słowy: czy elementy interfejsu, które są już wyświetlone, pozostaną na swoim miejscu podczas wczytywania cięższych elementów, takich jak zdjęcia czy filmy.

W scenariuszu z koncertem problemem był moment, w którym doczytał się baner i przycisk przesunął się o kilka pikseli.

To właśnie klasyczny przykład wysokiego CLS.

Z technicznego punktu widzenia problem powodują:

• brak zdefiniowanych wymiarów obrazów,
• dynamiczne wstrzykiwanie nowych elementów nad istniejącą zawartością strony
• reklamy lub banery ładowane bez rezerwacji miejsca.

Dobry wynik CLS to poniżej 0,1.  Wartość powyżej 0,25 oznacza realne ryzyko błędnych kliknięć i frustracji. W uproszczeniu: wartość 0,1 oznacza bardzo niewielkie, praktycznie niezauważalne przesunięcia elementów.

Z biznesowego i użytecznego punktu widzenia to nie jest „kosmetyka”. To sytuacja, w której użytkownik klika nie to, co chciał, a strona traci jego zaufanie.

3. INP - Interaction to Next Paint

INP mierzy czas reakcji strony na interakcję użytkownika - od momentu kliknięcia do chwili, gdy zobaczy on efekt swojej akcji.

W historii z biletem to był moment, w którym klikasz „Kup” i nic się nie dzieje. Strona „myśli”, ale nie daje żadnego sygnału. Innym przykładem jest sytuacja, w której strona mobilna wyświetla przycisk otwierania menu, ale pozostaje on nieaktywny do czasu załadowania kolejnych skryptów.

Najczęstsze przyczyny słabego INP w projektach, które analizuję:

• przeciążony główny wątek JavaScript,
• długie zadania JS (tzw. long tasks),
• zbyt wiele zewnętrznych narzędzi (chat, analityka, piksele reklamowe),
• ciężkie filtry i dynamiczne koszyki w e-commerce.

Dobry wynik INP to poniżej 200 ms. Powyżej 500 ms użytkownik zaczyna ponownie klikać przycisk - co często prowadzi do podwójnych akcji lub błędów (choć wiele zależy od tego, jak zaprojektowano obsługę zdarzeń). INP uwzględnia najwolniejszą interakcję podczas całej wizyty użytkownika, a nie tylko pierwsze kliknięcie.

Dlaczego te trzy wskaźniki są razem?

Bo razem opisują pełny moment decyzyjny użytkownika:

• Czy treść pojawiła się szybko? (LCP)
• Czy interfejs był stabilny? (CLS)
• Czy strona zareagowała natychmiast? (INP)

Jeśli którykolwiek z tych elementów zawodzi, użytkownik odczuwa frustrację nawet jeśli „technicznie” strona działa. Dlatego te wskaźniki są traktowane jako kluczowe, ponieważ razem budują wrażenie stabilnej, przewidywalnej i dobrze zaprojektowanej strony. A to bezpośrednio wpływa na zaufanie użytkownika i jego decyzję zakupową.

Monitorowanie Core Web Vitals - dlaczego to nie jest jednorazowy test?

Fajnie byłoby osiągnąć wynik 95/100 w jednym raporcie i uznać sprawę za zakończoną, ale ze względu na złożoność technologii oraz to, jak często się zmieniają, a także ponieważ Core Web Vitals opiera się na danych z rzeczywistych wizyt użytkowników, nie da się zrobić tego raz i uznać tematu za zamknięty.

Wyniki będą zmieniać się w czasie w zależności od aktualnego ruchu, aktualizacji systemu, nowych treści czy dodatkowych skryptów marketingowych.

Oznacza to trzy rzeczy:

• aktualizacja wtyczki może pogorszyć czas reakcji,
• nowa kampania reklamowa może dodać ciężkie skrypty,
• większy ruch może ujawnić problemy serwera, których wcześniej nie było widać.

Dlatego monitorowanie Core Web Vitals, podobnie jak monitorowanie innych obszarów technicznych, powinno być procesem, a nie jednorazowym „sprawdzeniem pod SEO”.

Najczęściej używane narzędzia to:

• Google PageSpeed Insights – szybki test laboratoryjny + dane użytkowników,
• Google Search Console – raport zbiorczy dla realnych użytkowników,
• Lighthouse – analiza techniczna,
• Chrome DevTools – diagnostyka na poziomie deweloperskim.

Dane z Search Console, są najważniejsze bo pokazują realne problemy użytkowników, a nie tylko symulację testową.

Jak wygląda sensowne monitorowanie w praktyce?

• Regularny przegląd raportu Core Web Vitals w Search Console.
• Analiza zmian po wdrożeniach lub aktualizacjach.
• Testy laboratoryjne przy większych zmianach technicznych.
• Porównanie wyników z konwersją i współczynnikiem odrzuceń.

Jak prowadzę audyt Core Web Vitals?

Audyt Core Web Vitals nie zaczyna się od patrzenia na kolor w raporcie. Zaczyna się od zrozumienia, co realnie widzi i odczuwa użytkownik.

Proces zazwyczaj wygląda tak:

1. Analiza danych rzeczywistych

Na początku sprawdzam raport w Google Search Console, ponieważ pokazuje on dane z realnych wizyt użytkowników.

To pozwala odpowiedzieć na pytania:

• czy problem dotyczy całej strony, czy tylko wybranych podstron,
• czy dotyczy głównie urządzeń mobilnych,
• czy pogorszenie wyników pojawiło się po konkretnej zmianie.

Bez tego łatwo pracować nad czymś, co nie jest faktycznym problemem.

2. Test laboratoryjny i identyfikacja przyczyny

Następnie wykonuję test w Google PageSpeed Insights oraz w Lighthouse.

Celem jest zidentyfikowanie problemów, takich jak:

• zasoby blokujące renderowanie,
• wysoki TTFB (problem po stronie serwera),
• przeciążenie głównego wątku przez JavaScript,
• elementy powodujące przesunięcia layoutu.

3. Priorytetyzacja pod kątem biznesowym

Na podstawie tych informacji można działać dalej. Pamiętaj, że nie każdy błąd czy słabszy wynik wymaga natychmiastowej poprawy.

Jeśli problem dotyczy podstrony z małym ruchem, a nie strony koszyka czy formularza kontaktowego, priorytety będą inne.

Najpierw poprawiam to, co wpływa na:

• proces zakupowy,
• kluczowe podstrony ofertowe,
• moment decyzji użytkownika.

Core Web Vitals to narzędzie. Celem jest konwersja.

4. Wdrożenie i ponowny pomiar

Po wdrożeniu zmian wykonuję ponowny test, a następnie monitoruję dane rzeczywiste przez kolejne tygodnie.

Ponieważ Core Web Vitals opiera się na danych z wizyt użytkowników, efekt zmian nie zawsze jest widoczny od razu. Potrzebny jest czas i realny ruch.

Audyt Core Web Vitals to nie jednorazowa poprawka. To uporządkowanie sposobu, w jaki strona ładuje się, reaguje i zachowuje w kluczowym momencie decyzji użytkownika.

Pamiętaj, że nie liczą się wyłącznie liczby. Gonienie za „setkami” w każdym raporcie nie ma większego sensu. Optymalizacja to nie tylko wynik to także sposób, w jaki użytkownik postrzega szybkość działania strony i proces jej wczytywania, o czym pisałem szerzej w osobnym artykule odnośnie optymalizacji pod kątem psychologicznym.

Podsumowanie.

Wracając do sytuacji z koncertem. Użytkownik nie analizuje raportu. Nie zastanawia się, czy LCP wynosiło 2,4 czy 3,1 sekundy, pewnie nie wie, czym ono jest podobnie jak CLS ani INP.

Chce stabilny responsywny interfejs który pomoże mu kupić bilet a nie w tym przeszkodzi. Core Web Vitals nie jest więc zestawem technicznych wskaźników dla deweloperów. To miernik tego, czy Twoja strona wspiera decyzję użytkownika, czy ją sabotuje.

Jeśli treść ładuje się z opóźnieniem, interfejs się przesuwa, a kliknięcie nie daje natychmiastowej reakcji użytkownik odczuwa frustrację. Nawet jeśli „technicznie” wszystko działa.

Dlatego:

• optymalizacja nie polega na gonieniu za wynikiem 100/100,
• wydajność nie jest jednorazowym projektem,
• a Core Web Vitals to nie moda SEO, tylko standard projektowania nowoczesnych stron.

W praktyce różnica między stroną „ładną” a stroną „skuteczną” często sprowadza się do milisekund. A milisekundy w e-commerce potrafią kosztować bardzo realne pieniądze.

Jeśli więc Twoja strona ma sprzedawać, zbierać leady lub budować markę, wydajność nie jest dodatkiem. Jest fundamentem.

Skontaktuj się ze mną, a sprawdzimy, co realnie spowalnia Twoją stronę i jak można to poprawić.

O autorze.

Od lat związany z szeroko rozumianą informatyką. Pierwszą stronę stworzyłem w liceum, za co otrzymałem wyróżnienie.

Ciągle uczę się, aby dorównać tempu rozwoju nowoczesnych technologii łącząc je z wiedzą o psychologii aby zwiększać skuteczność stron i aplikacji internetowych.