Większość użytkowników nie wychodzi z wolnej strony dlatego, że „nie lubi marki”. Wychodzi, bo czekanie oznacza tarcie, a tarcie na pierwszym ekranie zabija konwersję. Core Web Vitals to próba Google, żeby zmierzyć to tarcie w sposób, o którym można rozmawiać i z programistą, i z właścicielem serwisu.
Trzy metryki, po ludzku
LCP, Largest Contentful Paint
Jak długo trwa, zanim pojawi się główna treść strony, zdjęcie hero, nagłówek, pierwsze zdjęcie produktu. Dobry LCP sprawia wrażenie szybkiej strony; zły, że strona ciągle „myśli”.
INP, Interaction to Next Paint
Jak strona reaguje, gdy próbujesz coś zrobić, klik w przycisk, rozwinięcie menu, filtr. Zły INP to wrażenie, że strona Cię nie słucha przez moment.
CLS, Cumulative Layout Shift
Ile treści skacze w trakcie ładowania. Zły CLS to wyciąganie ręki w stronę przycisku i patrzenie, jak ten przycisk ucieka, zwykle przez reklamę, obrazek lub baner, które doładowały się z opóźnieniem.
Dlaczego te metryki dotyczą biznesu, a nie tylko SEO
- Wolny pierwszy ekran, ludzie zamykają kartę, zanim zobaczą treść.
- Niereagująca interakcja, formularze, filtry i koszyki wyglądają jak zepsute.
- Skoki layoutu, kliki w nie to miejsce, zwroty, zgłoszenia do obsługi.
- Google używa tych metryk jako sygnału w rankingu, więc słaba wydajność zmniejsza też widoczność w wyszukiwarce.
Wpływ się kumuluje: drobne problemy sumują się w skali sesji, i drobne poprawki również.
Co zwykle daje największą różnicę
- Obrazy. Właściwe wymiary, nowoczesne formaty (WebP/AVIF), lazy-loading poniżej pierwszego ekranu, jawne wymiary, żeby przeglądarka nie musiała zgadywać.
- Fonty. Tylko te, których naprawdę używacie; najlepiej hostowane lokalnie, z preloadem dla fontu z hero.
- Skrypty zewnętrzne. Analityka, czaty, testy A/B, tag managery, często największe źródło słabego INP. Ładujcie z opóźnieniem i tylko tam, gdzie są potrzebne.
- Nieużywany JavaScript. Mniej kodu = mniej parsowania i mniej pracy na słabszych urządzeniach.
- Czas odpowiedzi serwera. Wolny backend podnosi „podłogę” wszystkim innym. Cache, optymalizacja zapytań i sensowny hosting mają znaczenie.
- Rezerwowana przestrzeń. Jawne wymiary lub aspect-ratio dla obrazów, reklam, iframe'ów i banerów, żeby układ nie skakał.
Najczęstsze błędy
- Pomiar tylko na swoim szybkim laptopie. Użytkownicy są na sieci mobilnej i średnich urządzeniach. Potrzebujecie też danych z realnych wizyt.
- Gonienie jednego wyniku. Idealny Lighthouse z jednego uruchomienia to mało; stałe metryki z pola przez wiele tygodni, dużo.
- Dodawanie narzędzi, żeby naprawić wydajność. Więcej skryptów rzadko przyspiesza stronę.
- Jednorazowa optymalizacja. Bez monitoringu wydajność degraduje się za każdym razem, gdy ktoś dokłada nowy widget.
Sensowna kolejność
- Zmierzcie realne LCP, INP i CLS na 5 najważniejszych stronach.
- Najpierw obrazek hero i główny nagłówek, wpływają na LCP nieproporcjonalnie mocno.
- Audyt skryptów zewnętrznych, wywalcie lub opóźnijcie to, co nie jest niezbędne.
- Rezerwujcie miejsce dla obrazów, reklam i elementów ładowanych później.
- Monitorujcie stale i traktujcie regresje jak błędy.
