Czego się dowiesz z tego artykułu?

  • Czym są Web Core Vitals?
  • Czy Web Core Vitals będą wpływać na pozycję strony?
  • Jak mierzyć Web Core Vitals?
  • Jak optymalizować stronę pod Web Core Vitals?
Core Web Vitals – kompleksowy poradnik
Core Web Vitals – kompleksowy poradnik

Czym w ogóle są Core Web Vitals?

Core Web Vitals to trzy czynniki, które są częścią składową czegoś, co Google nazywa page experience. Nie od dziś wiadomo, że Google stara się zmuszać deweloperów stron internetowych do zmian, które będą wpływały na pozytywne doświadczenia użytkownika. Szybciej i sprawniej działające strony, które znajdują się w wyszukiwarce, to lepsze wrażenia z używania samego Google, a przecież właśnie o to chodzi.

Do niedawna szybkość strony była mierzona jedynie za pomocą prostych testów, które mocno odbiegały od rzeczywistości. Nie mówię, że teraz jest idealnie, ale Google stara się realnie patrzeć na web performance i dodaje coraz więcej czynników do doświadczeń użytkowników korzystających ze strony.

Core Web Vitals a page experience

Oprócz czynników związanych z dostosowaniem do urządzeń mobilnych, bezpieczeństwa oraz przeszkadzających reklam, Google dokłada trzy kolejne czynniki. Będą one odpowiedzialne za określenie, czy dana podstrona jest odpowiednia dla użytkownika pod kątem szybkości i użyteczności. Oczywiście nie są to idealne czynniki, jednak na dzień dzisiejszy są o wiele bardziej miarodajne niż stosowane dotychczas metryki.

Core Web Vitals, są czynnikami mierzonymi w czasie rzeczywistym, na komputerach realnych użytkowników wchodzących na Twoją stronę. Co prawda możesz zbadać te wskaźniki za pomocą testów laboratoryjnych (wszystkie narzędzia do szybkości strony), ale Google będzie brało pod uwagę, to jak Twoja strona wypada na komputerach realnych użytkowników.

Chcesz się nauczyć skutecznie pozyskiwać klientów z Google? Zobacz nasz kurs SEO, który jest instrukcją działania krok po kroku.

Składniki Core Web Vitals

W tym artykule skupimy się tylko na czynnikach, które wchodzą w skład Core Web Vitals. Poniżej postaram się dokładnie wyjaśnić każdy z nich. To na podstawie tych czynników, Twoja strona będzie oceniana. Co ważne, jeśli przynajmniej jeden z tych czynników będzie wykazywał problem, cała podstrona będzie oznaczona jako niewystarczająco dobra, nawet jeśli pozostałe czynniki będą idealne.

Optymalizacją i poprawą strony zajmiemy się w dalszej części artykułu.

LCP – Largest Contentful Paint

Pierwszym z elementów Core Web Vitals jest LCP (Largest Contentful Paint), który mierzy szybkość ładowania najważniejszych elementów danej podstrony. Chodzi tutaj o to, aby użytkownik jak najszybciej zobaczył pierwszy ekran i mógł zacząć korzystać ze strony. Ładowanie elementów, które znajdują się niżej na stronie, nie ma wpływu na ten wskaźnik, dlatego warto priorytetyzować kolejność ładowania wszystkich zasobów.

LCP – Largest Contentful Paint

Mówiąc dokładnie, wskaźnik LCP pokazuje czas renderowania największego elementu znajdującego się na pierwszym ekranie po załadowaniu strony. Takim elementem może być grafika (png, jpg, svg webp), wideo czy nawet blok tekstu.

LCP – przykład działania

Czas załadowania tego elementu od początku rozpoczęcia renderowania będzie reprezentował właśnie wskaźnik LCP, który jest wyrażany w sekundach. Przeglądarka zaczyna liczyć czas od pojawienia się pierwszego elementu (FCP), do chwili gdy największy element zostanie w pełni załadowany.

  • Jeśli dana podstrona ma wskaźnik poniżej 2,5 s, to oznaczona jest jako dobra.
  • Czas powyżej 2,5 s, ale niższy niż 4 sekundy to przedział ostrzegawczy i należy tutaj zacząć myśleć o poprawieniu tego wskaźnika.
  • Jeśli LCP wynosi powyżej 4 sekund, Google uzna daną podstronę za niewystarczającą i oznaczy ją jako problematyczną.

FID – First Input Delay

FID (First Input Delay) to wskaźnik, który mierzy czas od pierwszej interakcji użytkownika ze stroną (np. gdy klikniesz link lub naciśniesz przycisk) do czasu, gdy przeglądarka jest w stanie rozpocząć przetwarzanie akcji związanej z tą interakcją.

FID – First Input Delay

Głownie chodzi o to, aby Twoja strona była jak najszybciej interaktywna. Nie może być tak, że dopiero po załadowaniu całej strony (nawet tej niewidocznej części) menu dopiero działa poprawnie. Możliwość użycia przycisków oraz innych elementów interaktywnych musi być dostępna jak najszybciej.

Jak szybko? Tutaj czasy są oznaczone w milisekundach i tak:

  • Strona zostanie oznaczona jako poprawna jeśli FID wyniesie poniżej 100ms.
  • FID pomiędzy 100ms a 300ms, oznacza potrzebę optymalizacji.
  • Jeśli FID wyniesie powyżej 300ms, strona zostanie oznaczona jako problematyczna.

CLS – Cumulative Layout Shift

CLS (Cumulative Layout Shift) to metryka badająca wizualną stabilność strony. Co oznacza stabilność? Chodzi tutaj o wszelkie zmiany layoutu strony, które powodują niekontrolowane przesunięcia różnych elementów. Na pewno zdarzyło Ci się, że w trakcie ładowania, a raczej doładowywania nowych elementów zmienia się cały jej układ. Z punktu widzenia użytkownika to problem, bo może powodować problemy z interakcją, takie jak pokazane w poniższym przykładzie:

Prezentacja pokazująca, jak niestabilność układu może negatywnie wpłynąć na użytkowników.

Takie niespodziewane zmiany w treści strony spowodowane są asynchronicznym doładowywaniem lub dynamicznym zmienianiem strony. CLS mierzy właśnie takie skoki elementów podczas ładowania strony, prezentowany wskaźnik dla danej podstrony to suma zmian wszystkich elementów, które zmieniają się podczas ładowania.

Aby obliczyć CLS, najpierw należy znać cząstkowe wskaźniki dla każdego z elementów strony. Dla każdego elementu oblicza się tzw. layout shift score, który można określić poniższym wzorem:

layout shift score = impact fraction * distance fraction

Impact fraction
Impact fraction mierzy stabilność elementu za pomocą stosunku tego elementu do wysokości viewportu, czyli ekranu przeglądarki.

Przykład zmiany pozycji elementu strony

Na powyższym obrazku element zajmuje połowę widocznego obszaru. Po załadowaniu element przesuwa się w dół o 25% wysokości okna przeglądarki. Czerwony prostokąt wskazuje sumę widocznego obszaru elementu w obu przypadkach, który stanowi 75% całego obszaru, więc jego impact fraction wynosi 0,75.

Distance fraction
Distance fraction odpowiada za odległość, jaką dany element „przemierza” podczas ładowania taki element.

W powyższym przykładzie największym wymiarem zmiany jest wysokość, a niestabilny element przesunął się o 25% wysokości ekranu, co daje nam distance fraction równe 0,25.

Korzystając z powyższego wzoru, możemy już obliczyć layout shift score, które wynosi 0,1875 (0,75 * 0,25 = 0,1875).

Dodanie elementu na stronie też może być powodem zmian w całym layoucie. Poniżej możesz zobaczyć, jak doładowanie przycisku powoduje przesunięcie treści pod przyciskiem.

Jaki powinien być CLS?

Wskaźnik CLS wyrażany jest nie w sekundach, a stosunku odległości i przesunięcia danego elementu. Jego wynik to ułamek – im większy, tym gorzej.

CLS – Cumulative Layout Shift
  • Wszystkie wartości powyżej 0,1 to dobry wskaźnik.
  • Wartości poniżej 0.1, ale większe niż 0.25, to obszar do poprawy.
  • Strony ze wskaźnikiem poniżej 0,25 będą oznaczone jak problematyczne.

Czy Web Core Vitals będą wpływać na SEO / pozycjonowanie?

Wielu zadaje sobie pytanie, czy Core Web Vitals będą w jakiś sposób wpływać na pozycjonowanie. Google oficjalnie potwierdziło, że Core Web Vitals będą czynnikiem rankingowym. Jednak nie wiemy, jaka będzie waga tego czynnika. Moim zdaniem, zmiany w wynikach wyszukiwania nie będą rewolucyjne.

Podobnie było przy wprowadzaniu certyfikatów SSL. Google zmusiło większość właścicieli stron do ich instalacji, mimo że posiadanie certyfikatu w sumie nie dawało żadnych korzyści związanych z ruchem organicznym.

Oczywiście nie oznacza to, że nie należy pracować nad tymi wskaźnikami. One będą brane pod uwagę, chociażby przy pojawieniu się danego artykułu w newsach Google (Discover), czy innych wynikach niestandardowych.

Prawdopodobnie z Core Web Vitals będzie podobnie, jak to miało miejsce podczas wprowadzania indeksowania mobilnego. Strony, które będą bardzo słabo zoptymalizowane, mogą stracić ruch, ale takich przypadków nie będzie, aż tak dużo.

Wiele będzie też zależało od branży. Zakładam, że im większa konkurencja, tym bardziej trzeba będzie się skupić na optymalizacji strony pod Core Web Vitals. W konkurencyjnych branżach małe zmiany robią różnice, zwłaszcza w e-commerce. Dodam też, że sama optymalizacja szybkości pod kątem Core Web Vitals może zwiększyć sprzedaż.

Narzędzia do mierzenia Core Web Vitals

Skoro mamy za sobą trochę teorii, przejdźmy do mierzenia Core Web Vitals. Google się tutaj postarało i przygotowało nam zestaw narzędzi, które możesz wykorzystać za darmo. Oprócz narzędzi Google, wiele serwisów do sprawdzania szybkości strony od niedawna obliczają już współczynniki dla Core Web Vitals.

Lista narzędzi Google, które mierzą Core Web Vitals

Google Search Console

Jeśli używasz Google Search Console (bardzo polecam!), to na pewno zauważyłeś tam nowy raport nazwany „Podstawowe wskaźniki internetowe”, zawierający dwa wykresy: Urządzania mobilne oraz Wersja na komputery. Jest to wykres ilości adresów URL, które znajdują się jednym trzech przedziałów:

  • adresy URL dobrej jakości
  • adresy URL wymagających poprawienia
  • adresów URL słabej jakości
Podstawowe wskaźniki internetowe w Google Search Console

Po wejściu w szczegółowy raport możesz sprawdzić dokładnie adresy URL oraz rodzaj problemu, które pomogą Ci w diagnozie sytuacji:

Ligthouse

Lighthouse to zautomatyzowane narzędzie typu open source do poprawy jakości stron internetowych. Możesz go uruchomić na dowolnej stronie internetowej. Narzędzie służy do mierzenia wydajności, dostępności, progresywnych aplikacji internetowych, SEO i nie tylko.

Wynik raportu w Lighthouse

Od wersji 6.0, narzędzie to sprawdza stronę pod kątem Core Web Vitals i używa ich w obliczaniu punktacji dla danej podstrony.

PageSpeed Insights

Google PageSpeed Insights korzysta bezpośrednio z narzędzia Ligthouse, dlatego będziesz mógł tam sprawdzić czynniki Core Web Vitals, które wpływają na ogólną ocenę w tym narzędziu.

Narzędzia deweloperskie Chrome

Jeśli lubisz korzystać z narzędzi deweloperskich w przeglądarce Chrome, to w zakładce performance możesz od niedawna używać raportu dla Core Web Vitals.

Core Web Vitals w Chrome WebDev

Wtyczka do Chrome – Web Vitals

Bardzo fajną opcją do oceny Core Web Vitals jest wtyczka do Chrome o nazwie Web Vitals. Pobierzesz ją tutaj:

https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma

Dzięki wtyczce możesz sprawdzić Core Web Vitals podczas przeglądania każdej strony. Zielony kwadrat w ikonie oznacza poprawne wskaźniki. Gdy pojawi się czerwony, możesz sprawdzić, który wskaźnik jest problematyczny.

Wtyczka Web Vitals dla Chrome

Dane laboratoryjne vs dane rzeczywiste

To, co koniecznie musisz wiedzieć, to fakt, że wszystkie powyższe narzędzia, a także każde inne będą tzw. testem w warunkach laboratoryjnym. Każde z narzędzi uruchamia Twoją stronę i wykonuje serię testów na swoim komputerze o określonej wydajności. W przypadku Chrome WebTools oraz Lighthouse dostępnego w przeglądarce Chrome, test odbywa się na Twoim komputerze, a zatem w pewnych warunkach, jakimi są:

  • szybkość łącza internetowego
  • wydajność procesora
  • zasobność pamięci RAM
  • ogólne obniżenie komputera

Teraz, jeśli masz super szybki komputer, to narzędzia te mogą pokazać poprawne wartości, ponieważ strona ładuje się bardzo szybko. Ta sama strona może być o wiele wolniejsza, gdy zostaje uruchomiona na znacznie słabszym sprzęcie.

Google o tym wie, dlatego analizuje dane dla każdej podstrony podczas wizyt realnych użytkowników używających przeglądarki Chrome. Tak naprawdę, to odwiedzający Twoją stronę, ją nieświadomie testują. Teoretycznie, im słabsze urządzenia posiadają, tym bardziej musisz się postarać – zwłaszcza w kwestii urządzeń mobilnych.

Uśrednione dane o pomiarach realnych użytkowników, możesz znaleźć w kilku miejscach. Pierwsze z nich to wspomniane wcześniej Google Search Console. Drugie natomiast to specjalny raport Google Data Studio specjalnie przygotowane przez Google. Wygląda on tak (na dole możesz zmieniać strony, bo jest ich kilka):

Taki raport da Ci konkretny obraz tego, jak Twoja strona jest oceniana przez Google na bazie testów z realnymi urządzeniami. Instrukcja uruchomiania takiego raportu znajduje się tutaj: https://web.dev/chrome-ux-report-data-studio-dashboard/

Optymalizacja strony pod Core Web Vitals

Jak poprawić LCP?

LCP to wskaźnik, który pokaże Ci problemy związane z szybkością ładowania strony takimi jak:

  • Wolna odpowiedź serwera, która będzie najpewniej spowodowana brakiem optymalizacji kodu po stronie serwera lub infrastruktury. Sam hosting nie będzie miał aż tak dużego wpływu na ten wskaźnik.
  • Wolne ładowanie zasobów, a przede wszystkim grafik, które powinny mieć realnie używane rozmiary. Do tego Google zaleca kompresje w formacie WEBP, która jest o wiele wydajniejsza przy podobnej jakości do znanych formatów.
  • Blokowaniem renderowania, czyli na przykład synchronicznym ładowaniem po kolei zamiast skupianiem się na pierwszym ekranie.

Optymalizacja serwera

Serwer odpowiada za dostarczenie wszelkich niezbędnych informacji, które są potrzebne w procesie renderowania (tworzenia) strony przez Twoją przeglądarkę. Im szybciej serwer dostarczy wszystkie informacje czy pliki, tym szybciej przeglądarka zacznie renderować stronę.

Na tym etapie, warto jest bazować na parametrze TTFB (Time To Firs Byte), który pokazuje, po jakim czasie serwer zaczyna wysyłać pierwsze dane. Optymalizacja tego parametru to praca przede wszystkim na dwóch polach: infrastruktury samego serwera oraz optymalizacji aplikacji.

Infrastruktura serwera to elementy takie jak oprogramowanie serwera czy połączenia z bazą danych. Warto zadbać, aby serwer miał najnowszą wersję PHP oraz był zainstalowany na szybkich dyskach SSD. Jednak sam wpływ hostingu jest znacznie mniejszy, niż może się wydawać. Znacznie więcej możliwości optymalizacji jest po stornie aplikacji.

Oprogramowanie odpowiadające za wyświetlanie stron internetowych to zazwyczaj systemy CMS, taki jak bardzo popularny WordPress, na którym bazuje ponad połowa stron internetowym. Sam WordPress jest dość szybkim systemem i w czystej postaci jest w miarę radzi sobie z Core Web Vitals. Problem stanowią rozbudowane motywy i wtyczki, które generują ogromną ilość kodu, który jest wykonywany za każdym razem, gdy ktokolwiek wchodzi na Twoją stronę. To olbrzymie obciążenie dla serwera, co prawda można zwiększyć hosting na lepszy, ale trzeba będzie to robić ciągle – wraz ze wzrostem ruchu na stronie, co nie jest efektywne.

Znacznie lepiej jest zastosować mechanizmy cachujące po stronie serwera. Istnieje wiele rodzajów cache, jednak w dużej mierze wszystko sprowadza się do tego, że serwer produkuje strony dla użytkownika, zanim ten wejdzie na stronę i zapisuje je do statycznych plików HTML. Zaserwowanie jednego pliku HTML jest o wiele mniej zasobożerne, niż wykonywanie całej procedury za każdym razem. To jakby użyć kopiarki, zamiast ręcznie przepisywać treść tekstu na kartce A4. Ważne jest to, że zastosowanie cache znacznie przyspiesza stronę po stronie serwera, a to już połowa sukcesu.

Optymalizacja ładowania zasobów

Gdy serwer wyśle wszystkie dane do przeglądarki, ta musi je wczytać. Takie zasoby to przede wszystkim:

  • Pliki HTML, odpowiadający za treść strony;
  • Pliki CSS, czyli style odpowiadające za wygląd strony;
  • Pliki JS, odpowiadające za dodatkowe, dynamiczne funkcjonalności po stronie przeglądarki;
  • Pliki graficzne w przeróżnych formatach (JPG, PNG, SVG, itd)

W zależności od wielkości tych plików proces ich wczytywania może być szybki lub bardzo powolny. Zazwyczaj bardzo dużą rolę w szybkości ładowania strony mają pliki graficzne, które zajmują najwięcej danych. Grafiki należy optymalizować, stosując poniższe zasady:

  1. Pliki graficzne powinny być zawsze kompresowane, najlepiej do nowego formatu WEBP, który charakteryzuje się bardzo wysokim stosunkiem jakośći grafiki do jej rozmiaru.
  2. Rozmiary grafik powinny mieć wartości realnie używane. Używanie większych grafik i skalowanie ich w dół podczas procesu renderowania w przeglądarce to powszechny błąd.
  3. Grafiki powinny być ładowane za pomocą tzw. Lazy Load, czyli dosłownie chwilę przed tym, gdy mają pojawić się na ekranie podczas scrolowania. Nie ma sensu ładować wszystkich zdjęć od razu.
  4. Używaj szybkich serwerów do przechowywania plików statycznych – tzw CDN.

Optymalizacja procesu renderowania

Renderowanie to proces zamiany danych znajdujących się w plikach, na realny wygląd i funkcjonalności strony. Renderowanie odbywa się za każdym razem, gdy otwierasz nową podstronę lub odświeżasz istniejąca. Przeglądarka ładuje po kolei pliki, i wg instrukcji w nich zawarty buduje layout strony.

Najwięcej problemów wiąże się z priorytetyzacją kolejności ładowania. Z punktu widzenia użytkownika, najważniejsze jest, aby jak najszybciej załadować część strony, która jest widoczna na pierwszym ekranie (tzw. above the fold). Przeglądarka powinna renderować najpierw górną część strony, tak aby można było z niej korzystać. Dopiero później może zająć się renderowanie niewidocznych elementów, które zostaną zauważone dopiero po rozpoczęciu scrolowania.

Niestety, bardzo często jest tak, że strona renderuje wszystko w kolejności, w jakiej dostarczane są pliki. Nie zawsze jest to najlepsze rozwiązanie i należy doprowadzić do stanu, w którym najpierw ładowane są krytyczne style (CSS). A dopiero później całą reszta – najlepiej asynchronicznie.

W przypadku WordPress’a problem stanowią wtyczki, które dorzucają olbrzymią ilość plików CSS czy JS, które nie są potrzebne od razu. Blokują tym samym proces renderowania i spowalniają stronę, co będzie zaznaczane w narzędziach mierzących parametry Core Web Vitals.

Co zrobić, żeby maksymalnie przyspieszyć stronę pod tym kątem?

  1. Użyj łączenia i minifikacji CSS, która polega na połączeniu wielu plików w jeden i skompresowaniu go do wersji bez zbędnych spacji czy znaków.
  2. Podobny zabieg z kompresją i połączeniem można zrobić z plikami JS.
  3. Dobrze by było, aby krytyczne CSS były ładowane inline w sekcji <head> strony. Pozostałe pliki CSS i JS – albo asynchronicznie, albo na samym końcu kodu HTML.

Jak poprawić FID?

First Input Delay (FID) jest czynnikiem, którego nie da się zasymilować w testach laboratoryjnych, ponieważ, aby go sprawdzić, potrzebna jest reakcja prawdziwego użytkownika. W fazie wdrażania strony, Google zaleca na skupieniu się na innym czynniku, jakim jest TBT (total bloking time).

Głownem problemem zarówno z FID jak i TBT będzie zawsze Java Script, który jest uruchamiany i kompilwany podczas procesu renderowania. Takie operacje zawsze opóźniają proces ładowania strony, a w wielu przypadkach są zbędne na starcie.

Ładowanie dużych plików JS powoduje blokowanie przeglądarki, przez co strona czasami może nie działać prawidłowo – przyciski mogą nie działać, lub efekt kliknięcia w przycisk pojawia się z dużym opóźninieniem.

Co możesz zrobić, żeby poprawić FID?

  1. Wyłącz niepotrzebne skrypty JS lub ładuj je asynchronicznie po załadowaniu strony.
  2. Opóźnij ładowanie skryptów pochodzących z innych stron (Google Analytics, Google Tag Manager, HotJar, Call Page itp. ).
  3. Używaj funkcji Serwer-Side Rendering w stronach typu SPA (strony oparte na nowych technologiach takich jak Angular czy React).
  4. Usuń nieużywane pliki JS lub nawet pojedyncze fragmenty kodu, które nie są używane na danej podstronie.

Jak poprawić CLS?

CLS sprawdza stabilność strony przez obliczanie przesunięć elementów podczas ładowania. Rozwiązaniem problemu z CLS jest proste. Problem najczęściej powodują grafiki, które doładowując się, zmieniają pozycje elementów poniżej nich.

Rozwiązanie tego problemu jest dość proste. Wystarczy nadać predefiniowaną wysokość i szerokość danego elementu za pomocą odpowiednich atrybutów. W Przypadku grafiki, będzie to wyglądało w następujący sposób:

<img src="obrazek.webp" width="640" height="360" alt="Tekst alternatywny grafiki" />

Jeśli chcesz zadbać o responsywanść grafiki i ładować różne jej rozmiary w zależności od szerokości ekranu wystarczy posłużyć się atrybutem media, jak w poniższym przykładzie:

<picture>
  <source media="(max-width: 799px)" srcset="obrazek-480w-cropped.webp" />
  <source media="(min-width: 800px)" srcset="obrazek-800w.webp" />
  <img src="obrazek-800w.webp" alt="Tekst alternatywny grafiki" />
</picture>

W przypadku pozostałych elementów (reklamy, ramki), możesz skorzystać z tzw. placeholderów, czyli kontenerów, które zajmują wysokość szerokość ładującego się obiektu. Dzięki temu layout zawiera np. pusty prostokąt, w którym za chwilę pojawi się reklama.

W jakim stopniu Core Web Vitals wpływają na ocenę szybkości strony przez Google?

Wiesz już, że Core Web Vitals są składową do oceny szybkości strony. Nie są to jedyne parametry, jakie Google bada podczas sprawdzania web performance. Możesz jednak w łatwy sposób sprawdzić, jak ważne są dane elementy w ogólnej ocenie. Google udostępnia specjalne narzędzie zwane Lighthouse Scoring Calculator, które pokaże Ci wagi poszczególnych elementów składowych podczas obliczania oceny strony.

https://googlechrome.github.io/lighthouse/scorecalc/

Podsumowanie

Core Web Vitals to dość ważna kwestia związana z obecnością Twojej firmy w internecie. Szybko i sprawnie działająca strona to więcej zadowolonych użytkowników, a co za tym idzie – więcej klientów. Google zmusza nas do coraz lepszych optymalizacji stron pod kątem szybkości i robi to z dbałości o swoich użytkowników. Niemniej jednak, w kontekście zmian, które nadchodzą, nie spodziewałbym się, aby wprowadzenie Core Web Vitals do algorytmu Google znacząco wpłynęło na obraz wyników wyszukiwania.