Czego dokładnie dotyczy zapowiedziana zmiana

Warto rozdzielić dwa pojęcia, bo w rozmowach ciągle się zlewają.

Core Web Vitals to trzy konkretne wskaźniki mierzące szybkość wyświetlenia treści, reakcję na pierwsze działanie użytkownika oraz stabilność układu strony podczas ładowania. Są mierzalne, mają progi i są zbierane z realnych przeglądarek użytkowników Chrome.

Page Experience Update to szerszy zestaw sygnałów, w którym Core Web Vitals są tylko jedną częścią. Do tego dochodzą rzeczy, które w rankingu funkcjonują już od dawna: obsługa na urządzeniach mobilnych, połączenie po HTTPS, brak natrętnych reklam pełnoekranowych zasłaniających treść oraz bezpieczne przeglądanie. Nowością nie jest więc cały pakiet, a domknięcie go trzema mierzalnymi liczbami.

Google od początku komunikuje jedną rzecz wyraźnie: trafność treści pozostaje ważniejsza. Strona, która najlepiej odpowiada na zapytanie, nie wypadnie z pierwszej dziesiątki dlatego, że ładuje się wolniej od konkurenta. Sygnał zadziała raczej jako rozstrzygnięcie między stronami o podobnej jakości merytorycznej.

Skąd wziąć dane o własnej stronie

Zaczynam od Search Console, a nie od narzędzi punktowych. Raport dotyczący najważniejszych wskaźników internetowych pokazuje adresy pogrupowane na dobre, wymagające poprawy i słabe, osobno dla urządzeń mobilnych i komputerów.

Kluczowa różnica, którą trzeba zrozumieć na samym początku: ten raport pokazuje dane z pola, czyli zebrane od prawdziwych użytkowników w ciągu ostatnich dwudziestu ośmiu dni. Narzędzia typu Lighthouse pokazują dane z laboratorium, czyli pojedynczy pomiar na symulowanym urządzeniu i symulowanym łączu. Jedno i drugie jest przydatne, ale do innych rzeczy.

Do rankingu liczą się dane z pola. Do diagnozy, dlaczego jest źle, wygodniejsze są dane laboratoryjne, bo pokazują konkretną listę problemów i ich szacowany wpływ. Wnioski o postępie wyciągam wyłącznie z pola — i to z opóźnieniem, bo średnia z dwudziestu ośmiu dni potrzebuje czasu, żeby odzwierciedlić poprawki wdrożone w zeszłym tygodniu.

Jeszcze jedna praktyczna uwaga: dane z pola pojawiają się tylko dla adresów o wystarczającym ruchu. Mniejsze serwisy zobaczą w Search Console grupy adresów albo nic. Wtedy zostaje ocena laboratoryjna i zdrowy rozsądek.

Od czego zaczynam poprawki

Nie od listy zaleceń z narzędzia, bo ona jest posortowana według technicznej wagi, a nie według biznesowej wartości podstron.

Najpierw wybieram szablony, nie adresy. Serwis ma zwykle pięć, może osiem układów: strona główna, listing, karta produktu lub wpis blogowy, koszyk, formularz kontaktowy. Poprawka w szablonie karty produktu naprawia kilkaset adresów naraz. Ustawiam kolejność według tego, ile ruchu wchodzi na dany szablon z wyszukiwarki i ile na nim zależy sprzedażowo.

Potem sprawdzam, co jest wspólne dla wszystkich szablonów, bo tam zwykle siedzi największa strata. Najczęściej to trzy rzeczy: obrazy w oryginalnych rozmiarach, kod skryptów zewnętrznych ładowany w nagłówku i motyw ładujący arkusze stylów dla całego serwisu na każdej podstronie.

Dopiero na końcu zajmuję się pojedynczymi adresami, które odstają od reszty. Zwykle jest ich mniej, niż sugeruje pierwszy raport.

Typowe przyczyny słabych wyników

Z serwisów, które oglądam, wraca kilka tych samych powodów.

• Grafiki — wgrane w rozdzielczości aparatu i skalowane w przeglądarce, bez nowoczesnych formatów, bez podanych wymiarów w kodzie. Odpowiadają zwykle i za wolne wyświetlenie treści, i za przeskakiwanie układu.

• Skrypty firm trzecich — czaty, systemy zgód, mapy ciepła, kilka narzędzi analitycznych naraz. Każde z nich jest małe, wszystkie razem blokują wątek przeglądarki na sekundy.

• Kroje pisma z zewnętrznych serwerów — ładowane bez wskazania zastępczego kroju, więc tekst pojawia się z opóźnieniem albo przeskakuje po podmianie.

• Reklamy i banery wstawiane po załadowaniu — wchodzą w gotowy układ i przesuwają treść w dół. To najczęstsza przyczyna złej stabilności układu.

• Hosting i brak pamięci podręcznej — jeśli serwer odpowiada z opóźnieniem, żadna optymalizacja kodu tego nie nadgoni.

Czego bym nie robił

Przede wszystkim nie zaczynałbym od przebudowy serwisu. Zapowiedź dotyczy sygnału pomocniczego, nie wywrócenia rankingu, a migracja na nowy motyw albo nową technologię niesie ryzyka o rząd wielkości większe niż kilkaset milisekund różnicy w ładowaniu.

Nie gonię też wyniku sto na sto w narzędziach laboratoryjnych. Powyżej pewnego poziomu kolejne punkty kupuje się kosztem funkcji, których strona faktycznie potrzebuje. Progi Core Web Vitals są konkretne i osiągalne bez fanatyzmu — celuję w nie, a nie w idealną ocenę.

I nie wprowadzam pięciu zmian w jednym wdrożeniu. Skoro dane z pola mają miesięczne okno, to przy pięciu zmianach naraz nie dowiem się, która pomogła. Wolę wdrażać pojedynczo i notować daty.

Co zrobić w najbliższych tygodniach

Realistyczny plan na czas do wdrożenia wygląda u mnie tak.

Sprawdzam raport w Search Console i zapisuję stan wyjściowy — bez tego za dwa miesiące nie będzie punktu odniesienia. Wybieram dwa szablony o największym ruchu z wyszukiwarki i dla nich robię listę problemów. Naprawiam obrazy i porządkuję skrypty zewnętrzne, bo to najczęściej największy zysk przy najmniejszym ryzyku. Rezerwuję sobie sensowną liczbę godzin programisty, zamiast liczyć, że wtyczka do przyspieszania zrobi wszystko sama.

Na koniec rzecz, którą powtarzam klientom: te prace opłacają się niezależnie od tego, jak mocno zadziała sam sygnał rankingowy. Szybsza strona lepiej konwertuje i taniej wychodzi w kampaniach płatnych, bo za ten sam koszt kliknięcia dostaję użytkownika, który faktycznie doczekał się treści. Aktualizacja jest tylko dobrym pretekstem, żeby wreszcie się tym zająć.