Szybkie strony internetowe - Core Web Vitals i wydajność

Szybkość strony przestała być kwestią wrażenia, odkąd Google opublikowało progi. Największe wyrenderowanie treści (LCP), czyli moment, w którym pojawia się główny element widoku, ma nastąpić w ciągu 2,5 sekundy. Reakcja na interakcję do następnego renderowania (INP), czyli opóźnienie między kliknięciem a odpowiedzią strony, ma zmieścić się w 200 milisekundach. Skumulowane przesunięcie układu (CLS), czyli skakanie treści podczas wczytywania, ma pozostać na poziomie 0,1 lub niżej. Jeżeli oferta mówi o szybkiej stronie, ale nie podaje żadnej z tych trzech liczb, mówi o wrażeniu, a nie o pomiarze.

To jest szczegół, który zmienia sposób czytania raportów. Google ocenia te metryki na 75. percentylu wizyt, osobno dla telefonu i komputera. Oznacza to, że liczy się doświadczenie trzech czwartych użytkowników, a nie średnia, którą jeden szybki komputer na światłowodzie potrafi wyciągnąć w górę. Dlatego strona, która na Twoim laptopie otwiera się natychmiast, może mieć słabe wyniki: mierzone są też telefony na słabszym zasięgu. Praktyczny wniosek jest taki, że testy trzeba prowadzić na profilu mobilnym i na wolniejszym łączu, bo dopiero tam widać to, co widzi rynek.

Zestaw Core Web Vitals zmienił się i jest to najprostszy sposób na sprawdzenie, ile lat ma szablon raportu, który dostałeś. Metryka INP zastąpiła wcześniejsze opóźnienie pierwszej interakcji (FID) i to ona jest dziś stabilną metryką Core Web Vitals. FID mierzył wyłącznie opóźnienie pierwszego kliknięcia, więc prawie zawsze wychodził dobrze i prawie nic nie mówił. INP patrzy na wszystkie interakcje w trakcie wizyty, więc wyłapuje strony, które ładują się szybko, a potem reagują z opóźnieniem, bo w tle pracuje kilkanaście skryptów. Jeżeli w raporcie z audytu wciąż figuruje FID, wiesz, że nikt go nie aktualizował od kilku lat.

Nie i warto to powiedzieć wprost, bo na tym oczekiwaniu opiera się sporo sprzedaży. Google potwierdza, że Core Web Vitals są używane przez jego systemy rankingowe, ale zastrzega dwie rzeczy. Po pierwsze, nie ma jednego sygnału odpowiadającego za wrażenia ze strony, tylko wiele sygnałów ocenianych razem. Po drugie, i to jest zdanie decydujące o kolejności prac, wyszukiwarka i tak dąży do pokazania treści najbardziej trafnej, nawet jeśli wrażenia ze strony są słabe. Przyspieszenie strony, która nie odpowiada na pytanie użytkownika, nie da pozycji. Poprawa trafnej treści działa nawet na wolniejszej stronie. Dlatego wydajnością zajmujemy się równolegle z treścią, a nie zamiast niej, a szerszy zakres pracy nad wynikami opisaliśmy na stronie o optymalizacji SEO strony internetowej.

Kolejność jest zaskakująco powtarzalna. Na pierwszym miejscu zdjęcia wgrane prosto z aparatu albo z telefonu, ważące po kilka megabajtów, wyświetlane w miniaturze o szerokości trzystu pikseli. Na drugim wtyczki i skrypty zewnętrzne: czaty, piksele reklamowe, mapy, karuzele, banery zgód, z których każdy dokłada swoje. Na trzecim ciężki motyw uniwersalny, który wczytuje style i skrypty wszystkich funkcji, również tych, których nigdy nie użyjesz. Na czwartym serwer: jeżeli odpowiada po sześciuset milisekundach, połowa budżetu czasu na LCP znika, zanim przeglądarka dostanie pierwszy bajt, i żadna optymalizacja obrazów tego nie odrobi. Na piątym brak rezerwacji miejsca na obrazy i reklamy, przez co treść skacze i psuje CLS.

Uczciwa odpowiedź zależy od tego, na czym strona stoi. Jeżeli serwis ma sensowny fundament, a problemem są obrazy, kilka skryptów i konfiguracja serwera, poprawki są tanie i skuteczne, bo dotykają rzeczy zewnętrznych wobec kodu. Jeżeli natomiast strona stoi na ciężkim motywie uniwersalnym z trzydziestoma wtyczkami, walka o każde sto milisekund kosztuje więcej niż zbudowanie lekkiej strony od podstaw i kończy się połowicznym wynikiem, bo źródłem problemu jest sama konstrukcja. Próg opłacalności jest arytmetyczny: gdy wycena poprawek przekracza połowę ceny nowej strony, a u nas zaczyna się ona od 1 490 zł, dyskusja zwykle się kończy.

Pozycja w Google jest tu skutkiem ubocznym. Główny powód jest prostszy: użytkownik telefonu, który czeka, wraca do wyników i klika w następną firmę, a Ty nie dowiesz się nigdy, że w ogóle był. W usługach lokalnych, gdzie decyzja zapada w kilkadziesiąt sekund, ta różnica jest widoczna na liczbie telefonów, a nie w raporcie. Dlatego optymalizujemy przede wszystkim to, co widzi użytkownik w pierwszej sekundzie: główny obraz, nagłówek i widoczne wezwanie do kontaktu. Reszta może dogrywać się w tle.

Dwa narzędzia Google wystarczą i oba są bezpłatne. PageSpeed Insights pokazuje wyniki dla pojedynczego adresu i, co ważniejsze, dane od realnych użytkowników, jeżeli strona ma ich wystarczająco dużo. Raport Core Web Vitals w Search Console pokazuje całą witrynę pogrupowaną na adresy o podobnym problemie, więc od razu widać, czy kłopot dotyczy szablonu, czy jednej podstrony. Zasada przy czytaniu jest jedna: patrz na dane od realnych użytkowników, a nie wyłącznie na wynik testu laboratoryjnego, bo test symuluje jedno urządzenie i jedno łącze, a ranking bierze pod uwagę to, co spotkało prawdziwych ludzi.