More

    DBF #51: Core Web Vitals w pigułce.

    Core Web Vitals to termin, który w ostatnim czasie często pojawia się na ustach seowców i webdeveloperów. Nie bez powodu. W najbliższych miesiącach czeka nas aktualizacja algorytmu Google, nosząca nazwę Page Experience Update, której najważniejszą składową będą właśnie wskaźniki Core Web Vitals. Każdy wskaźnik odzwierciedla odrębny aspekt wpływający na UX, odnoszący się odpowiednio do: wydajności wczytywania, interaktywności oraz stabilności wizualnej strony. Niniejszy odcinek to pigułka wiedzy, która pozwoli Ci zrozumieć zbliżające się zmiany, o których opowie Dawid Pietkiewicz.

    Narzędzia wspomniane w odcinku:

    Źródła wiedzy:

    TRANSKRYPCJA ODCINKA

    Cześć, z tej strony Dawid Pietkiewicz, komentarz który właśnie słyszysz nagrywa już jakiś czas po przygotowaniu właściwego odcinka podcastu, a nagrywano go ponieważ jestem winien wyjaśnienia jednej kwestii. Mianowicie, chodzi o termin wejścia aktualizacji Page experience, czyli aktualizacji obejmującej te czynniki Core Web Vitals, o których będę opowiadał, w życie. Początkowo mowa była o maju 2021 i taka data też przewija się podczas podcastu. Kilka dni temu, dokładnie 19 kwietnia, Google wydało komunikat, że przesuwa tą datę. Nie żeby osobiście jestem to specjalnie zdziwiło, trochę może czułem w kościach, ponieważ nie jest jest to pierwsza tego typu sytuacja. Google w przeszłości np. w przypadku Mobile Fest Index również przesuwał te daty, więc w przypadku tak dużej aktualizacji, jak ta dotycząca Page Experience może można było się spodziewać, że ta data zostanie przesunięta. Wracając jednak do meritum – aktualizacja w obecnej formie zostanie bardziej rozłożona w czasie i od połowy czerwca zaczną już się zacznie rolować, pierwsze strony mogą zostać dotknięte zmianami, aż do końca sierpnia, do finalnego wprowadzenia aktualizacji w życie. Tak więc cały proces będzie bardziej rozciągnięty w czasie, będzie trwał od połowy czerwca, do końca sierpnia.

    Przynajmniej taka jest nasza wiedza na ten moment, taka jest informacja ze strony Google. Nie zatrzymuje cię już więcej. Z tą wiedzą możesz już wysłuchać resztę odcinka. Zapraszam.

    Cześć z tej strony, Dawid Pietkiewicz Witam was w 51 odcinku Dziennika Budowy Firmy, którego temat to Core Web Vitals w pigułce. Ze względu na zbliżającą się, wielkimi krokami, aktualizacji algorytmu Google obejmującą te czynniki. Temat bardzo głośny ostatnimi czasy, często omawiany. ja w dzisiejszym odcinku postaram się przedstawić wam taką pigułkę wiedzy na ten temat, czyli najważniejsze informacje jakie powinniście mieć, żeby zrozumieć w ogóle te czynniki, w jaki sposób one mają się do naszych stron internetowych, jak je w ogóle rozumieć. Niniejszy odcinek skonstruowałem tak, żeby wyjść od podstaw i coraz bardziej, coraz głębiej wchodzić w poszczególne tematy.

    Od razu zaznaczam jednak, że nie dowiecie się w tym odcinku, krok po kroku jak zoptymalizować stronę pod kątem Core Web Vitals. Temat jest na tyle złożony, że nie jestem w stanie po prostu w kilkunastu -kilkudziesięciu minutowym podcaście, bez żywych przykładów, powiedzieć wam; zrób to i to żeby otrzymać lepszy wynik. Nie da się po prostu tego zrobić. Każda strona też w inny sposób zbudowana, więc niekoniecznie te same działania dla jednej strony, zadziałają dla drugiej strony. Powiem wam natomiast gdzie szukać tych błędów, gdzie szukać przyczyn, dlaczego strona jest źle oceniana pod kątem Core Web Vitals.

    Mam więc nadzieję, że dzisiejszy odcinek rozjaśni wam po prostu trochę, o co w ogóle chodzi i jak się zabrać do tematu optymalizacji strony pod kątem Core Web Vitals. To co, zaczynamy.

    Zaczniemy od wprowadzenia pewnego terminu. Termin ten to Page Experience i jest to zestaw sygnałów, które określają wrażenia użytkowników, korzystających z danej strony internetowej. Termin ten został wprowadzony przez Google i jak zaraz dowiecie się, niedługo będzie jednym z czynników rankingowych. To co należy pamiętać jeżeli chodzi o Page Experience, to to że odnosi się do technicznych aspektów strony, wpływających na UX.

    Sygnały te nie dotyczą więc tego czy lepszy jest czerwony przycisk, czy żółty przycisk i tego typu, stricte wizualnych aspektów UXowych, ale konkretnych technicznych aspektów, które można po prostu w stosunkowo łatwy sposób ocenić i zbadać. Jakie mamy więc składowe Page Experience? Do tej pory były cztery. Pierwszą z nich była przyjazność strony pod kątem urządzeń mobilnych. Czyli to czy strona działa na urządzeniach mobilnych, czy dobrze wyświetla się na smartfonach na telefonach? Czy użytkownik nie ma problemów żeby z tej strony korzystać? Kolejnym elementem jest bezpieczeństwo stron internetowych, czyli to czy nie ma jakichś ataków czy strona nie wyłudzenia danych, nie działa na niekorzyść bezpieczeństwa użytkownika.

    Trzecim elementem jest obecność protokołu HTTPS. Natomiast Czwartym elementem jest brak natrętnych reklam. Tutaj głównie POPupów, które skłaniają całą zawartość strony, utrudniają korzystanie z niej. I te elementy zostały rozszerzone właśnie o Core Web Vitals. Na niego składają się trzy metryki, o czym opowiemy za chwilę, ale całość czyli Core Web Vitals, przyjazność pod kątem urządzeń mobilnych, bezpieczeństwo, https oraz brak natrętnych reklam składają się na Page Experience. I od maja 2021 roku, Google będzie uwzględniała te sygnały Page Experience, czyli całość, jako czynnik rankingowy, a to co było dotychczas zostanie rozszerzone o Core Web Vitals.

    Dobra mamy już załatwione pojęcie Pixel Experience. Chodźmy teraz krok dalej czyli do Web Vitals. Jescze nie do Core Web Vitals – do tego przejdziemy za chwilę. Na razie skupimy się na ogólnie pojęciu. Web Vitals to zestaw zunifikowanych wytycznych, skupionych na kwestiach wydajności strony, które są niezbędne do dostarczenia użytkownikowi satysfakcjonującego UX. Tłumacząc to na bardziej przystępny język- są to wytyczne które mówią o tym, jak strona ma działać żeby wrażenia użytkownika były pozytywne, żeby użytkownikowi łatwo i przyjemnie korzystało się z tej strony.

    To co warto wiedzieć o Web Vitalsach, to to że są to konkretne mierzalne metryki. Czyli to są rzeczy, które możemy fizycznie zmierzyć -jeżeli chodzi o optymalizację pod ich kątem, jeżeli chodzi o to czy strona dobrze jest zoptymalizowana pod kątem Web Vitalsów, czy nie. Nie są więc to subiektywne rzeczy, jak np. kolor przycisku. Core Web Vitals z kolei to podzbiór i każdy wskaźnik odzwierciedla odrębny aspekt wpływający na UX, odnoszący się do wydajności wczytywania, interaktywności oraz stabilności wizualnej stron. I do pomiaru tych Core Web Vitals, wykorzystywane są rzeczywiste dane od użytkowników. To jest pojęcie tzw. real users monitoring. Dane są zbierane od rzeczywistych użytkowników i Google wykorzystuje do tego Chrome User Experience Report, który zbiera po prostu dane z przeglądarki Chrome. O tych danych, rzeczywistych i danych laboratoryjnych w odniesieniu do Core Web Vitals, porozmawiamy sobie jeszcze pod koniec. Na ten moment musimy jednak wiedzieć, że do Core Web Vitals wykorzystywane są faktyczne dane od użytkowników.

    Jaki mamy podział tych Web Vitalsów? Z jednej strony mamy Core Web Vitals, do których zaliczamy trzy metryki.

    Jest to Larges content full paint, First Imput Delay oraz Cumulative Layout Ship i zaraz sobie o każdej z nich porozmawiamy i każdą z nich postaram się dość dokładnie opisać. Przejdźmy jednak do tematu innych Web Vitals. Na co również trzeba zwrócić uwagę, że istnieją i będą to: metryki takie jak Time to First Buy, First content full paint, Total Blooking Time czy Time Interactive. I te pozostałe Web Vitalsy, są tak naprawdę skorelowane bezpośrednio z tymi Core Web Vitalsmi, bo praktycznie wszystkie z tych Web Vitalsów, pomagają nam zdiagnozować również problemy z tymi Core Web Vitalsami.

    Np.Time tu First buy oraz First content Full Paint pozwalają zdiagnozować problemy z Largest Content FullPaint. Natomiast Total blocking Time oraz Time to Interactive pozwalają zdiagnozować problemy z First Input Delay. Po usłyszeniu teraz tych wszystkich skomplikowanych terminów, pewnie chcesz już wyłączyć ten podcast. Poczeka jeszcze chwilę, przejdziemy zaraz do wyjaśnienia wszystkiego. Na razie chcę tylko żebyś wiedział /żebyś wiedziała, że takie pojęcia funkcjonują i w jakiś sposób one są od siebie zależne. Przejdę więc do omówienia już konkretnych Core Web Vitals. Będę stopniowo odkrywa te karty, kolejne pojęcia i pod koniec mam nadzieję, że będziecie już mieli przynajmniej rozjaśnione o co chodzi z tym Core Web Vitals i jak rozumieć poszczególne pojęcia. Zacznijmy od Largest Content Full Paint, czyli w skrócie LCP. I jest to czas jaki strona potrzebuje do ładowania największego elementu contentowego, od razu po jej wywołaniu. Tu będzie funkcjonowało pojęcie about the fold, czyli tego co wyświetla się użytkownikowi po załadowaniu strony, bez jej skrolowania. Będziemy mówić o tak zwanym view porcie. I elementem LCP może być tekst, grafika, zwykle to są grafiki banery, jakieś większe obrazki. Może też być wideo, bądź jakaś animacja, ale tak jak na początku wymieniłem, tekst, może być to również jakieś DIV, blok tekstu. To co warto teraz wiedzieć i wprowadzę, to fakt że dla każdego Core Web Vitals Google stworzył progi oceny. Mamy trzy oceny. Możecie to zauważyć już w swojej Search Consoli, w raporcie Podstawowe Wskaźniki Internetowe. Jest to ocena Good, czyli dobra, Needs Improvment, czyli wymaga poprawek oraz Poor, czyli ocena słaba. Wartości te nie są wzięte jakoś z kosmosu, nie jest tak że ktoś w Google sobie usiadł i wymyślił, że tu będzie tyle, a tam będzie tyle.

    Są one oparte, po pierwsze na faktycznych danych o tych stronach internetowych, które są zbierane przez Google, ale również na aspektach psychologicznych czyli tego jak nasz mózg odbiera te czasy ładowania strony, interakcji, wyświetlania. Więc tutaj przy ustalaniu tych progów były brane również bardzo mocno te psychologiczne czynniki pod uwagę, czyli tego jak nasz mózg reaguje na te czasy ładowania, na czasy interaktywności ze stroną czy tez stabilność wizualną. Zaraz wytłumaczę też o co chodzi. Dla LCP taki oczekiwany minimalny wynik to jest poniżej czterech sekund. Czyli jeżeli mamy wynik poniżej czterech sekund to ten wskaźnik zostanie określony jako: wymaga poprawek.

    Ale to jest takie niezbędne minimum. Jeżeli mamy wskaźnik 'wymaga poprawek’, a mamy też inne wskaźniki, które określane są jako słabe, zajmujemy się w pierwszej kolejności tymi słabymi. Potem przechodzimy do 'wymaga poprawek’. Natomiast dla wartości dwie i pół sekundy, LCP jest określane jako 'dobre’. I teraz jeszcze jedna ważna uwaga LCP może się zmienić w trakcie ładowania. Czyli nie musi być to cały czas ten sam element, bo w miarę ładowania strony ten największy contentowy element na stronie może się zmieniać, bo jeżeli ładują nam się np. najpierw teksty, potem ładuje się grafika, no to na początku gdzieś blok tekstu może być tym LCP. Ale jak nam wejdzie w ten view port grafika jakaś duża, no to to LCP przeskoczy na grafikę. Nie jest więc tak, że ten LCP jest tym samym elementem od początku do końca. Jak więc zidentyfikować największy contentowy element strony? To możemy sprawdzić w łatwy sposób, korzystając z Chrome DevTools. Przechodzimy do zakładki 'performance’, nagrywane sobie ładowanie strony i możemy sprawdzić potem na wykresach, co jest określane jako LCP.

    Może być to szybkość odpowiedzi serwera i powiązana z tym ta wartość Time First buy, o której mówiłem wcześniej jako inną Core Web Vitals i tutaj już widzimy, że może ona wpłynąć również na to LCP. Jeżeli serwerowni zbyt dużo czasu zajmuje przesłanie tego pierwszego bite’a danych tego pierwszego pstryczka powiedzmy, to może nam to dość mocno zaburzyć, to jest largest content full Paint i ten czas ładowania tego największego zasobu. W kontekście szybkości odpowiedzi serwera, mamy różne możliwości optymalizacji. Ja nie będę teraz też bardzo mocno w to wchodził, bo musielibyśmy tu siedzieć kilka godzin, a i tak w takiej formie słuchowej  powiedzmy ciężko to wytłumaczyć wszystko, łatwiej to zrobić na przykładach wizualnych.

    Ale tutaj zarówno przyczyną może być wolny serwer, po prostu słaby, ale dość często będą to też problemy po stronie backendowej, na przykład jeżeli chodzi o bazę danych i obciążające zapytania serwera. Jeżeli chodzi o ten czas odpowiedzi serwera możemy wykorzystać również atrybuty takie jak PreConnect czy PreLoad dla danych zasobów, które spiorytetyzują nam ładowanie poszczególnych zasobów, czyli najważniejszych plików np. CSS czy JS, niezbędnych dla tego Largest content fullpaint. Możemy w ten sposób wymusić ich szybkie ładowanie, ale tutaj nie możemy też przegiąć. To zadziała to na minus, a nie na plus. Kolejnym elementem, który wpływa na LCP, są pliki CSS i JavaScriptowe blokujące renderowanie stron. I tutaj w kontekście tych plików CSS, bardzo istotna jest kolejność ich ładowania. Zastanówmy się więc czy pliki CSS/JS na pewno ładują się w odpowiedniej kolejności, czy może pliki odpowiadające za tę przestrzeń About TheFols za jakis największy element contentowy na naszej stronie nie jest ładowany za późno i czy nie mamy możliwości przeniesienia go tak, żeby ładował się jako pierwszy.

    Warto też się zastanowić czy nie mamy plików, których ładowanie można odłożyć na później. Nie musimy ich ładować od razu na starcie i obciążać tego naszego serwera. Więc tutaj takie drobne zmiany mogą nam dość mocno wpłynąć na to LCP. Jeżeli chodzi o kolejność ładowania tych plików czy ogólnie badanie szybkości ładowania strony, bardzo mocno polecam narzędzie webpagetest.org, które tworzy taki wodospad, gdzie mamy poszczególne zasoby, poszczególne wszystkie pliki ładowane na strony internetowej, poukładane według kolejności ich ładowania i w bardzo łatwy sposób korzystając z tego narzędzia możemy sobie sprawdzić, które pliki może ładują się niepotrzebnie szybko, możemy ich ładowania odłożyć w czasie, a które pliki ładują za późno.

    Tak jak mówiłem wcześniej, nawet drobna zmiana, drobna korekta ładowania tych plików może mocno wpłynąć na wydajność pod kątem LCP i ogólnie czas ładowania strony. Link do narzędzia na pewno zostawię pod transkrypcją. Co jeszcze może wpłynąć na LCP? Wolne ładowanie innych zasobów takich jak np. grafiki, pliki wideo, czy jakieś bloki tekstu. Wszystkie takie większe elementy, które ładują się na naszej stronie mogą być tym LCP,  więc mogą wpłynąć na ocenę pod tym kątem. Więc tutaj zwracamy uwagę też na optymalizację grafiki tych plików wideo, a często w tej przestrzeni about the foold, w miarę możliwości, unikamy po prostu jakichś ciężkich plików, jakiejś animacji czy pliku wideo, bezpośrednio na stronie zamieszczonych, no bo one mogą nam faktycznie mocno wpłynąć na ten czas ładowania.

    Jeżeli mamy jakiś bardzo duży blok tekstu, on również może być największym koncertowym elementem i może opóźnić nam ten czas LCP. Kolejnym elementem będzie wielkość i liczba ładowanych plików. Ogólnie dążymy do tego żeby tych plików było jak najmniej i były jak najmniejszej wielkości. Łatwo się o tym mówi, trudniej się robi, ale może możemy jakieś pliki połączyć w jeden? Nie musimy rozbijać na kilkadziesiąt plików JSowych czy CSSowych. Jeżeli możemy go połączyć w jeden, to zwykle to będzie lepsze rozwiązanie. Pamiętamy o mimifikacji tych plików, o tym żeby dbać też o ich jak najmniejszy rozmiar. Kolejny element wpływający na LCP to Client site rendering.

    I tu mam na myśli oczywiście skrypty javaskryptowe, jak i strony oparte w całości na JavaScripcie, na różnych Frameworkach. Tutaj zwłaszcza musimy bardzo mocno zwracać uwagę na to jak te skrypty są wykonywane, w jakiej kolejności, jak te zasoby się ładują jakie mamy TimeOuty. To jest ogólnie temat na osobną pogadankę. Na ten moment musicie wiedzieć po prostu że jeżeli macie stronę opartą na JS, to tu jest już troszkę inna bajka, jeżeli chodzi o analizowanie tego, ale jest to niesamowicie istotne. Tak jak gdzieś już po części, wcześniej wspominałem, wszelkie animacje about the Fold, zamieszczone na stronie tego typu ciężkie rzeczy, mogą wpłynąć na LCP.

    Ostatni element jest tak naprawdę uzupełnieniem tego co mówiłem wcześniej, pod kątem ładowania plików CSS i to jest już konkret, ale chce nam to zwrócić uwagę, bo często się pojawia ten problem, czyli Background Image, osadzone w CSS. Starajmy się raczej tego nie robić, raczej jako standardowe. IMG w HTMLu obrazki róbmy. Ponieważ Background Image w CSS działa w taki sposób, że pierwszym plikiem który przeglądarka wywołuje będzie ten plik html. Dopiero potem wyciągając HTMLa, idzie do tego pliku CSS, więc drogę mamy zdecydowanie dłuższą dotarcia do tego obrazka, niż osadzony bezpośrednio w HTMLu.

    Więc też zwracamy na to uwagę. Mam nadzieję że chociaż trochę rozjaśniłem to jak działa ten wskaźnik LCP. Choćmy teraz krok dalej, czyli do kolejnego wskaźnika którym będzie First Imput Delay,  w skrócie FID. FID, to czas w którym możliwa jest pierwsza interakcja użytkownika ze stroną, tuż po rozpoczęciu jej ładowania. I to może być kliknięcie jakiegoś linka, przycisku ze strony, tego typu interakcje. FID mierzy czas od momentu kiedy użytkownik coś kliknie, albo po raz pierwszy, aż do momentu kiedy przeglądarka będzie w stanie odpowiedzieć na tą interakcja, czyli wchodzimy sobie na stronę, wciskamy jakiś przycisk, na przykład do zalogowania, i ten czas od naciśnięcia, do reakcji przez przeglądarkę, czyli wyświetlenia okna logowania, będzie tym FID. To na co od razu zwrócę uwagę, w przypadku tej metryki, to fakt że nie ma możliwości jej bezpośredniego pomiaru w testach laboratoryjnych, tylko dane od rzeczywistych użytkowników się do niej odnoszą. Są inne Web Vitalsy, o których na początku gdzieś wspomniałem, które pomogą nam zmierzyć FID. Nie ma możliwości bezpośredniego pomiaru tego wskaźnika, z tego względu, że nie jesteśmy w stanie laboratoryjnie zbadać, jak użytkownik klika, jak szybko ta interakcja się dzieje, po prostu, więc są pewne wskaźniki, które pomogą nam to zrozumieć, pomogą nam pracować z tym wskaźnikiem, ale nie da się go bezpośrednio zbadać w tych t estach laboratoryjnych. Otestach laboratoryjnych i rzeczywistych zaraz będzie. No nie tak zaraz, ale pod koniec będzie, tak jak wspominałem. I oczekiwany minimalny wynik, jeżeli chodzi o FID, to poniżej 300 milisekund, a oczekiwany wynik, który będzie określany jako dobry, to poniżej stu milisekund.

    Jakie elementy będą wpływały na FID, na tą interaktywność strony? Zwykle w większości przypadków za interaktywną stronę odpowiada JavaScript. Więc zła optymalizacja kodu JS, zwykle będzie przyczyną tych problemów pod kątem interaktywności, pod kątem tego wskaźnika FID. I teraz, idąc krok dalej, za tą złą optymalizację pod kątem JS, zwykle będą odpowiedzialne tzw. Long Tasks czyli taski powyżej pięćdziesięciu milisekund. To jest opisane, że long task to są te, których wykonanie zajmuje więcej niż 50 milisekund, czyli uważamy na wszelkie ciężkie długo ładujące się skrypty, których wykonywanie zajmuje dużo czasu. Na duże bloki kodu, ale też na skrypty zewnętrzne, ponieważ skrypty zewnętrzne są w stanie dość mocno wpłynąć na tą interaktywną, dość mocno wpłynąć na czas ładowania zasobów i strony. Ogólnie w kontekście zewnętrznych skryptów to warto zastosować strategię, która będzie uruchamiała ten kod jej JS wtedy, kiedy jest potrzebny i to będzie dotyczyło zewnętrznych skryptów ale też naszych wewnętrznych skryptów.

    Czyli musimy zastanowić się czy na pewno wszystkie skrypty muszą być ładowane od razu przy załadowaniu strony, czy na przykład nie możemy ich opóźniać tak żeby były załadowane dopiero po interakcji użytkownika. Są mechanizmy, które pozwalają coś takiego zrobić np. w przypadku czatu, możemy wywołać skrypt czatu dopiero w momencie gdy użytkownik kliknie, że chce połączenie z konsultantem. Robimy wtedy jakiś loader,  że ładuje mu się czat i dopiero ładowany jest ten skrypt, a nie od razu po wejściu na stronę. Tak jak wspominałem, wcześniej nie da się zmierzyć laboratoryjne tego wskaźnika FID, ze względu na to, że odpowiada on właśnie za interaktywność.

    A jak mamy zmierzyć faktyczną interaktywność, jeżeli nie za pomocą rzeczywistych danych? Do procesu tego developmentu oraz do budowania/wykrywania tych błędów oraz ich naprawy, musimy więc wykorzystać inne metryki. Takimi metrykami będzie TBT, czyli Total Blooking Time, jeden z vitalsów, który się pojawił na początku, który pokazuje czas pomiędzy First content Fullpaint,  czyli pierwszym malowaniem strony, czyli tym momentem gdzie zaczyna coś się dziać na ekranie, a time to Interactive, czyli czasu w którym strona będzie interaktywna, w którym będzie w stanie odpowiedzieć na żądania użytkownika. Czyli ten TBT, wskazuje nam kiedy ten główny wątek jest zbyt długo zablokowany. Kiedy ten okres między pojawieniem się czegoś na ekranie, a możliwością interakcji z tym jest zbyt długi. TBT jest więc sumą trwania tych Long tasków, czyli ile czasu one potrzebują żeby zrobić nam tą interaktywność strony.

    Korzystając więc z tych innych Web Vitalsów o których wspominałem na początku i powiedziałem, że do tego dojdziemy. Czyli w tym przypadku Total Blooking Time oraz Time to Interactive jesteśmy w stanie ocenić FID. Jak zbadać te metryki oraz czas trwania tych Long tasków?

    Tutaj również możemy skorzystać z Chrome DevTools. Tu zakładka performance, nagrywamy sobie czas ładowania naszej strony i również będziemy mieli wskazania, które taski są tymi Long taskami, co wpływa na opóźnione interaktywność strony. Ostatnim Core Web Vitals jest Cumulative Layout Shift w skrócie CLS i jest to wskaźnik dotyczący niespodziewanych przesunięć elementów layoutu, podczas ładowania stron. I za jego pomocą oceniana jest ta wizualna stabilność strony. Czy nie ma żadnych przesunięć. Możecie kojarzyć to z codziennego korzystania z internetu stron internetowych jak ładuje wam się strona i podczas tego ładowania doładowuje się jakaś grafika, która przesuwamy np. blok tekstu i musimy scrollować, żeby dotrzeć do tego bloku tekstu. Czy chcemy wcisnąć jakiś przycisk na stronie, a nagle coś się nam odczytuje i nie trafiamy w ten przycisk, właśnie za coś takiego odpowiedzialna jest ta metryka CLS.  Jak przy każdej matryce tutaj również jest pewien haczyk, a w zasadzie uwaga. Jeżeli akcja zainicjowana przez użytkownika powoduje ten CLS to zbiorcze przesunięcie układu jest dozwolone, ale nie powinno trwać więcej niż 500 milisekund. Czyli jeżeli użytkownik zainicjuje coś, co spowoduje to przesunięcie, tą niestabilność powiedzmy wizualną, to jest to dozwolone, ale nie może to trwać więcej niż 500 milisekund.

    CLS nie jest określany przez wartość wyrażoną za pomocą sekund czy milisekund, ale po prostu wartości liczbową. I oczekiwany minimalny wynik, czyli ten który zostanie przez Google określony jako 'wymaga poprawy ale jest to akceptujemy to’, to poniżej 25setnych. Natomiast wynik 'dobry’ to wszystko poniżej jednej dziesiątej.

    Co wpływa na CLS, na te przesunięcia układu? Bardzo często będą to grafiki bez zadeklarowanych wymiarów lub przynajmniej zarezerwowanych przestrzeni na stronie. Jeżeli zamieszczamy jakąś grafikę to deklarujemy konkretne wymiary, szerokość, wysokość. Nie musimy się tutaj bać, że ona nie będzie się dobrze wyświetlać na różnych urządzeniach, nie będzie responsywna, bo współczesne przeglądarki przeliczą sobie, ustalą proporcje między tymi wymiarami i wyskakują te grafiki w przeglądarce. Więc, jeżeli chodzi o zamieszczanie grafik w kodzie, to deklarujemy te wymiary: szerokości, wysokości. Nie bójmy się tego, bo w ten sposób poprawiamy ten CLS,  poprawiamy wydajność strony pod kątem tego wskaźnika oraz unikamy tych przesunięć układu. Jeżeli nie chcemy lub nie możemy zadeklarować konkretnych wymiarów, grafik możemy wykorzystać też tzw. CSS aspekt ratio, gdzie możemy ten stosunek długości boków ustalić dla grafik. Co jeszcze może wpłynąć na CLS? Reklamy, ADSy, banery na stronie internetowej, również bez zarezerwowanej tej przestrzeni, w której powinny się znajdować.

    Jeżeli doładowuje się nam jakaś reklama, czy jakiś iframe i nie mamy wcześniej zarezerwowane przestrzeni, że w tym miejscu powinien się pojawić i mamy tam jakiegoś drzewa, np. w którym się pojawi ta reklama, tylko dynamicznie wchodzi gdzieś między tekst, na przykład, to jest to przesunięcie układu. Jest to duży problem, więc jeżeli mamy tego typu elementy to rezerwuje się dla nich wcześniej przestrzeń konkretną na stronach. I tutaj mamy też wszelkie elementy dodawane dynamicznie, bez zadeklarowanej przestrzeni. Może być to np. Lazy Loading, doładowanie się kolejny gdzieś tam grafik i przez to przesuwanie się całej tej struktury naszej strony.

    Więc jeżeli mamy te różne elementy, dodawane dynamicznie, to pamiętajmy żeby rezerwować dla nich przestrzeń, tak żeby podczas ładowania ta przestrzeń może być pusta i w niej, jak się załaduje, to się pojawi, to co ma się pojawić, ale nie róbmy tak, że to się doładowuje i przesuwa nam całą stronę, bo to jest słabe pod kątem użytkownika, słabe pod kątem tego wskaźnika, który jest tak naprawdę dla ułatwienia życia nam, użytkownikom. Na te przesunięcia układu również może wpłynąć Infinitive scroolink, czyli jeżeli przesuwamy stronę, jeżeli jest źle zaimplementowana, to Infinitive scrooling, coś nam się w trakcie dokleja, zmienia układ tej strony. To tu też zwracamy na to uwagę.

    Ostatnim elementem, który często sprawia problemy, ale jest oczywiście to o czym tu mówię, to niekoniecznie są wszystkie bezwzględnie wszystkie elementy, które powodują dany problem. Tylko te najpopularniejsze, ale jednym z takich najpopularniejszych, który stosunkowo często się zdarza, jest związany z czcionkami. I tutaj jeżeli chodzi o czcionki mamy dwa pojęcia Foold i to będzie nieostylowany tekst, który pojawia się na stronie w oczekiwaniu na doładowanie docelowego. Jeżeli te czcionki różnią się między sobą, mamy tą czcionka jakąś bazową, czekamy na doładowanie tej czcionki właściwej.

    I one różnią się mocno między sobą. To również może spowodować przesunięcie tego układu. Drugi problem to tzw. format czyli Flash of Invisible text i to jest puste miejsce w oczekiwaniu na doładowanie czcionki to o wiele rzadziej powoduje problemy z przesunięciem układu bo jeżeli mamy ten tekst zarezerwowany jeżeli mamy zarezerwowane miejsce i czekamy na doładowanie tej czcionki ona się znajdzie w tym miejscu to jest OK. Gorzej jeżeli nie mamy zarezerwowane tego miejsca tylko mamy coś w danym miejscu na stronie ta czcionka doładowań się przesuwa nam układ więc uważamy na te elementy, i one często będą miały miejsce w przypadku zaciągania czcionek z zewnętrznych źródeł, jak np. z Google Fonts. Więc w tych przypadkach uważamy na to, żeby rezerwować miejsce dla tych czcionek. Jeżeli mamy te różne czcionki, że najpierw doładować je się jakaś podstawowa czcionka, a dopiero potem jest zaciągane to docelowa, to starajmy się tak to oscylować żeby one jak najmniej różniły się między sobą. Jeżeli chodzi o przesunięcie tego układu, czyli wielkość tych czcionek oraz strukturę tego tekstu.

    To by było na tyle jeżeli chodzi o najważniejsze informacje o poszczególnych wskaźnikach.

    Teraz mam nadzieję, że chociaż trochę jaśniej wiesz o co chodzi i w jaki sposób interpretować te metryki. Teraz chciałbym jeszcze poruszyć dwa tematy. Pierwszy z nich poruszałem wcześniej i ciągle mówiłem, że wrócimy do niego na koniec. Więc wracamy na koniec. I to jest temat LabData czyli danych laboratoryjnych otrzymywanych w warunkach testowych, jeżeli chodzi o badanie tych Core Web Vitals oraz Field Data czyli danych rzeczywistych, od faktycznych użytkowników. Jaka jest różnica między tymi typami danych? Field Data to dane od prawdziwych użytkowników korzystających ze stron. Dane te pochodzą więc z różnych urządzeń lokalizacji, typów połączeń i zbierane są przez Chrome user experience report, to gdzieś tam wspominałem też wcześniej. I za pomocą danych o użytkownikach, przeglądarki Chrome, Google tworzy te raporty. Możemy za pomocą API te dane ściągać, mamy też narzędzia, które bezpośrednio nam te dane wyświetlają. To co się pojawia w Waszej Search Consoli, to są właśnie te Field Data, czyli z przeglądarki Chrome dane o użytkownikach. Natomiast LabData to dane z testowego, kontrolowanego środowiska.

    Tutaj mamy zdefiniowane połączenie, zdefiniowane urządzenia, lokalizację czyli mamy jakąś symulowaną sytuację, a nie rzeczywistą. Więc w przypadku Field Data, tych danych rzeczywistych mamy: dane prawdziwych użytkowników, mamy wiele różnych urządzeń, mamy różne rodzaje połączeń sieciowych, różne lokalizacje, mamy również dostęp do danych historycznych, bo one są zbierane w czasie i mamy dane dla całej domeny i poszczególnych stron, ale nie dla wszystkich stron, bo w przypadku gdy jest za mało danych zebranych z danej strony, bo np. jest nowa, no to nie będziemy mieli tych danych, tych Field Data. Natomiast Labdata, czyli te dane testowe, to są dane symulowane, z jednego wybranego urządzenia i domyślnie to jest Motorola Moto G4, na chwilę obecną, mamy zawsze takie same połączenia sieciowe, jakąś średnią symulację, to jest 3G Fast chyba określane. Mamy jedną lokalizację, mamy dane generowane na życzenie podczas wykonywania testu dopiero, czyli do historycznych danych też nie mamy, chcąc, nie chcąc dostępu i mamy dane tylko dla testowanego URL, jednego testowanego URL, można przetestować więcej URLi automatycznie, o tym za chwilę. Do ogólnej oceny, jak nasza strona radzi sobie z tymi Web Vital. Lepiej więc wykorzystać FieldData, te dane rzeczywiste, ponieważ one pokażą nam jak faktycznie to funkcjonuje na różnych komputerach, różnych połączeniach i tak dalej i po prostu są to dane od fizycznych, faktycznych użytkowników.

    Natomiast FieldData niekoniecznie sprawdzą się w procesie budowania, wprowadzania poprawek pracy nad tymi konkretami już. Te dane rzeczywiste mogą nie być dostępne dla wszystkich stron, bo mogą być one po prostu nie odwiedzane przez użytkowników, przez to nie ma skąd zebrać tych danych. Tutaj z pomocą przychodzą nam więc te dane laboratoryjne. Ponadto, w procesie budowania czyli w uproszczeniu poprawiania tych błędów na stronie oraz wprowadzania ich w życie, nie jesteśmy w stanie wykorzystać Field Data raportów, ponieważ musielibyśmy długo czekać na zebranie danych i na ocenę. W tych przypadkach również nie mamy wyjścia, tylko skorzystać po prostu z tych danych laboratoryjnych.

    Podsumowując więc: te dane FieldData rzeczywiste posłużą nam do wytypowanie konkretnych obszarów, konkretnych metryk do poprawy, konkretnych błędów pod kątem Core Web Vitals. Natomiast w kwestii już developmentu i wdrożenia poprawy, będziemy musieli opierać się na tych danych laboratoryjnych. Istotne jest więc łączenie zarówno LabData, jak i Fielddata. I dopiero biorąc to wszystko na warsztat, analizując zarówno dane rzeczywiste, jak i wykonując testy laboratoryjne, jesteśmy w stanie kompleksowo zająć się tymi Core Web Vitalsami oraz pracować nad ich poprawą.

    Jakie mamy narzędzia do badania Web Vital?

    Ogólnie narzędzi jest mnóstwo, ale większość z nich korzysta z tych samych silników. Trochę mechanizmy przedstawiania tych danych są inne, więc takim podstawowym narzędziem, jeżeli chodzi o badanie Web Vitals, jest CrUX. Raport CrUX tak naprawdę jest to API, do którego możemy się dostać za pomocą różnych narzędzi i w różny sposób sobiee dane zaciągać i w taki sposób działają one np. w Search Consoli. Dane w Search Consoli są więc danymi z CrUX, natomiast bezpośrednio z Search Consoli, z konkretnego raportu, możemy się przeklikać do Page Speed Insight i to jest kolejne narzędzie, które łączy już dane laboratoryjne z danymi CrUX, czyli tutaj możemy już przeprowadzić test konkretnej strony dla których zostaną zaciągnięte te dane rzeczywiste, ale zostaną przeprowadzone też te testy laboratoryjne i w kontekście Page Speed Insight, to warto pamiętać, że są to powiedzmy zdalne testy, czyli nie wykonywane fizycznie na naszym komputerze, tylko stymulujące jakieś średnie połączenie, jakieś średni typ urządzenia.

    Kolejnym narzędziem. Które możemy wykorzystać do badania Core Web Vital jest LightHouse. Tutaj podobnie będą to dane laboratoryjne, ale w przeciwieństwie do Speed Insight, sytuacja będzie symulowana  z naszego komputera, czyli taki jaki my mamy sprzęt, jakie mamy połączenie i tak dalej. Nie są to dane jakieś tam zdefiniowane, ale dane faktycznie z naszego sprzętu, czyli tak jak na naszym sprzęcie strona ładowała. Kolejnym narzędziem będzie Chrome DevTools, które się przewijały. To znowu są dane laboratoryjne z naszego sprzętu.

    Ale Chrome DevTools możemy już do konkretów wykorzystać, za pomocą Chrome DevTools możemy konkretne elementy, takie jak wspominałem  – czasy interaktywności możemy sobie analizować. Chrom DevTools jest bardzo fajny, właśnie pod kątem wykrywania już konkretnych problemów, konkretnych elementów do poprawy. Statystyki, dane możemy również zbierać, wstrzykując kod JS na naszej stronie, to już jest bardziej skomplikowany temat, ale również możemy wykorzystać kod JS, który damy stronę i będzie nam zbierał dane. Zwykle w przypadku oferty First Imput Delay dalej można to wykorzystać. Dodatkowym narzędziem, które bardzo dobrze moim zdaniem się sprawdza w optymalizacji pod kątem Core Web Vitals, w takim też ogólnym spojrzeniu na wydajność tego front endu naszego, jest właśnie webpagetest.org, gdzie możemy sobie różne dane zaciągać, możemy różne urządzenia symulować.

    Ale najfajniejsze jest właśnie ten wodospad, który pokazuje kolejność ładowania tych plików, jak bardzo one obciążają nasz serwer i jak bardzo obciążają też czasy ładowania. To jest też więc bardzo fajne do wyciągania konkretów i planowania konkretnych zmian. Jeżeli natomiast chcemy przetestować większą pulę adresów URL laboratoryjnie, to tutaj Page Speed Insight samo w sobie czy LightHouse nie pozwala nam na to, bo możemy jeden adres na raz przeanalizować. W takich wypadkach możemy wykorzystać na przykład crawlery – bierzemy sobie Screaming Froga, podpinamy Page Spee i craulujemy stronę i wyciągamy w ten sposób dla każdej strony wyniki. I tutaj można Page Speed API obejmuje zarówno wyniki z Pege Speed Inside, jak i dane CrUX, czyli możemy też te dane zestawić dla większej liczby stron i sprawdzić jak to wygląda. To są takie podstawowe narzędzia, które najczęściej są wykorzystywane do badania tych Web Vital. Jeżeli zapytacie, które z nich warto wykorzystać, które z nich jest najlepsze? Powiem, że wszystkie warto łączyć. Dane z różnych narzędzi sprawdzać, zarówno te laboratoryjne wyniki, jak i wyniki rzeczywiste zestawić je ze sobą, bo każde z narzędzi mimo, że może korzystać z podobnych mechanizmów, to trochę inne dane jest w stanie nam wyciągnąć, trochę inne elementy możemy przeanalizować.

    Ważne jest więc to żeby zbierać dane z różnych narzędzi oraz na tej podstawie planować wszelkie zmiany i optymalizacja. Oczywiście linki do wszystkich narzędzi znajdziecie pod transkrypcja. No i udało nam się doprowadzić do końca. Mam nadzieję, że chociaż trochę udało mi się rozjaśnić o co chodzi z tymi Core Web Vitals, jak rozumieć poszczególne metryki, jak interpretować wyniki. I pomoże wam to w optymalizacji strony pod tym kątem. Tak jak wspominałem, gdzieś na początku niestety nie jestem w stanie podać gotowej recepty, jak zoptymalizować stronę pod kątem poszczególnych matryc, ponieważ każda strona jest inna każda strona to inne zależności między ładowane i plikami między zasobami, nie jesteśmy po prostu w stanie stworzyć takiej gotowej instrukcji.

    Samych matryc Web Vital osobiście nie traktował bym jako bezpośredni cel działań. Uważam, że jest to pewnego rodzaju pomoc środek do celu, a nie bezpośredni cel. Bezpośrednim celem będzie optymalizacja, poprawa wydajności, ładowania strony oraz jej wyświetlania. Nie stawiał bym natomiast tych Core Web Vitals jako nasz nadrzędny cel, tylko pomoc w realizacji tego celu. Taki jest też zresztą zamysł metryk, czyli poprawa wydajności przyjazności dla użytkownika stron internetowych. Skupmy się więc na tym żeby strona była wydajna, żeby była przyjazna dla użytkownika, a Web Vitals, metryki po prostu w tym.

    Na koniec uspokoję też trochę tych którzy przesłuchawszy ten odcinek, patrzyli na swoją stronę zobaczyli, że ona ma braki pod kątem tych wskaźników. Moim zdaniem aktualizacja, która ma wejść w maj nie odbije się od razu intensywnie na wszystkich stronach internetowych. Zdecydowana większość analizowanych przeze mnie stron internetowych ma braki pod kątem tych Core Web Vitals. Jeżeli więc ta aktualizacja miałaby być bardzo rygorystyczna na starcie, to trzy/czwarte internetu czytaj strzelam, żeby mi ktoś nie policzył ile to dokładnie będzie, ale duża część internetu, po prostu, by była zaorana tym updatem. Więc osobiście nie uważam, że na starcie będziemy obserwować jakieś bardzo mocne wahania w wynikach wyszukiwania,  jakieś bardzo mocne rotacje w wynikach, ale z czasem wraz z coraz większą liczbą stron spełniających te założeniaCore Web Vitals. Myślę że to będzie coraz istotniejsze czynnik rankingowy, bo widać że Google dąży do tego żeby te strony były przyjazne dla użytkownika i to jest też ważne pod kątem nas użytkowników, więc mnie osobiście, mogę powiedzieć, że cieszy ta aktualizacja, bo wszystko mające na celu poprawę mojego komfortu, korzystania ze strony, jest na pewno na plus. Na pewno warto jednak skupić się na tych Web vitals, czy ogólnie tak jak mówiłem na poprawie wydajności elementów użytecznościowych strony, ponieważ ma to, nie robimy tego dla Google’a, robimy to dla użytkowników i dla ich komfortu korzystania z naszej strony i z tą myślą zostawię was na koniec.

    Mam nadzieję, że udało wam się brnąć do tego momentu i dziękuję tym którym się udało. Razem z transkrypcją tego odcinka, zamieszczę wszystkie linki do narzędzi, o których mówiłem, do istotnych źródeł wiedzy z których warto ją czerpać, tak żebyście mogli już samodzielnie sobie działać w tych obszarach. Dzięki raz jeszcze wszystkim za wysłuchanie dzisiejszego odcinka, zapraszam was również do innych odcinków DBF. Ja się z wami już teraz ostatecznie żegnam.

    Do usłyszenia.

    ZOSTAW ODPOWIEDŹ

    Proszę wpisać swój komentarz!
    Proszę podać swoje imię tutaj

    Powiązane odcinki

    Zapisz się do newslettera

    .