Sklep może mieć świetny wynik w pojedynczym teście, a mimo to irytować klientów. Może też wypaść słabiej w laboratorium, choć większość realnych wizyt działa przyzwoicie. Core Web Vitals pomagają uporządkować tę rozmowę, ale trzeba wiedzieć, co dokładnie mierzą.
W dużym skrócie chodzi o trzy rzeczy: kiedy pojawia się główna treść, jak szybko strona odpowiada na działanie klienta i czy elementy nie uciekają spod palca. W e-commerce problemy najlepiej widać na listingu, karcie produktu, w koszyku i checkoutcie — nie tylko na stronie głównej.
Trzy podstawowe wskaźniki
LCP — Largest Contentful Paint
Mierzy czas wyświetlenia największego istotnego elementu w widoku, najczęściej zdjęcia produktu, banera lub głównego nagłówka. Na LCP wpływają serwer, cache, kolejność ładowania zasobów, rozmiar obrazu i kod blokujący renderowanie.
INP — Interaction to Next Paint
Mierzy responsywność interakcji w całej wizycie: kliknięć, dotknięć i obsługi klawiatury. Długi INP oznacza, że przeglądarka jest zajęta i zbyt późno pokazuje rezultat działania użytkownika.
CLS — Cumulative Layout Shift
Mierzy niespodziewane przesunięcia układu. Typowy problem to przycisk, który ucieka po doładowaniu zdjęcia, bannera zgód, czcionki albo modułu rekomendacji.
Każdy wskaźnik opisuje inny problem. Zmniejszenie zdjęć może poprawić LCP, ale nie naprawi filtra, który blokuje główny wątek na pół sekundy. Z kolei szybki JavaScript nie pomoże, jeśli banner po załadowaniu spycha przycisk „Dodaj do koszyka”.
Jak czytać progi?
Według aktualnych materiałów web.dev dobry wynik to LCP do 2,5 s, INP do 200 ms oraz CLS do 0,1. Ocena opiera się na 75. percentylu wizyt, osobno dla urządzeń mobilnych i desktopowych.
Próg nie jest celem samym w sobie. Sklep powinien przede wszystkim szybko i stabilnie obsługiwać najważniejsze ścieżki: listing, wyszukiwarkę, kartę produktu, koszyk i checkout.
75. percentyl oznacza, że patrzymy nie na idealną wizytę, lecz na doświadczenie większości użytkowników. Wynik LCP 2,4 s nie oznacza, że każda osoba zobaczy stronę po 2,4 s. Część zobaczy ją szybciej, a część — szczególnie na słabszym telefonie i sieci — znacznie później.
Dane rzeczywiste i laboratoryjne
PageSpeed Insights łączy dwa różne rodzaje informacji. Dane terenowe (field data) pochodzą z rzeczywistych wizyt użytkowników w Chrome i obejmują kroczące okno ostatnich 28 dni. Dane laboratoryjne uruchamiają kontrolowany test i pomagają wskazać przyczynę problemu.
Dlatego wynik po wdrożeniu może poprawić się w teście od razu, a w danych rzeczywistych dopiero stopniowo. Ocena 0–100 z Lighthouse nie jest tym samym co zaliczenie Core Web Vitals i nie powinna być jedynym KPI.
W audycie zaczynam od danych terenowych i rozbijam je na typy stron. Średnia domeny może wyglądać dobrze, choć karta produktu z największym ruchem ma problem. Dopiero później odtwarzam konkretny przypadek w narzędziach deweloperskich i szukam przyczyny.
Dlaczego mobile i desktop różnią się tak bardzo?
Telefon ma zwykle słabszy procesor, bardziej zmienną sieć i inny sposób interakcji. Dochodzą do tego mobilne bannery, widgety, klawiatura ekranowa oraz większa wrażliwość na długie zadania JavaScript.
Desktop może mieć lepszy LCP dzięki szybszemu łączu, ale nadal cierpieć na niestabilny układ lub opóźnione filtry. Nie przenoś wniosków między urządzeniami bez danych.
Co najczęściej spowalnia Magento 2?
Nie ma jednej magicznej konfiguracji. W projektach Magento 2 regularnie wracają jednak te same klasy problemów: wolna odpowiedź backendu, nieoptymalne obrazy, ciężki frontend, rozbudowane rozszerzenia oraz skrypty marketingowe uruchamiane bez kontroli.
- Backend: wolne zapytania, nietrafiona konfiguracja cache, przeciążone indeksy lub zewnętrzne API czekające w ścieżce żądania.
- Frontend: za dużo JavaScriptu, długie zadania i komponenty inicjalizowane, zanim są potrzebne.
- Media: obraz desktopowy wysyłany na telefon albo brak priorytetu dla obrazu LCP.
- Rozszerzenia: moduły dodające zasoby na każdej stronie, choć używa ich tylko jeden widok.
- Marketing: kolejne tagi, czaty i personalizacja dodawane bez budżetu wydajności.
Hyvä zwykle mocno upraszcza warstwę frontendową Magento 2, ale nie jest przyciskiem „napraw wszystko”. Wolne API, źle przygotowane obrazy i nadmiar skryptów zewnętrznych nadal zostaną z Tobą. Dlatego migrację frontendu łączę z pomiarem całej ścieżki, a nie tylko strony głównej.
Jak ustalać priorytety optymalizacji?
- Sprawdź dane rzeczywistych użytkowników dla całej domeny i typów podstron.
- Wybierz szablon o największym wpływie biznesowym, nie najłatwiejszy do poprawy.
- Odtwórz problem w laboratorium i profilu wydajności.
- Usuń przyczynę, zamiast maskować objaw kolejną warstwą cache.
- Wdróż monitoring regresji po aktualizacjach, kampaniach i zmianach tagów marketingowych.
Najpierw naprawiam problem, który dotyka największej liczby klientów i ma realny wpływ na sprzedaż. Czasem będzie to obraz LCP na karcie produktu, a czasem blokujący skrypt w checkoutcie. Poprawa łatwego wyniku na mało ważnej podstronie może ładnie wyglądać w raporcie, ale nie zmieni doświadczenia kupujących.
Jak utrzymać dobry wynik?
Wydajność nie jest zadaniem z jednorazowym statusem „zrobione”. Nowy slider, narzędzie do rekomendacji albo kampania z kilkoma tagami potrafią cofnąć efekt optymalizacji w jeden dzień. Dlatego warto ustalić budżety dla kluczowych szablonów i sprawdzać je przed wdrożeniem.
Po stronie produkcyjnej przydaje się monitoring realnych użytkowników oraz regularny przegląd skryptów zewnętrznych. Każde narzędzie powinno mieć właściciela biznesowego. Jeśli nikt nie wie, do czego służy tag uruchamiany na wszystkich stronach, to dobry kandydat do usunięcia.
Najlepszy wynik daje połączenie szybkiego frontendu, rozsądnej liczby modułów, dobrze skonfigurowanej infrastruktury i dyscypliny po starcie. Core Web Vitals są wtedy nie końcem pracy, ale prostym językiem do rozmowy między biznesem, marketingiem i developmentem.
