Core Web Vitals

Spis treści

Czytasz teraz:

Core Web Vitals

• Core Web Vitals – jakość strony na pierwszym miejscu
  • Podstawowe Wskaźniki Internetowe – przyjrzyjmy im się bliżej
  • LCP – Largest Contentful Paint – Największe wyrenderowanie treści
  • FID – First Input Delay – Opóźnienie przy pierwszym działaniu
  • CLS – Cumulative Layouts Shift – Skumulowane Przesunięcie Układu
  • Podstawowe Wskaźniki Internetowe – UX ma znaczenie!

Zamknij

Internet nieustannie się zmienia. Strony internetowe z jego początków ledwo przypominają te, które towarzyszą nam dzisiaj. Zmienił się nie tylko ich wygląd, forma podania informacji, ale również i nasze oczekiwania. Wśród różnic wymienić można również sposób oceny witryny – dzisiaj nie wystarczy już, że po prostu JEST. W tym kontekście musimy zastanowić się, czym są Core Web Vitals i co nam właściwie mówią.

Core Web Vitals – jakość strony na pierwszym miejscu

Google od dłuższego czasu kładzie duży nacisk na szybkość i czytelność prezentowanych treści. Jednym z pierwszych elementów tych zmian z pewnością był zwrot w stronę użytkowników urządzeń mobilnych (znany także pod nazwą “Mobilegeddon”), który w 2015 zelektryzował pozycjonerów i twórców stron. Kolejne to m.in. konieczność zadbania o bezpieczeństwo witryny i jej użytkowników, czy też SSL. Teraz zwraca się w stronę doświadczeń użytkownika.

W maju 2021 roku jakość strony stanie się częścią algorytmu Google i będzie miała wpływ na umiejscowienie witryny w rankingu wyszukiwarki. Jak podają oficjalne źródła, jakość strony nie będzie miała znaczenia większego niż treść, jednak pozwoli na promowanie witryn, które przekazują je w sposób dostosowany do potrzeb użytkownika. 

Jakość strony internetowej będzie analizowana pod kątem kilku wspomnianych wcześniej czynników:

(Dalszą część artykułu znajdziesz pod formularzem)

• dostosowanie do urządzeń mobilnych (mobile-first indexing dla wszystkich stron od marca 2021);
• bezpieczeństwo przeglądania – brak treści szkodliwych i wprowadzających błąd, t.j. złośliwego oprogramowania oraz elementów pozwalających na wyłudzanie informacji;
• HTTPS;
• brak reklam pełnoekranowych, które uniemożliwiają dostęp do treści witryn.

Do tego dochodzi też Core Web Vitals, po polsku określane jako Podstawowe Wskaźniki Internetowe. Wskaźniki mają pomóc w zbadaniu doświadczeń użytkownika w zakresie wczytywania się strony i jej dostępności w trakcie i po wyrenderowaniu.

Google zaznacza, że prace nad sposobem badania jakości strony będą kontynuowane. W kolejnych latach lista czynników branych pod uwagę z pewnością ulegnie zmianie i zostanie rozbudowana o kolejne punkty. O zmianach będziemy informowani wcześniej, wyszukiwarka da nam również czas na przystosowanie swoich witryn do nowych wymogów.

Podstawowe Wskaźniki Internetowe – przyjrzyjmy im się bliżej

Jednym z bardziej kontrowersyjnych seo-tematów jest prędkość witryny. Na grupach specjalistycznych nie raz i nie dwa byliśmy świadkami długich dyskusji na temat tego jak wysoki wynik w PageSpeed Insights poprawia pozycję strony. Prawdą jest, że ocena witryny w narzędziu nie przekłada się bezpośrednio na pozycję w wyszukiwarce. Wiadomo jednak, że witryna, która nie ma problemów z prawidłowym wyświetlaniem treści nawet przy słabszym połączeniu internetowym, spotka się z cieplejszym przyjęciem przez użytkowników. To z kolei przełoży się na długość wizyty, chęć do dzielenia się linkiem oraz szansą na osiągnięcie wyznaczonej przez nas konwersji.

Badania prowadzone przez narzędzia, o którym wspomniałam w artykule o prędkości strony sprawdzają konkretne elementy witryny, nie dają jednak pełnej informacji na temat doświadczeń mniej zero-jedynkowego użytkownika. Ich analiza jest konieczna, jednak skupia się na innych aspektach serwisu niż Podstawowe Wskaźniki Internetowe. 

Core Web Vitals pozwalają na określenie doświadczeń, jakie stają się udziałem użytkownika naszej witryny. Dane pozwalające określić poziom jakości witryny zbierane są na podstawie rzeczywistych wizyt na stronie. Dzięki temu, zachowanie serwisu badane jest na szerokim przekroju przypadków – różnej prędkości połączenia sieciowego, rozmiarów i technologicznych możliwości urządzeń. 

Core Web Vitals w aktualnej odsłonie skupiają się na trzech elementach:

• największe wyrenderowanie treści,
• opóźnienie przy pierwszym działaniu,
• zbiorcze przesunięcie układu.

Jak wspomniałam już wcześniej, Google planuje rozbudowywać analizę jakości strony i możemy się spodziewać, że w kolejnych latach ta lista ulegnie rozbudowie. Google nie wyklucza też modyfikacji aktualnych wskaźników, np. rozszerzenie zakresu badań. 

LCP – Largest Contentful Paint – Największe wyrenderowanie treści

LCP określa czas wyrenderowania się największego fragmentu strony widocznej w oknie przeglądarki (wszystko co widzimy przed scrollowaniem). Elementy które są brane pod uwagę to:

• grafiki,
• wideo,
• element zawierający grafikę w tle, pobieraną z pomocą funkcji url(…) umieszczonej w CSS-ie,
• elementy blokowe (np.<p>, <div>, <ul>, <ol>, <hx>, itp.).

Jeżeli zawartość poszczególnych tagów rozciąga się poniżej linii scrollowania, te fragmenty nie są brane pod uwagę podczas analizy. W przypadku grafik, analiza oparta jest na podstawie najmniejszego rozmiaru osiąganego przez element. Jeśli podczas renderowania grafika jest zmniejszana w stosunku do określonych w tagu wartości, to jej wyrenderowany rozmiar będzie kluczowy dla analizy. Gdy grafika będzie rozciągana, rozmiar próbki pobranej do badania będzie zależny od wartości określonych w CSS-ie. 

Skąd wiadomo, który element jest największy? Strony internetowe renderują się etapami, a kod HTML rozczytywany jest zgodnie z kolejnością – od pierwszej linijki do ostatniej. W związku z tym, w trakcie renderowania się witryny, obiekt oznaczony jako “największy” będzie się zmieniać. Dany fragment strony określany jest jako “największe wyrenderowanie treści” dopiero w momencie, w którym wczyta się całkowicie. Uwaga – jeśli w trakcie renderowania strony użytkownik przesunie ekran, dalsze zmiany w zakresie “largest contentful paint” nie będą brane pod uwagę. 

A co z elementami, które ładują się poza ekranem i dopiero później pojawiają się w obrębie widoku użytkownika? W większości przypadków te fragmenty nie będą raportowane. W odwrotnej sytuacji – gdy renderują się w obrębie viewportu i zostaną zepchnięte poniżej linii scrollowania, wciąż będą brane pod uwagę i mogą być uwzględnione w końcowym wyniku.

Największe Wyrenderowanie Treści  – wynik

Na grafice powyżej zaznaczona jest granica optymalnego wyniku LCP – 2,5 sekundy od startu renderowania witryny. Powyżej tego czasu – aż do granicy 4 sekund, wynik rozpatrywany jest jako “wymaga pracy” a powyżej 4 sekund – jako słaby. 

W PageSpeed Insight wartości podawane są na dwa sposoby:

• w procentach, zebrane na podstawie danych zebranych od użytkowników  z ostatnich 28 dni. W 39% procentach LCP było na poziomie zadowalającym:

• w sekundach, na podstawie badań przeprowadzonych podczas symulacji wczytywania strony:

Poniżej znajduje się również informacja odnośnie tego, który element został uznany za “największy”:

PageSpeed Insights analizuje dane dotyczące wskazanego adresu. W celu uzyskania bardziej szczegółowych informacji o stronach w obrębie całej domeny, warto zajrzeć do Google Search Console i jednej z najnowszych zakładek, oznaczonej jako “Podstawowe Wskaźniki Internetowe”. Dostępne są tam dwa raporty, odnoszące się strony wyświetlanej na urządzeniach mobilnych oraz na komputerach.

Raport w GSC zawiera listę stron na których występuje problem ze słabymi wynikami LCP. W sytuacji, gdy narzędzie zidentyfikowało ten sam problem na wielu podstronach – w tabelce podany jest jeden adres i adnotacja o ilości stron, na których błąd się powtarza. Dokładne adresy dostępne są w rozszerzonym widoku, dostępnym po kliknięciu na rekord.

Słaby wynik LCP – skuteczne sposoby na poprawę

Kluczem do dobrego wyniku LCP jest optymalizacja punktów, które spowalniają działanie strony. Wolny serwer, konieczność wykonania się kodu JS i CSS, która blokuje dalsze renderowanie witryny oraz renderowanie po stronie klienta, o którym więcej pisałam w artykule “Pozycjonowanie stron a JavaScript” – to najczęstsze przyczyny słabych wyników. Przyjrzyjmy się remedium na najpopularniejsze problemy:

• powolna odpowiedź serwera – kluczową wartością będzie tu TTFB – Time To First Byte (czas od wysłania zapytania do otrzymania pierwszego bajtu odpowiedzi). Powolna odpowiedź jest raportowana m.in. w PageSpeed Insights, można ją również sprawdzić za pomocą innych narzędzi analizujących prędkość witryny. 

Podstawowym sposobem na poprawienie wyniku TTFB jest optymalizacja serwera i eliminacja procesów, które pogarszają jego wydajność. W tym celu warto przyjrzeć się poradom Twojego dostawcy hostingu lub skorzystać z pomocy specjalisty;

• blokowanie renderowania przez JavaScript i CSS – tutaj sprawdzą się tricki, które zalecane są podczas każdej optymalizacji prędkości witryny – minifikacja CSS, usunięcie nieużywanych fragmentów oraz rozważenie asynchronicznego ładowania plików styli. W zakresie JavaSript optymalizacja będzie wyglądać podobnie – minifikacja plików JS i usunięcie nieużywanych fragmentów;

Na poprawę wyniku LCP może mieć wpływ również optymalizacja innych elementów, np. kompresja grafik, korzystanie z CDN oraz priorytetyzacja wczytywania niektórych zasobów.  

FID – First Input Delay – Opóźnienie przy pierwszym działaniu

FID odnosi się do interaktywności witryny – określa czas upływający między pierwszą akcją wykonaną przez użytkownika a chwilą, w której przeglądarka rozpoczyna obsługę tej akcji. Pod uwagę brane są kliknięcia (w przypadku mobile – tapnięcia) oraz przyciśnięcie przycisków. Wynik FID skupia się na analizie czasu reakcji, nie bada jednak czasu przetwarzania zdarzenia zapoczątkowanego przez użytkownika. 

Opóźnienie przy pierwszym działaniu nie zawsze będzie mierzone – niektórzy użytkownicy nie decydują się na interakcję ze stroną w czasie jej wczytywania się. Co ciekawe, w przypadku tego wskaźnika analiza odbywa się tylko w trakcie faktycznego korzystania ze strony – podobne badania nie są przeprowadzane w czasie symulacji wykonywanej przez Lighthouse.

Każdy internauta z pewnością zetknął się z sytuacją, w której po wejściu na serwis od razu chciał przejść w kolejne miejsce. Kliknięcie na link lub rozwinięcie dalszej części tekstu, nie było jednak możliwe od razu – reakcja witryny na nasz ruch była znacznie opóźniona. Dlaczego tak się dzieje? W trakcie renderowania witryny, przeglądarka jest zajęta obsługą plików składających się na stronę. Dopiero po zakończeniu tego procesu jest w stanie reagować na zachowanie użytkownika. Czas oczekiwania na interaktywność strony przekłada się bezpośrednio na wystawienie subiektywnej oceny przez użytkownika i określenie jej jako “wolnej” lub “szybkiej”. 

Opisując LCP wspomniałam o tym, że HTML wczytuje się linijka po linijce – dlaczego zatem nie ma możliwości by wczytane fragmenty były aktywne wcześniej? Niektóre tagi – np. <input>, <a> czy <select> wymagają zamknięcia renderowania głównego wątku. Jeśli chodzi o inne przeszkody – w sekcji <head> pliku .html zazwyczaj umieszczone są linki do zasobów CSS i JS, które przeglądarka musi sparsować zanim przejdzie do dalszego renderowania strony. Stąd też wcześniejsze sugestie minifikacji tych plików (tj. m.in. usunięcia białych znaków) oraz przenoszenie do dalszej części kodu fragmentów zbędnych do renderowania pierwszego widoku. W przypadku wydarzeń, które są rejestrowane przez “event listenery” umieszczone w JS, ich działanie jest możliwe dopiero po wykonaniu się całego kodu. 

Opóźnienie przy pierwszym działaniu – wynik

Jak wskazane na grafice powyżej, zadowalający wynik plasuje się w przedziale 0-100ms. Powyżej tego czasu warto wprowadzić poprawki, a powyżej 300 ms – trzeba.

Informacje z PageSpeed Insight oparte są na danych od użytkowników – w tym przypadku 82% przypadków osiąga zadowalające wyniki.

Bardziej szczegółowe dane, wraz z danymi o konkretnych adresach wymagających poprawy, zawarte są w zakładce “Podstawowe Wskaźniki Internetowe” w Google Search Console.

Słaby wynik FID – skuteczne sposoby na poprawę

W sytuacji idealnej narzędzia informowałyby o 95-99% “zielonych odpowiedzi”. Jeżeli nasze aktualne wyniki nie są jeszcze tak wysokie, wprowadzenie zmian w obrębie witryny z pewnością wyjdzie im na dobre. 

Podobnie jak w przypadku LCP, przede wszystkim zaleca się optymalizację kodu niezbędnego do wczytania się kluczowych elementów witryny i przeniesienia fragmentów z niższym priorytetem do dalszej części pliku. Warto również usunąć niewykorzystywane fragmenty oraz przeprowadzić minifikację.

Głównym powodem niskich wyników FID jest zazwyczaj kod JS. Optymalizacja plików i rozbicie poszczególnych fragmentów na mniejsze, asynchronicznie wykonywane partie, powinno znacznie przyśpieszyć proces renderowania i ograniczyć blokowanie zasobów. 

Na prędkość odpowiedzi przeglądarki będzie miał również wpływ kod pochodzący spoza strony – ograniczenie go zmniejszy liczbę procesów wykonywanych przez przeglądarkę. 

CLS – Cumulative Layouts Shift – Skumulowane Przesunięcie Układu

Wynik CLS to suma zmian powstałych na skutek nieoczekiwanego przesunięcia układu strony. Zmiana liczy się w momencie, gdy element zmieni pozycję, na której się znajdował w chwili renderowania. Do CLS nie zalicza się nowych elementów pojawiających się na stronie ani zmiany rozmiaru już istniejących – tak długo, jak nie powodują przesunięcia innych składników strony. W przeciwieństwie do wyszczególnionych wyżej wskaźników, CLS zbiera dane podczas całej wizyty w obrębie strony, a nie w pierwszych chwilach jej renderowania.

Przeskoki w layoucie strony powstają m.in. na skutek asynchronicznego ładowania zasobów lub poprzez dynamiczne dodawanie kolejnych elementów do struktury DOM. Tego typu sytuacje są zauważalne np. podczas korzystania ze stron na których doładowywane są grafiki bez zadeklarowanej wielkości – dopasowanie odpowiedniej wielkości do rozmiaru ekranu może powodować nagłą zmianę w wyglądzie strony, która powoduje przeniesienie użytkownika w jej inny fragment.

Problematyczne mogą być tu też zasoby pobierane z zewnętrznych źródeł, zbudowane w oparciu o inne wartości niż docelowa strona oraz spersonalizowany content, generujący się bez odpowiedniego sformatowania. Niespodziewane przesunięcie może być również spowodowane wydłużonym renderowaniem fontów.

Nie każde przesunięcie jest złe, zależnie od designu strony, niektóre akcje użytkownika będą powodować zmiany w stosunku do pierwotnego rozkładu elementów. Ważne, żeby tego typu przesunięcie miało bezpośrednie powiązanie z wykonaną akcją.

CLS oparty jest na danych zebranych od użytkowników i pozwala określić faktyczne doświadczenia na stronie, które nie zawsze są dostępne w warunkach, w jakich pracuje deweloper strony. 

Skumulowane Przesunięcie Układu – wynik

Dobry wynik CLS mieści się w przedziale 0-0.1. Wynik powyżej 0.25 oznacza konieczność wprowadzenia zmian i poprawienia wrażeń jej użytkowników. Przyjmuje się, że witryna jest stabilna, gdy minimum 75% użytkowników otrzymuje wynik poniżej 0.1.

Dane na temat przesunięcia znaleźć możemy w PageSpeed Insights:

Wynik procentowy oparty jest na analizie danych użytkowników – w tym przypadku 90% osiąga dobry wynik. 

PSI dostarcza również informacji zebranych w warunkach laboratoryjnych:

Szczegółowe informacje na temat większej ilości podstron ponownie możemy czerpać z Google Search Console.

Słaby wynik CLS – skuteczne sposoby na poprawę

Lepszy wynik CLS można osiągnąć poprzez trzymanie się ogólnych standardów budowania stron internetowych. Znaczącą rolę odgrywa tu zwłaszcza dokładne opisanie grafik i video – dodanie do nich atrybutów związanych z wielkością elementu (width, height i powiązanego z nimi aspect ratio) ułatwia przeglądarce prawidłowe rozłożenie elementów podczas renderowania, bez konieczności zmian w trakcie wczytywania się kolejnych fragmentów contentu. W przypadku grafik dodawanych dynamiczne, zalecane jest stosowanie placeholderów, które rezerwują miejsce przeznaczone na dodany później element.

Od jakiegoś czasu PageSpeed Insights zaleca korzystanie z cssowego font-display, które odpowiada za zachowanie czcionki na stronie. Inną możliwością jest też wcześniejsze załadowanie fontu z pomocą atrybutu preload umieszczonego w elemencie <link>. Preload powoduje ściągnięcie wskazanych zasobów przed startem renderowania strony. Dzięki temu, w dalszej części wyświetlania strony, eliminowany jest problem przestojów i oczekiwania na załadowanie się wszystkich plików z pierwszej części kolejki.

Podstawowe Wskaźniki Internetowe – UX ma znaczenie!

Jeśli przyjrzeć się rozwiązaniom, które będa miały pozytywny wpływ na wynik poszczególnych wskaźników, łatwo można zauważyć, że nie są nowością. Wiele z nich Google zalecał już podczas pierwszych wersji PageSpeed Insights. Wskaźniki i ich wejście w skład algorytmu wyszukiwarki są jednak dobrym powodem, by przyjrzeć się bliżej swoim witrynom i faktycznie wprowadzić zmiany, które ułatwią korzystanie z serwisów. Ma to wpływ zarówno na pozycjonowanie w sieci i wyższą pozycję w wyszukiwarkach, jak i na komfort korzystania z serwisu przez użytkowników.