Core Web Vitals: jak poprawić LCP, INP i CLS na stronie firmy

Czym są Core Web Vitals i jakie mają progi

Core Web Vitals to trzy wskaźniki, którymi Google opisuje wygodę korzystania ze strony: szybkość wczytywania, szybkość reakcji i stabilność układu. W polskiej wersji Search Console noszą nazwę "Podstawowe wskaźniki internetowe". Każdy z nich ma jasno określony próg dobrego wyniku, podany w dokumentacji web.dev i powtórzony w Google Search Central.

Progi są trzystopniowe. Wynik może być dobry, wymagający poprawy albo słaby. Poniższe wartości pochodzą z pomocy Search Console oraz dokumentacji PageSpeed Insights i są w obu miejscach takie same.

Co oznacza 75. percentyl

Progi nie odnoszą się do średniej ani do najlepszej wizyty. Google zaleca ocenianie strony na 75. percentylu wczytań, osobno dla urządzeń mobilnych i komputerów. W praktyce oznacza to, że co najmniej trzy czwarte wizyt musi mieścić się w progu dobrego wyniku. Dokumentacja PageSpeed Insights wyjaśnia, że ten poziom wybrano po to, aby właściciel strony widział także najbardziej uciążliwe doświadczenia swoich użytkowników, a nie tylko te najwygodniejsze.

Dla właściciela firmy wynika z tego ważny wniosek: fakt, że strona działa szybko na służbowym komputerze podłączonym do światłowodu, niczego jeszcze nie dowodzi. Klient hydraulika z Łodzi, który szuka pomocy przy pękniętej rurze, otwiera stronę na kilkuletnim telefonie, często przy słabym zasięgu. To jego wizyta, razem z wieloma podobnymi, decyduje o ocenie.

Dane z rzeczywistych wizyt a dane laboratoryjne

Dane z rzeczywistych wizyt pokazują, jak strona działała u prawdziwych użytkowników, a dane laboratoryjne to wynik jednego sztucznego testu w stałych warunkach. Oba rodzaje są potrzebne, ale służą do czegoś innego: pierwsze mówią, czy problem naprawdę istnieje, drugie pomagają znaleźć jego przyczynę.

Dane z rzeczywistych wizyt (w dokumentacji nazywane danymi polowymi lub danymi z terenu) pochodzą z raportu na temat użytkowania Chrome, w skrócie CrUX. Są to anonimowe, zbiorcze informacje od osób, które odwiedziły stronę w przeglądarce Chrome. PageSpeed Insights pokazuje je za okres ostatnich 28 dni. Jak zaznacza web.dev, nie jest to jedna liczba, lecz rozkład wyników z wielu urządzeń, sieci i miejsc, z którego narzędzia Google podają wartość 75. percentyla.

Dane laboratoryjne powstają przez wczytanie strony w kontrolowanym środowisku, zwykle za pomocą narzędzia Lighthouse. Jeden test oznacza jedno urządzenie, jedno łącze i jedną lokalizację. Dla telefonów Lighthouse symuluje urządzenie średniej klasy w sieci komórkowej. Zaletą jest powtarzalność i szczegółowa diagnostyka, wadą to, że test nie odtwarza zachowania ludzi.

Dlaczego wyniki się różnią

Różnice między obiema grupami danych są normalne i dokumentacja web.dev opisuje ich przyczyny. Test laboratoryjny zaczyna zwykle od pustej pamięci podręcznej, tymczasem powracający użytkownicy mają część plików zapisaną w przeglądarce, więc u nich LCP bywa krótszy. Największym elementem na małym, symulowanym ekranie może być coś innego niż na ekranach większości odwiedzających. Narzędzie laboratoryjne mierzy CLS głównie podczas wczytywania górnej części strony, a w danych rzeczywistych liczą się przesunięcia z całej wizyty, także te, które pojawiają się dopiero podczas przewijania.

Najmocniej różni się INP. Bez działania użytkownika nie ma czego mierzyć, dlatego Lighthouse w ogóle nie podaje tego wskaźnika. Zastępczo pokazuje całkowity czas blokowania (TBT), który web.dev określa jako laboratoryjne przybliżenie INP: poprawki zmniejszające TBT w teście mogą poprawić INP u prawdziwych użytkowników, ale nie jest to zależność pewna.

Gdzie sprawdzić Core Web Vitals swojej strony

Wyniki najlepiej sprawdzać w trzech narzędziach Google, które wzajemnie się uzupełniają: raport "Podstawowe wskaźniki internetowe" w Search Console pokazuje stan całego serwisu, PageSpeed Insights ocenia pojedynczy adres, a Lighthouse pozwala testować zmiany przed publikacją.

Raport w Search Console

Zgodnie z pomocą Search Console raport opiera się na danych CrUX, a jego strona przeglądu jest podzielona według rodzaju urządzenia: osobny wykres dotyczy telefonów, osobny komputerów i każdy typ urządzenia oceniany jest oddzielnie. Adresy nie są wymienione pojedynczo, lecz łączone w grupy stron działających podobnie, na przykład wszystkie karty produktów albo wszystkie wpisy na blogu. Wartość dla grupy to wynik osiągnięty przez 75 procent wyświetleń, a status grupy odpowiada najgorszemu z jej wskaźników. Jeśli więc LCP wymaga poprawy, a CLS jest słaby, cała grupa otrzymuje status słabej jakości.

Takie grupowanie jest wygodne, ponieważ wskazuje szablon, a nie setki osobnych adresów. Sklep z Poznania, w którym słaby wynik ma grupa kart produktów, nie musi poprawiać każdej karty oddzielnie. Wystarczy naprawić szablon karty, a zmiana obejmie wszystkie produkty.

W raporcie może pojawić się komunikat o braku danych. Pomoc Search Console podaje dwie przyczyny: usługa została dodana niedawno albo w CrUX nie ma wystarczającej liczby wizyt dla danego typu urządzenia. Dotyczy to wielu stron małych firm o niewielkim ruchu. W takiej sytuacji pozostaje test pojedynczego adresu w PageSpeed Insights lub Lighthouse.

PageSpeed Insights i Lighthouse

PageSpeed Insights po wpisaniu adresu pokazuje dwie części. Górna to dane z rzeczywistych wizyt z ostatnich 28 dni wraz z oceną Core Web Vitals. Według dokumentacji narzędzia ocena jest pozytywna, gdy 75. percentyl wszystkich trzech wskaźników mieści się w progu dobrego wyniku. Jeśli dla konkretnego adresu danych jest za mało, narzędzie pokazuje dane dla całej witryny, a gdy i tych brakuje, część z danymi rzeczywistymi pozostaje pusta.

Dolna część to test laboratoryjny Lighthouse z oceną wydajności w skali do 100 punktów. Wynik od 90 w górę oznacza ocenę dobrą, od 50 do 89 wymagającą poprawy, a poniżej 50 słabą. Pod oceną znajduje się lista zaleceń ze wskazaniem konkretnych plików i elementów. To ona jest najcenniejsza dla programisty. Ten sam test można uruchomić w narzędziach dla programistów w przeglądarce Chrome, co przydaje się do badania wersji roboczej strony, niedostępnej jeszcze publicznie.

LCP: jak przyspieszyć wyświetlenie największego elementu

LCP poprawia się, skracając cztery odcinki czasu: odpowiedź serwera, oczekiwanie na rozpoczęcie pobierania największego elementu, samo pobieranie oraz jego wyświetlenie. Zanim jednak zacznie się cokolwiek zmieniać, trzeba ustalić, który element strony jest tym największym.

Według opisu wskaźnika w web.dev pod uwagę brane są obrazy, kadry początkowe filmów, elementy z obrazem tła wczytanym w arkuszu stylów oraz bloki tekstu. Liczy się wyłącznie część widoczna na ekranie bez przewijania. Na stronie głównej firmy bywa to zdjęcie w nagłówku albo pierwszy slajd karuzeli, na karcie produktu zdjęcie towaru, a we wpisie blogowym często sam nagłówek lub pierwszy akapit. PageSpeed Insights wskazuje ten element wprost w części diagnostycznej, w pozycji poświęconej największemu wyrenderowaniu treści. Warto sprawdzić osobno widok mobilny i komputerowy, ponieważ na różnych ekranach największym elementem może być coś innego.

Czas odpowiedzi serwera

Pierwszym odcinkiem jest czas do otrzymania pierwszego bajtu odpowiedzi, oznaczany skrótem TTFB. Opracowanie web.dev o optymalizacji LCP zauważa, że na ten etap programista ma często najmniejszy wpływ, a jednocześnie opóźnia on wszystko, co następuje później. PageSpeed Insights pokazuje TTFB jako wskaźnik eksperymentalny, z progiem dobrego wyniku do 800 milisekund.

Wśród zaleceń web.dev znajdują się: ograniczenie przekierowań, ponieważ każda kolejna zmiana adresu przed dotarciem do strony wydłuża oczekiwanie, oraz serwowanie zapisanej wcześniej wersji strony z serwerów sieci dostarczania treści (CDN) położonych blisko użytkownika. Opracowanie zwraca też uwagę, że unikalne parametry w adresie mogą uniemożliwić skorzystanie z takiej zapisanej kopii. Dotyczy to między innymi ruchu z kampanii reklamowych, w których do adresu dopisywane są oznaczenia. Kancelaria z Krakowa, która prowadzi reklamy kierujące na stronę z długim łańcuchem przekierowań, może więc mieć słaby LCP właśnie u osób przychodzących z reklam, mimo że sama strona jest lekka. Jeżeli źródłem kłopotu jest przeciążony lub źle skonfigurowany serwer, rozwiązaniem bywa zmiana konfiguracji albo przeniesienie strony na inny hosting.

Obraz główny i priorytet ładowania

Drugi odcinek to czas, jaki mija, zanim przeglądarka w ogóle zacznie pobierać największy element. Web.dev stawia tu jasny cel: zasób LCP powinien zacząć się wczytywać równocześnie z pierwszym zasobem strony. Żeby tak się stało, przeglądarka musi znaleźć adres obrazu już w kodzie HTML. Jeśli obraz jest wstawiany dopiero przez JavaScript albo ukryty jako tło w zewnętrznym arkuszu stylów, przeglądarka dowiaduje się o nim z opóźnieniem. W takim układzie opracowanie zaleca wstępne wczytanie zasobu (preload) z wysokim priorytetem.

Dwa zalecenia z tego samego źródła dotyczą bezpośrednio obrazu głównego. Po pierwsze, obrazu LCP nie należy obejmować leniwym ładowaniem, czyli odkładaniem pobierania do chwili, gdy element zbliży się do widocznej części ekranu, ponieważ taki atrybut opóźnia jego pobranie. Po drugie, na obrazie, który najpewniej jest elementem LCP, warto ustawić atrybut fetchpriority z wartością wysokiego priorytetu. Web.dev zastrzega, że nadanie go więcej niż jednemu lub dwóm obrazom odbiera mu skuteczność. Obrazom niewidocznym na starcie, na przykład dalszym slajdom karuzeli, można z kolei nadać priorytet niski.

Trzeci odcinek to czas pobierania samego pliku. Zalecenia są tu dobrze znane: nowoczesne formaty AVIF lub WebP, rozmiar dopasowany do miejsca, w którym obraz jest wyświetlany, kompresja, sieć CDN oraz właściwe zasady przechowywania plików w pamięci podręcznej przeglądarki. Web.dev dodaje jednak trzeźwą uwagę, że w większości serwisów czas pobierania nie jest głównym wąskim gardłem, więc przed przystąpieniem do pracy warto potwierdzić w danych, że to rzeczywiście ten etap zawodzi. Samo zmniejszenie wagi zdjęć nie pomoże, jeśli przeglądarka zaczyna je pobierać zbyt późno.

Zasoby blokujące renderowanie

Ostatni odcinek to czas między pobraniem zasobu a jego wyświetleniem. Wydłużają go arkusze stylów i skrypty, które przeglądarka musi przetworzyć, zanim cokolwiek narysuje. Web.dev zaleca zmniejszenie arkuszy blokujących renderowanie, unikanie skryptów synchronicznych w nagłówku dokumentu i odraczanie ich wykonania. Osadzanie kodu bezpośrednio w dokumencie ma sens tylko dla bardzo małych fragmentów. Jeżeli treść strony powstaje dopiero w przeglądarce, po pobraniu i wykonaniu dodatkowych skryptów, opracowanie radzi rozważyć generowanie gotowego kodu HTML po stronie serwera.

Web.dev podaje orientacyjne proporcje dobrze zoptymalizowanego LCP: około 40 procent czasu na odpowiedź serwera, około 40 procent na pobranie zasobu i mniej niż po 10 procent na oba opóźnienia. Autorzy zastrzegają, że są to wskazówki, a nie sztywne reguły, i że nie należy przeliczać ich na konkretne milisekundy. Proporcje dobrze jednak pokazują, gdzie szukać: jeśli większość czasu pochłania oczekiwanie na rozpoczęcie pobierania obrazu, problemem jest kolejność ładowania, a nie waga pliku.

INP: skąd biorą się opóźnienia reakcji i jak je skrócić

Opóźnienia reakcji biorą się niemal zawsze z tego, że przeglądarka jest zajęta wykonywaniem kodu JavaScript i nie może od razu obsłużyć kliknięcia. INP poprawia się więc przede wszystkim przez ograniczenie ilości tego kodu i podzielenie długich zadań na krótsze.

Według opisu wskaźnika INP obserwuje kliknięcia myszą, dotknięcia ekranu i naciśnięcia klawiszy przez cały czas wizyty, a jako wynik podaje najdłuższą zaobserwowaną reakcję, z pominięciem wartości odstających. Na stronach z bardzo wieloma interakcjami pomijana jest jedna najgorsza na każde 50. Jeśli użytkownik tylko przewijał stronę i niczego nie kliknął, wizyta nie ma wartości INP. Dlatego serwisy o małym ruchu często nie mają tego wskaźnika w danych rzeczywistych, a PageSpeed Insights wystawia wtedy ocenę na podstawie LCP i CLS.

Trzy fazy każdej interakcji

Opracowanie web.dev o optymalizacji INP dzieli każdą interakcję na trzy części. Opóźnienie wejściowe trwa od chwili kliknięcia do momentu, w którym strona zaczyna na nie reagować. Czas przetwarzania to wykonanie kodu przypisanego do danego działania. Opóźnienie prezentacji to czas potrzebny przeglądarce na narysowanie kolejnej klatki z widocznym efektem. Suma tych trzech części daje pełne opóźnienie.

Podział ten pomaga w rozmowie z programistą, ponieważ każda faza ma inne przyczyny. Długie opóźnienie wejściowe oznacza zwykle, że w chwili kliknięcia przeglądarka była zajęta czymś innym, najczęściej wczytywaniem i uruchamianiem skryptów podczas ładowania strony. Długi czas przetwarzania wskazuje na zbyt rozbudowany kod obsługujący dane działanie. Długie opóźnienie prezentacji wiąże się między innymi z bardzo rozbudowaną strukturą dokumentu, ponieważ, jak podaje web.dev, duża struktura wymaga więcej pracy przy rysowaniu niż mała.

Ciężki JavaScript i skrypty zewnętrzne

Znaczna część kodu obciążającego przeglądarkę nie pochodzi od autora strony, lecz od zewnętrznych dostawców. Web.dev w opracowaniu o skryptach zewnętrznych wymienia wśród nich przyciski mediów społecznościowych, osadzone odtwarzacze filmów, ramki reklamowe, skrypty analityczne i skrypty testów porównawczych. Źródło nazywa je częstą przyczyną spowolnień i wyjaśnia, że analiza oraz wykonanie skryptów mocno obciążają procesor, co może opóźniać reakcję na działania użytkownika.

Zalecenia są praktyczne. Skrypty zewnętrzne, które nie są niezbędne do wyświetlenia strony, powinny być wczytywane asynchronicznie lub z odroczeniem. Osadzone filmy, mapy i podobne elementy można wczytywać dopiero wtedy, gdy są potrzebne. Najprostsza rada brzmi zaś: jeśli skrypt nie wnosi wyraźnej wartości, należy go usunąć. W firmach, z którymi pracujemy, przegląd skryptów kończy się często odkryciem kodu po dawno zakończonych kampaniach, po nieużywanym już czacie albo po narzędziu, z którego raportów nikt nie korzysta. Usunięcie ich jest najtańszą poprawką, bo nie wymaga pisania niczego nowego.

Dla kodu własnego web.dev zaleca dzielenie długich zadań tak, aby przeglądarka mogła w przerwach obsłużyć działania użytkownika, oraz wykonywanie w odpowiedzi na kliknięcie tylko tego, co potrzebne do pokazania efektu, z odłożeniem reszty na później. Przykład z życia: w sklepie po kliknięciu przycisku dodania do koszyka klient powinien od razu zobaczyć potwierdzenie, a przeliczenie zawartości, zapis danych analitycznych i odświeżenie polecanych produktów mogą nastąpić chwilę potem. Jeżeli wszystko dzieje się naraz, klient przez ułamek sekundy widzi stronę, która wygląda na zawieszoną, i klika ponownie.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

CLS: jak zatrzymać przesunięcia układu strony

Przesunięcia układu zatrzymuje się, rezerwując z góry miejsce na wszystko, co pojawia się na stronie z opóźnieniem: obrazy, reklamy, osadzone treści, banery i tekst zapisany czcionką pobieraną z sieci. Jeśli przeglądarka od początku wie, ile miejsca zajmie dany element, nie musi później rozsuwać pozostałych.

Każdy zna to zjawisko z własnego doświadczenia: czytany akapit nagle zjeżdża w dół, bo nad nim wczytało się zdjęcie, albo przycisk ucieka spod palca i kliknięcie trafia w coś innego. Opis wskaźnika w web.dev precyzuje, że liczą się wyłącznie przesunięcia nieoczekiwane. Zmiana układu, która następuje w ciągu 500 milisekund od kliknięcia, dotknięcia lub naciśnięcia klawisza, jest traktowana jako spodziewana i może zostać pominięta. Rozwinięcie odpowiedzi po kliknięciu w pytanie nie psuje więc wyniku, a baner, który sam wsuwa się nad treść, już tak.

Opracowanie web.dev o optymalizacji CLS wymienia najczęstsze przyczyny: obrazy bez wymiarów, reklamy, osadzone treści i ramki bez wymiarów, treści wstawiane dynamicznie oraz czcionki internetowe.

Obrazy bez wymiarów

Najprostsza i najczęściej pomijana poprawka to podanie szerokości i wysokości każdego obrazu oraz filmu w kodzie strony. Współczesne przeglądarki wyliczają z tych dwóch wartości proporcje i rezerwują właściwe miejsce, zanim plik zostanie pobrany. Web.dev zaleca połączenie atrybutów z regułą stylów ustawiającą automatyczną wysokość, dzięki czemu obraz nadal dopasowuje się do szerokości ekranu. To samo można osiągnąć właściwością aspect-ratio w arkuszu stylów.

Problem dotyczy szczególnie obrazów poniżej pierwszego ekranu, wczytywanych leniwie. Test laboratoryjny ich nie zauważa, ponieważ nie przewija strony, a w danych rzeczywistych pojawiają się jako przesunięcia podczas czytania. To częsty powód sytuacji, w której test pokazuje CLS bliski zeru, a raport w Search Console zgłasza słaby wynik. Web.dev wprost wskazuje, że taka różnica zwykle oznacza przesunięcia następujące już po wczytaniu strony.

Reklamy, banery i treści wstawiane po czasie

Reklamy web.dev opisuje jako jedno z głównych źródeł przesunięć, ponieważ ich rozmiar bywa zmienny i spychają widoczną treść w dół. Podobnie zachowują się osadzone filmy, mapy i wpisy z mediów społecznościowych. Rozwiązaniem jest zarezerwowanie miejsca regułą minimalnej wysokości lub proporcji. Gdy dokładny rozmiar nie jest znany, należy przyjąć najmniejszy spodziewany. Opracowanie przestrzega też przed błędem odwrotnym: usunięcie zarezerwowanego miejsca, gdy reklama się nie wyświetli, może spowodować równie duże przesunięcie jak wstawienie treści. Elementy wczytywane z opóźnieniem lepiej umieszczać niżej, bo treść wstawiona blisko góry ekranu przesuwa więcej.

Osobną grupą są elementy wstawiane przez samą stronę: pasek z informacją o promocji, baner zgody na pliki cookie, formularz zapisu na newsletter, okienko czatu. Web.dev zaleca dwa wyjścia. Można zarezerwować dla nich miejsce od początku albo wyświetlić je jako nakładkę ponad treścią, tak aby nie przesuwały pozostałych elementów. Pasek promocyjny, który sklep z Poznania włącza przed świątecznym szczytem sprzedaży i który po sekundzie spycha całą stronę w dół, potrafi zepsuć ocenę wszystkich grup adresów jednocześnie, ponieważ wyświetla się na każdej podstronie.

Przesunięcia powodują również niektóre animacje. Zmiana położenia elementu przez właściwości odpowiadające za odległość od góry i lewej krawędzi wywołuje przeliczenie układu, dlatego web.dev zaleca stosowanie właściwości transform, która nie wpływa na inne elementy i nie jest liczona do CLS.

Czcionki internetowe

Czcionka pobierana z sieci dociera do przeglądarki z opóźnieniem. Do tego czasu tekst jest wyświetlany czcionką zastępczą albo pozostaje niewidoczny, a po podmianie zmienia szerokość i wysokość, co przesuwa sąsiednie elementy. Web.dev wymienia kilka sposobów ograniczenia tego efektu: wstępne wczytanie najważniejszych czcionek, aby były gotowe przy pierwszym rysowaniu strony, wskazanie dobrze dobranej czcionki zastępczej, dopasowanie jej rozmiaru do czcionki docelowej za pomocą właściwości size-adjust oraz ustawienie font-display na wartość optional, przy której czcionka internetowa jest używana tylko wtedy, gdy zdąży się wczytać przed pierwszym ułożeniem strony. Z perspektywy firmy oznacza to często prostą decyzję: ograniczenie liczby krojów i odmian do tych, które są naprawdę używane.

• Każdy obraz i film ma w kodzie podaną szerokość i wysokość lub proporcje.
• Miejsca na reklamy, mapy i osadzone filmy mają zarezerwowaną wysokość.
• Puste miejsce po niewyświetlonej reklamie nie jest zwijane.
• Baner zgody na pliki cookie i pasek promocyjny są nakładką albo mają stałe miejsce.
• Najważniejsze czcionki są wczytywane wstępnie, a czcionka zastępcza ma zbliżone wymiary.
• Animacje przesuwające elementy korzystają z właściwości transform.
• Wynik został sprawdzony także podczas przewijania strony, nie tylko po jej otwarciu.

WordPress i wtyczki jako częste źródło problemów

Na stronach opartych na WordPressie słabe wyniki rzadko wynikają z samego systemu, a znacznie częściej z tego, co zostało do niego dołożone: rozbudowanego motywu, kreatora układów i kilkunastu lub kilkudziesięciu wtyczek. To obserwacja z naszej codziennej pracy przy audytach, a mechanizm jest zgodny z tym, co opisuje web.dev: każdy dodatkowy arkusz stylów i skrypt to kolejny zasób, który przeglądarka musi pobrać i przetworzyć.

Typowy obraz wygląda następująco. Wtyczka formularza kontaktowego wczytuje swoje pliki na każdej podstronie, choć formularz znajduje się tylko na jednej. Wtyczka karuzeli dokłada bibliotekę skryptów dla jednego slajdu na stronie głównej. Wtyczki czatu, wyskakujących okien i przycisków mediów społecznościowych dodają skrypty zewnętrzne, które obciążają przeglądarkę i wydłużają reakcję na kliknięcia. Kreator układów tworzy bardzo głęboką strukturę dokumentu, a ta, jak wiemy z opracowania o INP, zwiększa nakład pracy przy rysowaniu. Każda z tych rzeczy osobno jest niewielka, razem dają stronę, która na telefonie reaguje z wyraźnym opóźnieniem.

Drugą grupą kłopotów są, paradoksalnie, wtyczki przyspieszające. Ich ustawienia potrafią stać w sprzeczności z zaleceniami opisanymi wyżej. Najczęstszy przypadek, który spotykamy, to leniwe ładowanie włączone dla wszystkich obrazów bez wyjątku, a więc także dla zdjęcia w nagłówku, które jest elementem LCP. Web.dev jednoznacznie odradza takie ustawienie. Zdarza się również odroczenie wszystkich skryptów, po którym menu lub karuzela pojawiają się z opóźnieniem i przesuwają treść, co pogarsza CLS. Ustawienia takich wtyczek trzeba dobierać do konkretnej strony i sprawdzać po każdej zmianie, a nie włączać wszystkich naraz.

Przy starszych stronach, zbudowanych na ciężkim motywie wielozadaniowym, przychodzi czasem moment, w którym dalsze poprawki kosztują więcej niż przebudowa. Jeżeli planują Państwo nową wersję serwisu, wymagania dotyczące trzech wskaźników warto wpisać do zamówienia już na etapie projektu. Opisujemy to szerzej we wpisie o tym, jak przygotować stronę firmową pod SEO, a przy tworzeniu stron uwzględniamy je od pierwszej makiety.

Jaki jest realny wpływ Core Web Vitals na pozycje w Google

Core Web Vitals są wykorzystywane przez systemy rankingowe Google, ale są jednym z wielu sygnałów i nie zastąpią trafnej, przydatnej treści. Tak wynika wprost z dokumentacji Google Search Central i właśnie w tych granicach warto o nich myśleć.

Strona o jakości strony w wynikach wyszukiwania zawiera kilka stwierdzeń, które warto znać. Google potwierdza, że jego systemy rankingowe korzystają z Core Web Vitals, i zaleca właścicielom witryn osiągnięcie dobrych wyników. Jednocześnie zastrzega, że dobre rezultaty w raporcie Search Console lub w narzędziach zewnętrznych nie gwarantują miejsca na szczycie wyników oraz że dążenie do idealnej oceny wyłącznie z myślą o SEO może nie być najlepszym wykorzystaniem czasu. Wyjaśnia też, że nie istnieje jeden sygnał jakości strony: systemy rankingowe biorą pod uwagę różne sygnały zgodne z ogólnym wrażeniem z korzystania ze strony.

Najważniejsze zdanie dotyczy hierarchii. Google pisze, że wyszukiwarka zawsze stara się pokazać najtrafniejsze treści, nawet jeśli jakość korzystania ze strony jest gorsza. Dodaje jednak, że dla wielu zapytań dostępnych jest dużo pomocnych treści i w takich przypadkach dobra jakość strony może przyczynić się do sukcesu w wyszukiwarce. Innymi słowy: szybka strona ze słabą treścią nie wyprzedzi z tego powodu wolniejszej strony z dobrą odpowiedzią, ale tam, gdzie kilka firm odpowiada na pytanie podobnie dobrze, wygoda korzystania może mieć znaczenie.

Z tego powodu nie obiecujemy wzrostu pozycji po poprawie wskaźników i nie traktujemy ich jako osobnego celu. W naszej pracy to jeden z elementów SEO technicznego, obok indeksowania, struktury serwisu i danych strukturalnych, a całość jest częścią szerszych działań opisanych we wpisie o tym, jak działa Google i co podnosi widoczność. Osobną korzyścią, niezależną od wyszukiwarki, jest wygoda klientów: strona, która wczytuje się sprawnie, reaguje od razu i nie przesuwa przycisków pod palcem, jest po prostu łatwiejsza w użyciu, także dla osób przychodzących z reklam i mediów społecznościowych.

Kolejność prac i rozmowa z programistą

Prace warto zaczynać od grup adresów ze statusem słabym w widoku mobilnym, które mają najwięcej wyświetleń i największe znaczenie dla sprzedaży, a kończyć na potwierdzeniu efektu w danych z rzeczywistych wizyt. Taka kolejność chroni przed poprawianiem wyniku punktowego na podstronach, których prawie nikt nie odwiedza.

Pomoc Search Console podaje, że adresy w grupie są uporządkowane malejąco według liczby wyświetleń, więc raport sam podpowiada, od czego zacząć. Skoro status grupy odpowiada najgorszemu wskaźnikowi, najpierw trzeba ustalić, który z trzech zawodzi, a dopiero potem szukać przyczyny. Dla każdego wskaźnika przebiega to inaczej, dlatego zlecenie w rodzaju "prosimy poprawić Core Web Vitals" jest zbyt ogólne, aby dało się je dobrze wycenić i rozliczyć.

1. Odczyt stanu w Search Console

   W raporcie dla telefonów ustalamy, które grupy adresów mają status słaby lub wymagający poprawy i który wskaźnik o tym przesądza.

2. Wybór adresów reprezentujących szablony

   Z każdej grupy wybieramy po jednym lub dwóch adresach, na przykład stronę główną, stronę usługi, kartę produktu i wpis na blogu.

3. Diagnoza w PageSpeed Insights i Lighthouse

   Dla wybranych adresów sprawdzamy, co jest elementem LCP, które skrypty najdłużej zajmują przeglądarkę i które elementy się przesuwają.

4. Poprawki od najprostszych

   Najpierw zmiany o małym ryzyku: usunięcie zbędnych skryptów, wymiary obrazów, priorytet obrazu głównego. Potem zmiany większe: serwer, szablon, motyw.

5. Test na kopii roboczej i wdrożenie

   Każdą zmianę sprawdzamy w teście laboratoryjnym przed publikacją oraz upewniamy się, że strona nadal działa poprawnie.

6. Potwierdzenie w danych rzeczywistych

   Po wdrożeniu uruchamiamy w Search Console weryfikację poprawki i obserwujemy raport przez kolejne tygodnie.

Ile czeka się na efekt w raportach

Poprawka wdrożona dzisiaj nie zmieni raportu jutro. Dane z rzeczywistych wizyt w PageSpeed Insights obejmują ostatnie 28 dni, więc nowe, lepsze wizyty stopniowo wypierają z tego okresu starsze. W Search Console po zgłoszeniu poprawki rozpoczyna się 28-dniowe monitorowanie. Według pomocy narzędzia problem zostaje uznany za naprawiony, jeśli w tym czasie nie wystąpił pod żadnym adresem z grupy, a samo zgłoszenie nie powoduje ponownego indeksowania stron. Do tego czasu jedynym szybkim potwierdzeniem jest test laboratoryjny, z zastrzeżeniami opisanymi wcześniej. O tej zwłoce dobrze uprzedzić osoby decydujące o budżecie, aby nie oczekiwały zmiany statusu w dniu odbioru prac.

O co zapytać programistę

Rozmowa z wykonawcą przebiega sprawniej, gdy obie strony posługują się tymi samymi danymi. Przed zleceniem warto przekazać zrzut raportu z Search Console z nazwami grup adresów oraz wyniki PageSpeed Insights dla wybranych podstron, a następnie poprosić o odpowiedź na kilka prostych pytań. Który element jest elementem LCP na telefonie i w którym z czterech odcinków traci się najwięcej czasu? Jakie skrypty zewnętrzne działają na stronie i które z nich można usunąć lub wczytywać później? Które elementy powodują przesunięcia i czy da się zarezerwować dla nich miejsce? Jakie zmiany niosą ryzyko dla działania formularzy, koszyka lub pomiaru w Google Analytics? Rzetelny wykonawca odpowie na nie konkretnie, wskazując pliki i elementy, a nie ogólnikami.

Warto też ustalić sposób odbioru. Rozsądnym kryterium nie jest liczba punktów w teście, która zmienia się między uruchomieniami, lecz wykonanie uzgodnionych zmian oraz mieszczenie się danych rzeczywistych w progach po upływie okresu pomiaru. Trzeba przy tym uczciwie przyjąć, że na wynik wpływają również decyzje biznesowe. Jeżeli dział marketingu chce zachować czat, okno z promocją i kilka narzędzi pomiarowych, programista nie osiągnie tego samego co na stronie bez tych dodatków. Część poprawek dotyczy też układu strony, na przykład rezygnacji z karuzeli w nagłówku, i wtedy przydaje się spojrzenie od strony projektowania UX.

Jeśli nie mają Państwo pewności, od czego zacząć, punktem wyjścia może być audyt SEO, w którym wskaźniki są oceniane razem z pozostałymi elementami technicznymi i ustawiane w kolejności według wagi dla serwisu. O tym, co powinno znaleźć się w takim opracowaniu, piszemy we wpisie o tym, co zawiera audyt SEO. W sklepach internetowych, gdzie szablonów i skryptów jest najwięcej, prace nad wskaźnikami łączymy zwykle z pozycjonowaniem sklepu, ponieważ te same szablony decydują o indeksowaniu kategorii i kart produktów.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl