Cove Web Vitals, czyli nowy wskaźnik rankingowy Google. Został ogłoszony w połowie 2020 roku i prawdopodobnym jest, że za jego sprawą wyniki wyszukiwania zadrżą*, jak w 2012 roku, kiedy Google wprowadził algorytm Pingwin, usuwając tym samym spam z sieci. Czemu do tego nawiązuję? Ponieważ Core Web Vitals jako czynnik rankingowy doceniają dobrej jakości strony: szybkie, wydajne, bezpieczne i stabilne, a karać będą spadkami te, które są niezoptymalizowane technicznie, o niesprzyjającym UX oraz przeładowane zbędnym kodem i utrzymywane na wolnych niestabilnych hostingach.

*Doprecyzowując, chodzi o duże serwisy lub strony skrajnie niezoptymalizowane. Prawdopodobnie typowa strona o site:100 zbudowana na WordPress o wynikach Page Speed typu 60:80 nie odczuje żadnej zmiany.

Myślę, że to właściwy moment, aby zastanowić się, gdzie utrzymywana jest własna domena oraz serwer (zostało to szczegółowo wyjaśnione we wpisie Jak sprawdzić gdzie i na kogo zarejestrowana jest domena). Dlaczego? Ponieważ “wpadka” z niezapłaconą fakturą jest dość powszechna. Skutkuje to wyłączeniem strony i w efekcie gwałtownymi spadkami, jak powiedziałem wcześniej – dla algorytmów Google stabilność jest jednym z najważniejszych czynników rankingowych.

 

wskazniki core web vitals lcp fid cls

Wskaźniki Core Web Vitals

 

 

Spis treści:

 

 

Core Web Vitals – co to jest?

Core Web Vitals to w dużej mierze zestaw wskaźników:

  • Wczytywanie: Largest Contentful Paint (LCP)
  • Interaktywność: First Input Delay (FID)
  • Stabilność wizualna: Cumulative Layout Shift (CLS)

Wracając jeszcze do pytania co to jest CWV? Są to czynniki, które łączą w sobie wrażenia użytkowników, właściwe i optymalne techniki tworzenia stron internetowych, ale także zwiększają komfort przeglądania witryn, poprzez karanie za nachalne reklamy lub “uciekające” treści. Dążenie do wdrożenia Core Web Vitals nie powinno być zaskoczeniem, od lat w branży SEO mówi się o mobile friendly, co w szerszym znaczeniu nie oznacza tylko responsywności, ale również używania optymalnych technik minimalizujących czas ładowania i oszczędzających transfer. Dlaczego?

Internet w telefonie obecnie jest szybki, moc obliczeniowa również nie należy do najniższych, jednak nie należy zapominać o jednym bardzo ważnym aspekcie, który jest drugą stronę medalu wdrażania CWV… otóż Crawl Budget 🙂 Zastanawiacie się pewnie, co ma jedno z drugim wspólnego? Już wyjaśniam. Należy wyjść z perspektywy jednostki i spojrzeć na sieć w sposób globalny ( 2 stycznia 2021 r. było ponad 1.83 miliarda stron internetowych). To w łatwy sposób pozwoli nam zrozumieć zależność, że szybka i zoptymalizowana strona to ukłon dla użytkowników, jednak na swój sposób Google takim rozwiązaniem zmierza do odciążenia swoich serwerowni, które w ciągu dnia przetwarzają miliardy danych. Zakładając, że 10% sieci zoptymalizuje swoje strony pod wytyczne – oszczędności dla Google będą astronomiczne. Nie należy zapominać, że wskaźniki CWV dostępne są w Google Search Console.

 

zestawienie search page experience

Search Page Experience – zestawienie

 

 

Largest Contentful Paint (LCP) – kluczowe 2,5 sekundy – wskaźniki Core Web Vital

LCP, czyli wczytywanie największego elementu witryny. Wskaźnik wydaje się być oczywisty, włączamy stronę, czekamy na jej załadowanie – najlepiej ze stoperem 😉 i proszę mamy zmierzony czas ładowania 🙂 Otóż nie, to nie jest takie proste. Strona to nie tylko jest front end, to również różne skrypty (np. biblioteki JavaScript lub jQuery), które często w niewidoczny sposób opóźniają pełne załadowanie strony. Należy też zwrócić uwagę na strony wykorzystujące infinite scroll. Ciężko tu mówić o pełnym załadowaniu witryny.

W praktyce LCP mierzy czas do załadowania największego elementu witryny. Może to być grafika, film tekst itp. Kluczowe są tutaj pierwsze 2,5 sekundy, w tym czasie witryna powinna osiągnąć gotowość do odbioru przez usera, bez “skakania” elementów. Powody, czemu tak jest, są wymienione powyżej, jednak warto tutaj nadmienić, że to tylko najbardziej prawdopodobne warianty.

 

largest contentful paint czynniki core web vitals

Largest Contentful Paint – czynniki Core Web Vitals

 

Pewnie wiele osób wpadnie na pomysł – zakup lepszego hostingu, zamiast wdrażać drogą optymalizację techniczną lub zlecić wykonanie nowej strony internetowej. Czy takie rozwiązanie się sprawdzi? Prawdopodobnie nie, jednak na moment pisania tego artykułu, nie przeprowadzaliśmy jeszcze jednoznacznych testów. Z dużą dozą pewności stwierdzam, że takie działanie może przynieść wymierne efekty w postaci kilku oczek w górę, jednak jeżeli skrypty ładowane są z zewnątrz, z przeciążonymi bibliotekami – niewiele da szybki serwer, ponieważ w grę wchodzi czynnik zewnętrzny. Porównując to trochę na język rzeczy, którymi się otaczamy „wsadzenie do Porsche silnika z Malucha, nie spowoduje, że to Porsche będzie szybkie, mimo aerodynamicznego kształtu”. Szczególną uwagę należy zwrócić na implementowanie całych rozbudowanych bibliotek tylko po to, aby zrobić slider lub klikalną (powiększającą się) grafikę lub w przypadku WordPress wdrożeniu 20 lub więcej wtyczek.

 

Wpływ serwera/hostingu na LCP

W części dotyczącej bezpośrednio LCP napisałem, że lepszy serwer nie uratuje fatalnej witryny i to podtrzymuję z pełną odpowiedzialnością, jednak zdarzają się szczególne przypadki, gdzie zmiana serwera na inny w dużej mierze załatwi sprawę. Pewnie pomyślicie – jak to? Dotyczy to przede wszystkim stron, których optymalizacja techniczna została poprawnie wykonana, jednak efekty nadal nie są satysfakcjonujące. W takim przypadku należy się pochylić ku technicznym rozwiązaniom serwerowym i odpowiedzieć sobie na pytanie: korzystam ze współdzielonego hostingu czy mam własny serwer? Prawdopodobnie odpowiedź to: współdzielony hosting. Dochodzimy tym do sedna sprawy. Jeżeli w ramach jednego serwera ktoś wykorzystuje intensywnie swoją usługę, rozsyła spam itd. to, po pierwsze bardzo obciąża serwer, po drugie prowokuje Google do nałożenia kary na adres IP, a to już krótka droga do bardzo gwałtownych spadków. Optymalnym rozwiązaniem jest korzystanie z własnych serwerów dedykowanych, jednak to niesie duże koszty – zakupu jak i utrzymania.

 

dobry serwer cechy dobrego hostingu

Cechy dobrego hostingu

 

Przede wszystkim należy wybrać hosting, z “którym jest kontakt”, a także mieć pewność popartą licznymi opiniami, że poradzi sobie z problemami technicznymi oraz co najważniejsze, zniweluje ataki hakerskie typu DDOS. Obecnie hostingodawcy robią częste backupy danych swoich klientów, oraz posiadają narzędzia przyspieszające wczytywanie danych typu LiteSpeed czy REDIS w WordPress, a także protokół HTTP/2, które potrafią widocznie przyspieszać działanie stron www.

 

atak typu ddos

Atak typu DDOS

 

Jak optymalizować LCP:

  • pełna optymalizacja grafik, używanie nowoczesnych i zalecanych formatów typu webp
  • optymalizacja czasu odpowiedzi serwera
  • optymalizacja i minifikacja stylów CSS oraz kodu JS

 

 

First Input Delay (FID) – akcja reakcja – wskaźniki Core Web Vital

First Input Delay, czyli opóźnienie pierwszego wejścia. W praktyce oznacza to czas potrzebny na reakcję strony po wykonaniu interakcji przez użytkownika np. kliknięcie URL. Mierzony jest tu czas od interakcji do pełnego załadowania strony.

 

first input delay czynniki core web vitals

First Input Delay – czynniki Core Web Vitals

 

Jak mierzyć FID:

  • Dobry wynik FID to czas mniejszy bądź równy niż 100ms
  • Wynik FID wymagający poprawy: 101-300ms
  • Wynik zły wymagający pilnej naprawy: powyżej 300ms

Z danych Google wynika, że na niski wynik FID wpływa źle zoptymalizowany i przeładowany kod JavaScript. W dużej mierze dotyczy to rozwiązań gotowych, gdzie do implementacji jednego rozwiązania stosuje się całą bibliotekę. Przeglądarka blokowana jest analizą kodu JavaScript, wskutek czego występuje opóźnienia w reakcji na zachowania użytkownika

Więcej informacji dostępnych tutaj.

 

Jak optymalizować FID:

  • podzielenie kodu na mniejsze działania, szczególnie kodu JavaScript
  • wykorzystanie asynchroniczności
  • ustalenie i wdrożenie priorytetów kolejności ładowania treści
  • przeniesienie działań niezwiązanych z interfejsem poza wątek główny

 

 

Cumulative Layout Shift (CLS) – stabilność wizualna – wskaźniki Core Web Vital

Cumulative Layout Shift – skumulowane przesunięcie układu. CLS to jeden z ciekawszych elementów CWV zorientowanym na użytkownika. Wskaźnik ten określa, w jakim stopniu szablon strony przesunął się na ekranie z powodu niespodziewanych zdarzeń i zachowań. Chodzi tu o przesunięcia niezwiązane z interakcją użytkownika, czyli te, które są efektem problemów programistycznych.
Często określenie tego, co powoduje problemy na stronie z przesunięciem, możliwe jest już po samym odświeżeniu strony. Dokładniejsza analiza możliwa jest z wykorzystaniem narzędzi do debugowania strony.

 

cumulative layout shift czynniki core web vitals

Cumulative Layout Shift – czynniki Core Web Vitals

 

CLS oceniane są w skali:

Ocena mniejsza bądź równa 0.1 jest oceną dobrą, powyżej 0.25 – złą.

 

widok cls w panelu google search console

Widok CLS w panelu Google Search Console

 

Najczęstsze przyczyny problemów z CLS:

  • przemieszczające się reklamy, które ciężko wyłączyć,
  • obrazy bez wymiarów (width; height) – częsty konflikt programistyczny, ponieważ w obecnych standardach Responsive Web Design(RWD) siatki dopasowywane są procentowo, a same obrazy mają wypełniać element <div>, który ma wyznaczony rozmiar w media queries lub np. w siatce Bootstrap. W mojej opinii jest to krok w tył,Google preferuje liniowo podane rozmiary, ponieważ nie musi analizować samego obraza i kodu CSS – ma podane wszystko ‘na tacy’,
  • treści dynamiczne, generowane za pomocą kodu JavaScript

 

Jak optymalizować CLS:

  • unikać stylów inline
  • jeżeli Twój serwis zawiera reklamy – przenieś je z góry strony na środek lub dół witryny
  • elementy iframe osadzaj w divach lub sekcjach o określonych wymiarach
  • stosowanie zdjęć o określonych w kodzie wymiarach

 

 

Symulator Core Web Vitals – Lighthouse Scoring Calculator

Pod tym adresem dostępne jest narzędzie Lighthouse Scoring Calculator, które umożliwia symulację danych związanych z szybkością page speed oraz CWV.

 

lighthouse scoring calculator

Lighthouse Scoring Calculator

 

 

PageSpeed Insight – dane pomiarowe

PageSpeed Insight mierzy poniższe dane.

 

pagespeed insight dane pomiarowe

PageSpeed Insight – dane pomiarowe

 

First Contentful Paint (Pierwsze wyrenderowanie treści) – FCP

FCP mierzy czas, jaki potrzebuje przeglądarka na wyświetlenie pierwszego fragmentu treści DOM po wejściu użytkownika na daną stronę. Pierwsze wyrenderowanie treści zawiera:

  • czas odpowiedzi serwera(TTFB)
  • czas ładowania treści oraz czas renderowania

 

Speed Index (Indeks szybkości)

Speed Index służy do pomiarów wyświetlania zawartości strony w procesie jej ładowania. Lighthouse rejestruje wideo z ładowaniem witryny i oblicza postęp między ramkami.

 

Możliwość poprawy Speed Index

  • optymalizacja kodu JavaScript
  • zoptymalizowanie grafik i wyświetlanie w trybie “lazy loading”
  • wykorzystanie cache

 

Time to Interactive (Czas do pełnej interaktywności) (TTI)

Jest to czas potrzebny na załadowanie strony na tyle, aby użytkownik mógł korzystać ze strony i wchodzić w interakcję z jej widocznymi elementami.

 

Total Blocking Time (Łączny czas zablokowania) – TBT

Jest to łączny czas blokowania ładowanych zasobów, został wycofany i zastąpiony FID.

 

Time to first byte (TTFB)

Time to first byte jest wartością podawaną w mikrosekundach, docelowo miał wskazywać tzw. wąskie gardło w procesie ładowania strony. TTFB mierzy czas od momentu wysłania zapytania do serwera, aż do chwili otrzymania pierwszych bajtów danych. W praktyce jest to jeden z popularniejszych sposobów mierzenia prędkości ładowania strony, niestety zawiera on kilka niuansów, które mogą znacznie spowolnić ten proces i nie być winą samego serwera, a błędnej architektury aplikacji/strony. TTFB z całą pewnością nie jest odpowiednim sposobem mierzenia wydajności serwera, zdecydowanie bardziej wpisuje się jako narzędzie do pomiaru optymalizacji strony.

 

Możliwości poprawy TTFB

  • optymalizacja i skrócenie reakcji serwera (TTFB)
  • optymalizacja architektury strony
  • wdrożenie CDN
  • unikanie wielokrotnych przekierowań

 

 

Narzędzia do mierzenia CWV oraz szybkości wczytywania strony www

  • Google PageSpeed Insights – wystarczy wkleić adres URL strony i kliknąć ANALIZUJ, aby otrzymać wykres szybkości strony i problemów technicznych związanych z niewłaściwą optymalizacją kodu.
  • Test My Site z Think with Google – narzędzie służy do analizy szybkości strona na urządzeniach mobilnych. Wystarczy wkleić link i kliknąć enter. Ciekawą funkcjonalnością jest możliwość porównania szybkości wczytywania naszej witryny z witryną konkurencji
  • web.dev narzędzie bardzo podobne do Page Speed oraz Lighthouse. Sprawdzany jest czas interakcji, odpowiedzi serwera oraz: ‘Performance’, ‘Accessibility’, ‘Best Practices’ oraz ‘SEO’.Web.Dev podpowiada również jak przyspieszyć wczytywanie witryny
  • Lighthouse – działa w przeglądarce Chrome (PPM -> Zbadaj -> Lighthouse. W celu skorzystania z tego narzędzia trzeba wejść na stronę, którą chcemy zbadać.
  • Google Analytics -> Raport “Szybkość wczytywania strony”
  • WebPage Test – pozwala wybrać lokalizację oraz typ przeglądarki, z jakiej chcemy przeprowadzić testy
  • Pingdom Website Speed Test – przejrzyste narzędzie wskazujące czas ładowania, blokowanie, odpowiedź DNS oraz dające możliwość wyboru lokalizacji.
  • Load Impact – pozwala sprawdzić szybkość witryny w zależności od ilości użytkowników odwiedzających witrynę
  • GTMetrix – niezwykle funkcjonalne narzędzie do wykonywania istotnych analiz. Plusem jest wykonywanie raportów PDF
  • DotCom – wykonuje pomiary dla różnych lokalizacji
  • Super! Monitoring – łączy w sobie dane z Page Speed oraz Lighthouse
  • Sucuri Load Time Tester – przedstawia informacje na temat szybkości połączenia oraz pobrania pierwszego bajtu danych. Umożliwia pomiar z różnych lokalizacji
  • Website Speed Test Uptrends – przedstawia informacje o ogólnym czasie wczytywania strony

 

 

Page Speed Inside – typowe komunikaty

  1. Usuń nieużywany kod CSS
  2. Minifikuj CSS
  3. Odłóż ładowanie obrazów poza ekranem
  4. Wyświetlaj obrazy w formatach nowej generacji
  5. Nie używaj pasywnych detektorów do poprawy działania przewijania
  6. Zmień rozmiar obrazów
  7. Unikaj wielokrotnych przekierowań
  8. Wyeliminuj zasoby blokujące renderowanie
  9. Usuń nieużywany JavaScript
  10. Unikaj bardzo dużych ładunków sieciowych
  11. Użyj efektywnego kodowania obrazów
  12. Zminimalizuj aktywność głównego wątku
  13. Zapewnij widoczność tekstu podczas ładowania czcionek internetowych
  14. Załaduj wstępnie kluczowe żądania
  15. Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej
  16. Skróć czas wykonywania JavaScriptu
  17. Unikaj zbyt dużego DOM
  18. Unikaj tworzenia łańcuchów żądań krytycznych
  19. Liczba żądań i ilość przesyłanych danych powinny być małe
  20. Minifikuj JavaScript
  21. Włącz kompresję tekstu
  22. Wcześniej nawiąż połączenia z wymaganymi źródłami
  23. Użyj formatów wideo dla animacji
  24. Nie używaj instrukcji document.write()

 

 

Podsumowanie

Core Web Vitals są jasnym sygnałem dla właścicieli stron, co powinni na nich poprawić. Dzięki wykorzystaniu narzędzi pomiarowych jak Page Speed czy Lighthouse dostajemy gotowe informacje prawie „na tacy”. Google swoimi działaniami w niepisany sposób wymusza optymalizację witryn poprzez poprawę ich kodu, optymalizację grafik oraz wykorzystywanie tylko niezbędnych skryptów na stronie. Z dużym prawdopodobieństwem w ten sposób przyczyni się do większego udziału specjalistów SEO w procesie tworzenia stron internetowych. Obecnie często byli oni często pomijani, w efekcie programiści wykorzystywali rozwiązanie wygodne i szybkie wykonawczo, niekoniecznie optymalne pod wyszukiwarki. Klient otrzymywał stronę, która z jednej strony działa, jednak jej wyniki optymalizacyjne są jak kotwica trzymająca stronę w SERPach w miejscu – zwykle poza top10. Oczywiście można się tutaj doszukać drugiego dna, strony niezoptymalizowane będą musiały inwestować w kampanie Google Ads – i to prawdopodobnie większe pieniądze niż zoptymalizowana konkurencja (czynnik jakościowy). W efekcie Google wyrówna sobie dodatkowy czas poświęcany na indeksację. W końcu strony internetowe tworzone dla Klientów są po to, aby sprzedawały, a nie tylko były w sieci 😉 CWV warto brać pod uwagę już na etapie projektowania, jeżeli zakładamy, że nasz biznes ma być widoczny, a cena konwersji maksymalnie niska.

 

[Aktualizacja] Dane dotyczące granic oceny wskaźników Core Web Vitals zostały zaktualizowane o wytyczne Google z dnia 17.02.2021 r.

 

Autor: Łukasz Pietruszka

Szybki kontakt z nami

    Wysyłając formularz wyrażasz zgodę na przetwarzanie Twoich danych osobowych.