30 maja 2021 77:12 Odcinek 041

Core Web Vitals – co zmieni aktualizacja algorytmów Google? – Wojciech Haremza

Google cały czas zmienia w mniejszym lub większym stopniu algorytm, który decyduje o tym, które strony będą wysoko w wynikach wyszukiwania. Dla sklepów internetowych to często być albo nie być, bo kto będzie kupował, jeśli sklep nie jest widoczny w sieci?

Dlatego dzisiaj wszyscy zastanawiają się, co zmieni aktualizacja Core Web Vitals i jak się do niej najlepiej przygotować. Szykować się na rewolucję (tak, jak na przykład przy aktualizacji BERT)? A może to tylko drobna korekta i nie ma się czym przejmować? No i przede wszystkim – co właściwie zmienić w sklepie, żeby spać spokojnie? Posłuchaj wskazówek Wojtka Haremzy.

Listen to „041 – Core Web Vitals – co zmieni aktualizacja algorytmów Google? – Wojciech Haremza” on Spreaker.

Dodatkowe materiały

Podczas naszej rozmowy Wojtek wymienił kilka narzędzi, które warto sprawdzić:

  1. Algoroo – strona, na której możesz sprawdzić dzienne zmiany algorytmu Google
    https://algoroo.com/
  2. GTmetrix – narzędzie do testowania witryn pod kątem szybkości działania
    https://gtmetrix.com/
  3. PageSpeed Insights – narzędzie od Google, dzięki któremu sprawdzisz stan swojej witryny pod kątem optymalizacji ładowania
    https://developers.google.com/speed/pagespeed/insights/
  4. Chrome Dev Tools – wtyczka do Chrome, w której między innymi możesz sprawdzić szybkość ładowania Twojej witryny. Żeby uruchomić narzędzie, wystarczy wcisnąć F12 w przeglądarce Chrome. Poniżej instrukcja użytkowania.
    https://developer.chrome.com/docs/devtools/
  5. Google Search Console – narzędzie od Google, które pozwala na zmierzenie i weryfikację ruchu z wyszukiwarki Google
    https://search.google.com/search-console/
  6. Pingdoom – jeszcze jedno narzędzie do monitorowania szybkości Twojej witryny
    https://www.pingdom.com/

Materiał bonusowy

Jeśli chcesz pogadać z Grupą iCEA o Twojej witrynie, możesz to zrobić, umawiając się na konsultacje przez formularz kontaktowy na ich stronie firmowej.

Dla pierwszych 10 osób, które w polu opis dopiszą hasło „Sztuka E-Commerce” iCEA przygotowała mały bonus. Jeśli po konsultacji zdecydujesz się na dłuższą współpracę, będziesz mógł skorzystać z vouchera na 1000zł na usługi grupy.

Transkrypcja odcinka

Można śmiało powiedzieć, że w przypadku e-Commerce wyszukiwarka Google powinna być traktowana trochę tak, jak persona zakupowa. To znaczy, powinieneś rozumieć potrzeby algorytmów rankingowych, a Twój sklep powinien je spełniać, bo inaczej przestanie być atrakcyjny dla Google. A jak przestanie być atrakcyjny, no to będziesz musiał się prawdopodobnie zmierzyć z tym, że pojawisz się na niższych pozycjach w wynikach wyszukiwania.

To można z kolei przeliczyć na złotówki, bo im niżej będziesz, tym trudniej będzie Cię znaleźć i u Ciebie kupić.

Jest też tak, że zmiany w algorytmach często podyktowane są troską o użytkownika końcowego, więc w zasadzie można powiedzieć, że w długiej perspektywie interesy Twoje, użytkowników i wyszukiwarki Google są zbieżne. Więc naprawdę z wielu różnych powodów warto zwrócić uwagę na rzeczone aktualizacje.

O Core Web Vitals rozmawiam dzisiaj z Wojtkiem Haremzą, który aktualnie pełni funkcję Head of SEO w Grupie iCEA. Z branżą SEO jest związany od 2007 roku, a swoją karierę rozpoczynał od pozycjonowania lokalnego. Od 2014 roku związany z budowaniem widoczności w wyszukiwarkach internetowych dla e-Commerce. Te parę lat doświadczeń dzisiaj naprawdę się przydało, bo trochę sobie porozmawialiśmy o sprawach historycznych. Ulubione powiedzenie Wojtka to „ma być jakość, a nie jakoś” i wdraża je we wszystkie działania, które nadzoruje. Prywatnie fan RPG, gór, dobrego i jedzenia i piwa kraftowego. A z punktu widzenia dzisiejszego odcinka to człowiek, który ma bardzo dużo fajnej, merytorycznej i ciekawej wiedzy – i nie zawaha się jej użyć.

Nie będę dłużej przeciągał wstępu – zapraszam Cię do mojej rozmowy z Wojtkiem o tym, jak przygotować się na aktualizację Core Web Vitals.

Cześć Wojtek.

Cześć Marek i przede wszystkim cześć wszystkim słuchającym. Dzięki, że zaprosiłeś mnie do swojego podcastu. Sam jestem aktywnym słuchaczem tego, co robisz – bardzo fajna i merytoryczna wiedza z tego płynie, także tym bardziej się cieszę, że też mogę dorzucić cegiełkę do edukacji świata e-Commerce.

Czekam na gradobicie pytań z twojej strony.

W takim razie pytanie rozgrzewkowe – czy mógłbyś w kilku zdaniach opowiedzieć o tym, czym zajmujesz się na co dzień w Grupie iCEA?

Tych tematów jest bardzo dużo, ale przede wszystkim piastuję stanowisko Head of SEO w całej grupie. No a ta grupa się już rozrosła nam trochę na sporo oddziałów, bo działamy na trzech kontynentach, w USA, Indiach i Polsce, gdzie mamy indywidualne oddziały. Ktoś musi spiąć pracę tych oddziałów, wdrożyć procesy, optymalizować je – to jest moje podstawowe zadanie.

Poza tym też działam dość mocno z działem handlowym nad ofertą firmy tak, żeby ona była jak najbardziej optymalna dla naszych klientów.

Zajmuję się też wszystkimi tematami rozwojowymi, jeśli chodzi o stronę techniczną grupy. Prowadzę też swój podcast „Zapytaj o SEO”, także wszystkich też zapraszam i ciebie również.

To powiedz – mając tyle na głowie, jak znajdujesz czas na to, żeby jeszcze pozyskiwać wiedzę z zakresu SEO?

Przede wszystkim praca w SEO to nie jest praca od 8 do 16. Moje zdanie jest takie, że żeby cokolwiek dobrego dla klienta w tej branży zdziałać, trzeba być pasjonatem.

To tak, jak dobry mechanik samochodowy nie pracuje od 8 do 16 w warsztacie, po godzinach sam naprawia swój samochód, tuninguje go, wdraża nowe części, narzędzia i tak dalej. Tak samo jest z SEO, trzeba być cały czas na bieżąco i tym żyć.

To jest moje hobby i jestem tym szczęściarzem, że faktycznie moja praca to moje hobby i mam wrażenie, że nie spędzam czasu w pracy, tylko na rozwijaniu swoich zainteresowań. I to jest chyba ten złoty środek, którego wszystkim słuchającym życzę, żeby taki złoty środek sobie w życiu odnaleźli.

Temat, dla którego cię dzisiaj zaprosiłem, to ogólnie rzecz ujmując aktualizacja algorytmów Google, natomiast to zaproszenie pojawiło się na okoliczność tej najnowszej, czyli Core Web Vitals. Myślę, że pewnie za chwilę sobie pogadamy o samym Core Web Vitals, natomiast może zacznijmy od tego dużego obrazu, czyli samych aktualizacji. Powiedz mi, co tak naprawdę z punktu widzenia właściciela sklepu w ogóle oznacza to, że Google aktualizuje swoje algorytmy wyszukiwania?

To może oznaczać bardzo wiele rzeczy, bo tutaj musimy przede wszystkim pamiętać o tym, że w ogóle aktualizuje te algorytmy po to, żeby poprawiać jakość swoich wyników wyszukiwania, no i poprawiać jakość odczuć użytkownika, czyli klienta Google tak naprawdę.

Google skupia się przede wszystkim na użytkownikach. Mało go interesuje zdanie właścicieli e-Commerce, bloga czy strony informacyjnej. Najważniejsze jest odczucia użytkownika. No i po to są te wszystkie aktualizacje, żeby tak naprawdę to cały czas poprawiać i ulepszać.

Tych aktualizacji tak naprawdę jest cała masa. Każdego dnia one się pojawiają, gdzieś tam się mówi, że jest 200 rocznie (są różne wartości). Ja na przykład polecam bardzo mocno wszystkim zainteresowanym strony, które monitorują te aktualizacje. Ja na przykład korzystam bardzo chętnie z takiej strony Algoroo. Tam po prostu na wykresie widzimy, jak wyglądają przetasowania każdego dnia wyników wyszukiwania. Czyli algorytm bada, jak zmieniły się pozycje na dane frazy. Na przykład widzimy, że była jakaś fraza, niech to będą „brodziki do prysznica” i algorytm bada, jak bardzo przetasowały się wyniki na tę frazę w danych zakresach pozycji. Na tej podstawie możemy określić czy pojawił się nowy algorytm, update czy zmiana. Bo jeśli przetasowanie jest duże, to wiadomo, że coś musiało się zadziać i na tej podstawie możemy wnioskować, że była jakaś aktualizacja.

Z takich ciekawych rzeczy – na pewno słuchają nas właściciele e-Commerce, bo przecież to Sztuka E-commerce – w samym maju były trzy duże przetasowania w wynikach wyszukiwania. No i pytanie właściwie do twoich słuchaczy, czy oni odczuli to na własnej skórze, bo przetasowania były spore.

Czy one ich dotknęły, czy nie? Trudno powiedzieć, niektórych dotykają, a niektórych nie. To jest troszeczkę prawo wyszukiwarki Google, że tych aktualizacji jest dużo, ale one bardzo rzadko tak naprawdę bardzo mocno wpływają na czyjeś biznesy, jeśli są oczywiście prowadzone z głową, a nie jakimiś bardzo szemranymi technikami szybkiego wbijania tych pozycji. Jeśli pracujemy bardzo organicznie, systematycznie, to raczej powinniśmy być odporni na jakieś większe zmiany. Są oczywiście drobne wyjątki, ale co do zasady nie powinno to być aż tak bardzo druzgoczące w samych wynikach.

Powiedziałeś o tych wyjątkach. Wiem, że branża raz na jakiś czas obwieszcza, że właśnie wchodzi duży update – i dla jednego segmentu, dla wielu czy w ogóle dla całego e-Commerce może oznaczać jakieś większe problemy. Mógłbyś podać z przeszłości jakieś takie bardziej istotne aktualizacje, które faktycznie ten rynek mocno przetasowały?

Trzeba by się było cofnąć gdzieś bardzo daleko, bo pierwsze takie, które pamiętam, to w ogóle było wprowadzenie (chyba rok 2013 lub 2014, ciężko tak bardzo się cofnąć, może jeszcze dalej) algorytmu Pingwina i Pandy. Teraz mamy już kolejne iteracje tych algorytmów, ale jak się tylko pojawiły na samym początku, to był duży problem, bo trzeba było całkowicie zmienić podejście do pozycjonowania.

W ramach przypomnienia – Pingwin to jest algorytm odpowiedzialny za badanie linkowania, czyli właściwie core algorytmu Google. O tym trzeba pamiętać, że na jakiejś podstawie należy stworzyć ten ranking bazowy. Mówimy o pozycjonowaniu bardzo często, gdzie wpływamy na pozycję poszczególnych fraz, segmentów fraz i tak dalej, ale na jakiejś podstawie Google musi budować sobie ten taki pierwszy i pierwotny ranking, od którego zaczyna dodawać kolejne czynniki i go modyfikować.

No i tym pierwotnym rankingiem jest ranking PageRank. On kiedyś był dostępny dla użytkowników i nawet były wtyczki do przeglądarek, gdzie można było sobie zobaczyć, jaki nasza strona ma PageRank, on był w przedziale od 0 do 10. Potem Google przestało udostępniać ten parametr, no ale wiemy, że on dalej w wewnętrznych algorytmach wyszukiwarki funkcjonuje.

Czym jest ten PageRank? To jest po prostu badanie tego, ile stron poleca naszą stronę i ile stron poleciło te strony, które poleciły nas. Prosta zależność, jest na to wzór matematyczny, który możemy gdzieś tam sobie przeliczyć. Wiadomo, że on się na pewno bardzo zmienił od czasu oficjalnych informacji. On jest bodajże zbudowany na algorytmie, który wypuścił Harvard, aczkolwiek nie chcę tutaj wprowadzić słuchaczy w błąd, ale jedna z popularnych dużych uczelni taki algorytm stworzyła. Google bazował na nim na początku, potem pewnie go zmodyfikował. Ale tym bazowym elementem jest na pewno PageRank.

No i mówimy o tym, że ten PageRank jest budowany na podstawie linkowania, czyli poleceń innych stron. No a właśnie algorytm Pingwin, o którym mówiłem, bardzo mocno wpłynął na to, w jaki sposób wyszukiwarka Google postrzega te linki, jak je przelicza i tak dalej. No i w związku z tym pamiętam, że jak ten Pingwin się pojawił w tej pierwszej iteracji i kolejnych, bardzo mocno zamieszał w wynikach wyszukiwania. Ja sam pamiętam też, że moje początki pozycjonowania polegały głównie na pozycjonowaniu linków, głównie w trybie automatycznym – na przykład miałem skrypt, który stawiał mi w ciągu nocy, powiedzmy 800 blogów na blogspot, na każdy z nich wrzucał po 5 artykułów z jakiejś mieszarki i to wystarczyło, żeby mieć dużo linków i żeby fajnie się pozycjonować. W pewnym momencie zostało to bardzo mocno zmodyfikowane i wycięte i trzeba było bardzo zmienić podejście do tego sposobu linkowania. Cały czas to podejście się bardzo mocno zmienia, więc to jest jedna z bardziej kluczowych rzeczy.

Tak samo takim kluczowym elementem był algorytm Pandy, czyli ten odpowiedzialny za treść. On bada, czy ta treść nie jest duplikowana, czy ma wartość dla użytkownika, czy jest kontekstowo dobrana odpowiednio do zawartości witryny i tak dalej. Czyli nie wystarczy już po prostu napisać jednej treści z synonimami, wrzucić ją na stronę i cieszyć się z wyników – trzeba bardzo konkretnie podejść do jakości tej treści, jaką wrzucamy na naszą witrynę i dbać o to, żeby ona nie była duplikowana na zewnątrz naszej witryny, cały czas ją optymalizować i tak dalej.

To były na pewno takie dwa podstawowe algorytmy, które mocno zmieniły całą branżę SEO nie tylko w Polsce, ale i na świecie.

Poza tym mamy jeszcze dużo innych algorytmów, takich już z całkiem niedawnego czasu – 3 lata, bo w 2018 roku pierwsza iteracja Medical Update. To jest właśnie ten wyjątek, o którym gdzieś mówiliśmy, bo on bardzo mocno wstrząsnął branżą związaną z tematami medycznymi.

Dlaczego tak się stało? Myślę, że jest to związane z tym, że Google mocno postawił nacisk na treści, które mogą bezpośrednio wpłynąć na nasze życie. Jeżeli mówimy o opisie produktu czy kategorii w sklepie meblarskim, to jeżeli tam będą błędy merytoryczne i napiszemy, że coś jest z buku, a tak naprawdę jest z sosny i tak dalej – no to mocno to na nasze życie nie wpłynie. Może będziemy zawiedzeni, że jakość tego produktu jest niższa, niż oczekiwaliśmy, ale na przykład nie zażyjemy tabletek, które nie są dla nas przeznaczone i przez to wylądujemy w szpitalu, albo na przykład nie podpiszemy umowy o kredyt w oparciu o błędne polecenia, bo to też wpływa mocno na nasze życie.

Czyli Medical Update mocno wpłynął na takie tematy medyczne, żeby gdzieś te treści nie były śmieciowe, byle jakie, tylko faktycznie były rzetelną poradą, którą pisze specjalista, czyli faktyczny doktor medycyny, a nie jakiś aktor czy uśmiechnięty pan ze stocka, który zostanie podpisany jako doktor medycyny. Więc te elementy musiały się pojawić, bo Google nie chciało, żeby użytkownicy dostawali wiedzę, która jest naprawdę pisana przez laików, tylko faktycznie ma konkretne podłoże naukowe, bo w tych branżach, jeśli mówimy o naszym zdrowiu, finansach, to są rzeczy, które mogą bardzo mocno wpłynąć na nasze życie i możemy zrobić sobie dużą krzywdę, korzystając z porad, które nie są sprawdzone i tworzone przez specjalistów.

No i mamy jeszcze jeden update, który mi przychodzi do głowy i może mocno nie wpłynął globalnie, ale ideologicznie. Ja bardzo lubię ten update i byłem bardzo zadowolony, jak się pojawił. To jest Site Diversity Update – on się pojawił gdzieś w połowie 2019 roku, o ile mnie pamięć nie myli i to była super rzecz, bo przestała faworyzować gigantów e-Commerce w wynikach wyszukiwania.

Nie wiem, czy jesteś w stanie cofnąć się pamięcią gdzieś do 2018, początek 2019 roku. Jak wpisałeś sobie na przykład „basen z plastikowymi piłeczkami” w wyszukiwarkę, no to bardzo często zdarzało się tak, że na przykład 8 pierwszych wyników z top10 pochodziło z Allegro, Ceneo lub innego agregatora ofert. Czyli tak naprawdę, mimo że korzystałeś z wyszukiwarki Google, bo chciałeś dostać jak najlepsze wyniki, no to Google polecał i tak jeden podmiot. Gdzie jest ten wybór?

Google wprowadziło ten update i w tym momencie jeden brand może pojawić się 2-3 razy mniej więcej na jedno hasło w top10 wyników wyszukiwania, no i to jest bardzo fajna rzecz, bo to dało możliwość mniejszym e-Commerce, takim, które startują lub nie są tak wielkimi brandami z machiną marketingową, jak te, o których mówimy, na zaistnienie w top10 wyników wyszukiwania, co bardzo pobudziło według mnie rynek e-Commerce w Polsce i podniosło przychody tych mniejszych e-Commerce, które nie są w stanie marketingowo walczyć z gigantami.

Także to był bardzo fajny update.

Na pewno trzeba też wspomnieć o update Hummingbird (Koliber) i jakby wynikowej tego algorytmu, czyli BERT. Dlaczego z mojej perspektywy to jest ciekawy algorytm? Dlatego, że on zaczął uczyć wyszukiwarkę Google, w jaki sposób postrzegać kontekstowo zapytania użytkowników. Czyli nie chodzi już tylko o to, że trzeba dokładnie wpisać frazę.

Na przykład szukałbyś dentysty na Warszawie-Ochocie. Kiedyś trzeba było całą stronę optymalizować pod kątem słowa „Warszawa” albo „dentysta Ochota-Warszawa”. Bardzo nienaturalne słownictwo. Google zauważyło, że ludzie wpisują w wyszukiwarkę znacznie dłuższe frazy. Ktoś wpisze „dentysta na Ochocie” i domyślnie ten człowiek wie, że Google powinno wiedzieć, że Ochota jest w Warszawie no i powinno wiedzieć, czego szukać.

I właśnie ten algorytm Hummingbird pozwolił łapać ten kontekst zdecydowanie lepiej. A wynikiem tego update był według mnie BERT, który pojawił się całkiem niedawno. On faktycznie jeszcze lepiej pozwala badać kontekst i intencyjność zapytania użytkownika, co jest bardzo fajną rzeczą.

Wspominam o tym dlatego, że to dość mocno zamieszało w wynikach wyszukiwania, ale według mnie na plus. Ja na przykład dostrzegłem w wielu przypadkach sytuację, w której ogólna widoczność, badana chociażby narzędziem Senuto, Semrush czy Semstorm (dużo jest takich narzędzi) zanotowała spadki. Ale, co ciekawe, spadki tej widoczności przełożyły się na wzrost przychodu w tych sklepach e-Commerce. Wydaje się to dosyć dziwne, no bo widoczność spada, a przychód rośnie. A dlaczego tak się stało? Po prostu te algorytmy były w stanie wyciąć frazy, które były zbędne z punktu widzenia budowania twojego biznesu. Jeśli ktoś na przykład szukał frazy związanej z rowerem, a w ogóle nie miał intencji zakupowej i nie chciał kupić roweru, tylko chciał się czegoś dowiedzieć i Google wykryło to swoim algorytmem, no to nie polecało sklepów z rowerami, tylko jakieś tam blogi eksperckie, grupy, fora i tak dalej. Na e-Commerce przestał być kierowany ruch bezsensowny, który by nigdy w życiu nie konwertował, a pojawiły się wzrosty na frazy typowo sprzedażowe. Więc pojawiły się spadki widoczności, ale za tym poszło lepsze targetowanie fraz do konkretnych stron internetowych, co uważam za wielki plus i mi, szczerze mówiąc, bardzo się ten update spodobał.

No a z takich update mocnych, które miały zakręcić rynkiem, a tak naprawdę to się nie wydarzyło, no to jest na pewno Mobile Update. Ja byłem ciekawy, jak to się wszystko zadzieje, bo chyba już w 2016 roku Google trąbiło, że będzie Mobile Update, branża pisała o mobilegeddonie, że trzeba mieć wersję mobilną, bo jak nie, to w ogóle cię wytnie z wyników wyszukiwania. Nic takiego się nie zadziało. Dlaczego? Bo to była naturalna zmiana – właściciele e-Commerce i stron internetowych, zanim ten update w ogóle miał się pojawić, to już sami wcześniej bardzo mocno stawiali na tą wersję mobilną, bo wiedzieli, że większość ruchu zaczyna się wrzucać na mobile. No i siłą rzeczy impaktu dużego nie było, bo ci, którzy mieli mieć wersje mobilne, to i tak mieli. A ci, którzy nie chcą, to i tak nigdy nie zrobią.

Więc wpływu nie było, tym bardziej że musimy pamiętać też o tym, że aktualizacje aktualizacjami, ale jeżeli Marku masz na przykład sklep i jako jedyny w Polsce sprzedajesz jakiś produkt, to nawet, jak nie będziesz miał tam treści, linków, wersji mobilnej, to i tak będziesz wysoko pozycjonowany, bo po prostu nie ma konkurencji, a kogoś trzeba pokazać w tym topie. Więc tutaj ten Mobile Update dużej różnicy nie zrobił, jeśli chodzi o same SERP-y, a przynajmniej my tego nie dostrzegliśmy na naszej dość dużej grupie e-Commerce, które prowadzimy.

No i taka ciekawostka na sam koniec moich podsumowań algorytmów (bo na pewno jest ich znacznie więcej, a ja wybrałem te, które mnie najbardziej zainteresowały) – będziemy mówili dzisiaj o Core Web Vitals, czyli właściwie takim update, który jest nastawiony na szybkość ładowania witryn, no a taki update już mieliśmy za sobą i to była połowa 2018 roku. Nazywało się to Speed Update, no i tak naprawdę nie zrobiło żadnej różny w wynikach wyszukiwania. Ale tam Google zaznaczyło faktycznie, że ten update dotknie tylko tych stron, które mają najgorsze możliwe wyniki. Tam nie było elementu, który mówi „musicie dobić do tego czasu ładowania strony, bo inaczej będzie źle”, tylko po prostu te, które miały najgorsze wyniki ładowania, zostały dotknięte tą aktualizacją, ale to był naprawdę znikomy procent, jeśli nie promil wszystkich wyników wyszukiwania na świecie.

Tak mniej więcej wygląda skrócona historia update z ostatnich lat algorytmu, które gdzieś tam zrobiły większe zamieszanie.

Wojtek to z tego, co mówisz, praktycznie wszystkie zmiany algorytmu gdzieś z tyłu miały takie uzasadnienie, że one są dla użytkownika końcowego. Strony muszą być bardziej wartościowe, wyszukiwarka lepiej podpowiada kontekstowo, daje użytkownikowi możliwość większego wyboru. Gdzieś tam to wszystko kręciło się wokół użytkownika, prawda?

Zdecydowanie tak.

Pamiętajmy, że główną usługą Google jest Ads. Jeżeli użytkownik nie będzie zadowolony z wyszukiwarki, przestanie klikać w te reklamy, przez co Google straci zarobek. Dlatego też cały Google jest optymalizowany pod użytkownika docelowego.

Mhm. No i teraz przechodząc pomału do Core Web Vitals, może zacznijmy od tego? To brzmi jak taka aktualizacja mocno techniczna. Zresztą sam mówiłeś też trochę o tej szybkości, za chwilę się pojawi przynajmniej kilka dość trudnych skrótów, które bardzo mocno brzmią technicznie i też w jakimś sensie takie są. Czy w takim wypadku Core Web Vitals faktycznie gdzieś tam w podszewce ma to dbanie o użytkownika?

Zdecydowanie tak. Przejdziemy sobie przez trzy takie najpopularniejsze wskaźniki, z czego jeden jest dla mnie po prostu must have i ja bardzo często, zwłaszcza przeglądając strony na wersjach mobilnych, mam ostre słowa w głowie, nie będę mówił, jakie.

Chodzi o CLS (Cumulative Layout Shift). Marek, ile razy miałeś sytuację, że wchodzisz na stronę, chcesz coś kliknąć i w momencie, gdy klikasz, to ona się przesuwa, bo doładował się na przykład obrazek i klikasz w inne miejsce, niż chciałeś. Ja mam bardzo często coś takiego i nienawidzę takich sytuacji, dlatego się bardzo cieszę, że ten update między innymi powinien wyeliminować takie sytuacje.

To chyba najczęściej reklama się w taki sposób doładowuje, że chcesz kliknąć w link, a klikasz w reklamę, a ta się przy okazji otwiera w nowym oknie.

Dokładnie tak.

Wojtek, no to trochę zaspoilerowałeś, więc w takim razie może dokończmy ten temat. Opowiedz mi o wskaźnikach w Core Web Vitals.

Tych wskaźników jest kilka i powiemy sobie o wszystkich, ale ja bym się skupił przede wszystkim na trzech podstawowych, które się pojawiają. W skrócie to jest LCP, FID i CLS.

LCP to jest tzw. Largest Content Paint. Co przez to rozumiemy? Jest to czas załadowania się największego zasobu na stronie. Jeśli na przykład ty masz podcast i jeśli okaże się, że najwięcej waży właśnie plik z naszym odsłuchem, no to faktycznie czas załadowania tego pliku będzie tym wyznacznikiem. Jeśli na przykład mamy stronę internetową fotografa i on ma w topie strony jakieś swoje najlepsze zdjęcie wrzucone w rozdzielczości 8K lub więcej i ono pewnie będzie ważyło najwięcej na całej stronie, no to faktycznie załadowanie się tego elementu będzie tym wyznacznikiem LCP. Im szybciej ten element się załaduje, tym lepiej dla nas.

Google zaleca tutaj bardzo mocno, żeby to były maksymalnie 2.5 sekundy. Wiadomo – im krócej, tym lepiej, ale jest to 2.5 sekundy. Wiem, że te wartości, jak się tylko w ogóle Core Web Vitals pojawił, były bardzo wyśrubowane, chyba nawet 2 albo 1.5 sekundy, no ale po konsultacjach ze specjalistami i społecznością pozycjonerów i developerów Google doszło do wniosku, że jest to zbyt wyśrubowane na ten moment. Wiele stron nie było w stanie sobie z tym poradzić, dlatego to jest 2.5 sekundy i jeżeli będą 4 sekundy, to jest akceptowalne. Poniżej 4 sekund powinniśmy bardzo mocno się skupić nad optymalizacją tego elementu.

Jeśli chodzi o to, według czego mamy właściwie te 2.5 sekundy sobie oceniać. Mamy narzędzia, które nam w tym pomagają i tych narzędzi jest naprawdę sporo. Musimy badać przede wszystkim te elementy, o których sobie będziemy dzisiaj mówili w dwóch formach. Możemy korzystać z tzw. lab data i field data.

Lab data to są dane laboratoryjne, czyli możemy przewidzieć, jak strona się będzie ładowała i na przykład możemy sobie do tego wykorzystać takie narzędzie jak GTmetrix, Pingdoom – jest sporo tego na rynku. Ja akurat korzystam głównie z GTmetrix, ale to są dane laboratoryjne. To, że akurat robot GTmetrix w tyle czasu wczytuje moją stronę, no to jest tylko bardzo mały ułamek tego wszystkiego.

Powinniśmy korzystać z takich narzędzi, jak field data, które są „danymi terenowymi”, czyli zbierają dane z dłuższego okresu, z bardzo dużej grupy użytkowników. No i takie rzeczy możemy sobie sprawdzić przede wszystkim w PageSpeed Insights. To jest narzędzie od Google, gdzie te dane są najbardziej skumulowane. Ale jeżeli ktoś ma podpięty Google Search Console (co polecamy i jeśli ktoś nie ma, to powinien jak najszybciej spauzować podcast i zainstalować go szybko na swojej stronie, bo to totalny must have), to w ten sposób możemy sobie sprawdzić, jakie są duże próbki, na przykład z okresu 28 dni na bardzo dużej grupie użytkowników i tak dalej. Te dane będą dla nas najbardziej miarodajne.

Ja polecam PageSpeed Insights, ono jest bardzo fajne dla laików do badania, bo pokazuje nam wszystko graficznie. Podobnie GSC. Do bardziej zaawansowanych badań konkretnych elementów to Chrome Dev Tools, o którym jeszcze pewnie trochę powiemy później. No i GTmetrix dla developerów, żeby faktycznie wyłapywać te najważniejsze elementy do optymalizacji.

Więc mamy LCP, czyli czas do załadowania się największego zasobu na naszej stronie. Tutaj tak od razu też mówię – bardzo często problemem tego LCP są loga strony. Jak wiemy, logo jest małym elementem gdzieś w lewym narożniku najczęściej, z tym że ja się często spotykam podczas optymalizacji stron, że to logo ma na przykład olbrzymie rozdzielczości, po 3000 pikseli na 4000 pikseli tak dalej, a potem jest za pomocą CSS zmniejszane do takiego rozmiaru, który zmieści się na stronie. Ale pamiętajmy, że ten mały obrazek musi najpierw załadować się w całej rozdzielczości, a potem jest zmniejszony i takie elementy bardzo mocno psują ten czas wczytywania właśnie w przypadku LCP. To dość łatwo zoptymalizować, wystarczy sobie po prostu posprawdzać. Na sam koniec, jak starczy nam czasu i pozwolisz Marku, to taki prosty tutorial pięciopunktowy pokażę, jak to sobie zbadać.

To jest ten element, który najłatwiej według mnie zoptymalizować na całej stronie, bo nie wymaga skomplikowanej wiedzy programistycznej, wystarczy po prostu pamiętać o kompresji obrazów i wrzucaniu ich w sposób sensowny na stronę. Oczywiście tak, jak mówisz, tym LCP nie musi być zdjęcie, bo to może być też film video, który ktoś wrzuci. Ale co do zasady, w większości przypadków stron internetowych są to właśnie zdjęcia, które mają zbyt duże rozdzielczości i to wystarczy skompresować i już ten element możemy bardzo mocno sobie poprawić.

Wiesz co, dopytam cię tutaj o dosłownie dwie rzeczy. Dobrze rozumiem, że jeśli bym sobie wszedł na stronę i miał naprawdę super łącze i jakiś bardzo duży plik mi się pobierze w ułamku sekundy, to jeszcze tak naprawdę wcale nic nie oznacza, bo dane, których wykorzystuje Google, mogą dotyczyć innych łącz?

Dokładnie. Ty możesz mieć super łącze, ale ja mogę mieć znacznie gorsze no i chodzi o to, żeby jednak pełen obraz sytuacji.

To jest w sumie ciekawe, co mówisz i tutaj bym dorzucił dygresję. Bardzo wielu właścicieli stron internetowych patrzy na sytuację tylko z własnej perspektywy. Ale jeśli ty Marek masz w domu 30-calowy monitor FullHD o olbrzymiej rozdzielczości, a ja mam w domu monitor 14-calowy, który nie jest FullHD, tylko mam 1024 piksele odpalone, to zupełnie inaczej tę stronę postrzegamy, no bo ja widzę coś innego, a ty widzisz  coś innego.

O tym trzeba tutaj mocno pamiętać.

To druga rzecz dotyczy w ogóle sposobu ładowania. Czy jeżeli mówimy o wskaźniku LCP, to wdrożenie mechanizmu, który opóźnia ładowanie niektórych elementów, na przykład do momentu, w którym użytkownik zescrolluje stronę – rozumiem, że te elementy, jeśli zostaną doładowane później, to nie wpływają na ten wskaźnik?

Tak, zdecydowanie – dobrze, że o to pytasz.

Musimy pamiętać, że ten wskaźnik jest mierzony w obszarze „above the fold”. Jest to ten obszar strony, który my widzimy jako pierwszy po załadowaniu strony. Czyli zwróć uwagę – masz duży monitor w rozdzielczości FullHD i zobaczysz więcej na pierwszy rzut strony niż ja na małej rozdzielczości. I te wyniki dla nas będą zupełnie różne, bo ten wielki obrazek może być na przykład dla mnie niewidoczny przy pierwszym załadowaniu strony, a u ciebie już będzie, bo będziesz widział większą część strony. Trzeba na to zwracać uwagę.

Ale tak jak mówisz o doładowaniu obrazów (tzw. lazy load), to bardzo polecam wdrażanie tego. Jak najbardziej to powinno poprawić takie parametry, zwłaszcza w sklepach, gdzie mamy dużo produktów w kategorii i dużo jest tych zdjęć. Lazy load jest bardzo fajny, bo dopiero przy scrollowaniu doładuje nam zdjęcia i dzięki temu ten LCP nie będzie musiał ładować tych wszystkich zdjęć od razu, tylko to, co zobaczymy, więc jak najbardziej in plus takie rozwiązanie.

W takim razie myślę, że możemy iść do kolejnych 3-literowych i trudnych do wyjaśnienia skrótów.

Ok, kolejną rzeczą jest FID, czyli First Input Delay.

Tak naprawdę to jest taki miernik interaktywności strony. No bo załóżmy, że wchodzisz na stronę fryzjera i chcesz szybko wypełnić formularz, żeby umówić się na wizytę, bo masz weselę, albo ważną imprezę. Albo stoisz na światłach w samochodzie (nie polecamy nikomu), to chcesz jak najszybciej ten formularz wypełnić, żeby coś się zadziało. No i ten magiczny skrót FID mówi po prostu o tym, jaki powinien być czas od załadowania strony do momentu, kiedy ona stanie się interaktywna. Czyli kiedy jesteśmy w stanie w coś kliknąć, coś wypełnić i tak dalej.

Jaki jest ten wymagany czas przez wyszukiwarkę? On już jest bardziej skrócony. Jeśli mówiliśmy o 2.5 sekundy w przypadku ładowania się treści strony, no to tutaj już mamy taki wymarzony czas od zera do 100 milisekund. To jest bardzo krótko, ale te czasy są osiągalne, da się to zrobić jak najbardziej. Do 300 milisekund jeszcze będzie akceptowalne, powyżej tego czasu powinniśmy mocno skupić się na tym, żeby spróbować poprawić ten parametr. To już nie jest takie łatwe, jak w przypadku LCP, bo najczęściej wymaga już konfiguracji po stronie serwera i optymalizacji skryptów na stronie, więc tu przeciętny użytkownik, który nie jest programistą i nie zna się na technologiach internetowych, będzie miał problem, żeby sobie z tym poradzić i będzie trzeba korzystać z pomocy specjalistów z konkretnej dziedziny.

Ale ten FID – skrót skomplikowany, ale tak naprawdę mówi wyłącznie o tym, w jakim tempie strona staje się dla nas interaktywna dla użytkownika.

Mamy też kolejny magiczny skrót, którym jest CLS. To jest to, co sobie zaspoilerowaliśmy wcześniej, czyli współczynnik przesunięcia treści. Czyli w momencie, gdy strona się ładuje, to ile razy ten content się przesunie nam w dół lub w górę w związku z doładowaniem się kolejnych elementów na stronie.

To dla mnie jest najlepsza rzecz, bo mnie to najbardziej wkurza w użytkowaniu stron, zwłaszcza w wersji mobilnej, gdzie ona się bardzo często przesuwa i to głównie przez reklamy, ale też przez inne elementy doładowujące się.

Tutaj nie mamy tego określonego w żadnym czasie, bo tego nie da się zrobić w czasie. Jest to współczynnik po prostu, on jest mierzony od 0 do 1. I od 0 do 0.1 jest naprawdę super, do 0.25 jest akceptowalnie. A jeżeli jest więcej, niż 0.25 to znaczy, że content przesuwa się bardzo mocno, co już powoduje utrudnienia w użytkowaniu tej witryny przez użytkowników i powinniśmy wtedy jak najszybciej zmienić.

Tutaj też trzeba zaznaczyć bardzo mocno, że przy tym przesunięciu contentu nie liczą się elementy, które my wywołujemy. Czyli jak masz na przykład jakąś harmonijkę na stronie (np. FAQ), klikasz i się rozwija jakiś element na stronie, to już nie jest liczone, bo to ty wywołałeś jako użytkownik. Chodzi o to, żeby samo z siebie się coś nie rozwijało bez naszej interakcji. Jeśli po naszej interakcji, to oczywiście już nie wchodzi w żaden sposób w skalę tej oceny.

No i oczywiście to też możemy sobie badać najlepiej przez PageSpeed Insights, tam bardzo fajnie jest pokazane, jaki mamy współczynnik tego elementu. Zresztą nie ma się co oszukiwać, według mnie przy tym CLS to właściciele witryn bardzo dobrze wiedzą, że mają z tym problem, bo jeśli ktoś specjalnie doładowuje reklamy, to wie, że ma z tym problem po prostu.

Więc na zdrowy rozum można to zobaczyć, ładując witrynę na swoim telefonie czy komputerze, możemy naocznie zobaczyć, jak to wygląda. Także ten CLS to według mnie najlepszy element tego update, bo o ile jestem w stanie poczekać sekundę dłużej, aż się strona załaduje, to jak klikam nie w to, co chciałem, to już jest zupełnie inne odczucie dla mnie jako użytkownika.

A powiedz mi, czy to przesunięcie działa w obu kierunkach? Wyobrażam sobie, że ktoś może wpaść na ambitny pomysł, że w takim razie zrobi sobie placeholder na baner 1000px i mu się gdzieś tam zwinąć do tych 300px, bo taki jest właściwy baner. To też jest źle, że layout się skurczy?

Tak. Jeśli content się porusza bez naszego zaangażowania, to jest źle.

Tutaj też warto zaznaczyć, że w ten element nie wchodzą popupy. Bo można stwierdzić, że popup też będzie złym rozwiązaniem, ale jeśli wyskakuje popup, to nie przesuwa się content, tylko zostaje zasłonięty. O tym trzeba pamiętać, że popupy są odporne na ten czynnik, także obawiam się troszeczkę, że może dojść do sytuacji, że wcześniej reklamy były prezentowane w treści i ją przesuwały, a teraz przeniosą się do popupów niestety, co może według mnie negatywnie wpłynąć na odczucia użytkowników.

No właśnie, bo generalnie popupy są rozwiązaniem tego problemu, ale generują wiele innych. Więc co do zasady popupów jakoś też specjalnie nie będziemy promowali, jako remedium na problemy ze sklepem internetowym.

Tak, no ja się troszeczkę tego boję, bo popup mimo wszystko jest fajnym narzędziem w e-Commerce. Jeśli chcesz zbudować bazę mailingową, co jest bardzo ważne, to ten popup jest naprawdę super. Albo wyskakuje popup „masz zniżkę na pierwsze zakupy”. To są fajne rzeczy.

Trochę się boję, żeby nie doszło do sytuacji, w której ktoś nagminnie zacznie wykorzystywać popupy do prezentacji reklam, przez co ich wartość mocno spadnie, bo jak ktoś zobaczy popup, to od razu będzie uczulony na to i nie będzie nawet czytał. To będzie negatywny skutek i mam nadzieję, że do tego nie dojdzie, a to wszystko zależy od kreatywności właścicieli stron internetowych. A jak wiemy, ta jest nieograniczona.

Mhm.

A jeśli chodzi o sam Core Web Vitals, mamy jeszcze inne elementy. One są mniej istotne. Na pewno nie są zupełnie nieistotne, ale nie aż tak bardzo.

Jest to FCP, czyli First Content Paint. Tak, jak mieliśmy LCP, to był największy element witryny, który się załadował, no to nasz FCP to będzie wtedy, kiedy załaduje się pierwszy element, czyli jaki jest czas do załadowania pierwszego elementu.

Mamy też TTI, czyli Time To Interactive. To jest trochę rozwinięcie, tak jak FCP jest rozwinięcie LCP – tak TTI jest rozwinięciem tego naszego FID. FID mówi nam o tym, w którym momencie pierwsze elementy strony stają się interaktywne. TTI mówi nam o tym, jaki jest czas do tego, żeby cała strona była w pełni interaktywna, czyli pełna funkcjonalność strony została załadowana, czyli kiedy załadują się wszystkie skrypty, formularze (i będą działały), video i tak dalej.

No i mamy jeszcze TBT (Total Blocking Time), który nam po prostu mówi, kiedy wszystko na całej stronie się całkowicie załaduje i witryna jest w pełni widoczna, operacyjna i możemy z nią robić, co nam się tylko podoba.

Także to są te elementy, które są gdzieś najważniejsze w tym Core Web Vitals.

Powiedz mi, na ile to może być w ogóle ważny czynnik rankingowy? Wydaje mi się, że tej pracy może być realnie dużo po stronie sklepów internetowych. O ile wyobrażam sobie, że pozmniejszanie zdjęć czy wprowadzenie innego formatu zdjęć to nie jest jakiś rocket science, o tyle sklepy lubią sobie przegiąć trochę ze skryptami. Tu karuzela, tu jakiś popup, maska na inpucie, tutaj jakiś element interkatywny, przybliżenia – dużo potrafi się dziać, w związku z czym dość dużo skryptów też się doładowuje. Plus jeszcze jakieś monitoringi, zewnętrzne usługi i tak dalej. Generalnie sam rozmiar strony i ta jej interaktywność w sklepach internetowych powoduje, że z wielu rzeczy będzie ciężko zrezygnować, albo w ogóle myśleć o optymalizacji. Czy jest o co kruszyć kopie?

Są dwie strony tego medalu tak jak zwykle.

Trzeba zrozumieć, dlaczego w ogóle ten Core Web Vitals się pojawia. Z jednej strony chodzi o to, że ci użytkownicy mają dostać jak najszybciej te informacje ze strony, żeby byli zadowoleni. Ale też trzeba pamiętać o tym, że Google musiało według mnie w ogóle pójść w tym kierunku.

Wystarczy sobie spojrzeć na statystyki. Ja sobie sprawdziłem specjalnie przed naszym nagraniem, żeby mieć świeżą informację. Jeśli mówimy o stronach desktopowych, to w 2016 roku średnia strona ważyła 1400KB. Pod koniec 2020 to jest 2100KB, czyli mniej więcej o 700KB jest różnicy, to jest jakieś 30% wzrostu.

A jeśli weźmiemy sobie wersje mobilne, a Internet stoi teraz na wersji mobilnej (chociaż desktop też jest istotnym elementem). 2016 rok – strona mobilna ważyła 800KB, a dzisiaj waży 2000KB. To jest prawie dwu-i-pół-krotny wzrost rozmiaru witryny.

Gdyby Google w pewnym momencie, jako taki trendsetter (bo Google jest trendsetterem, jeśli chodzi o technologie internetowe, nie ma się co oszukiwać), nie powiedziało w pewnym momencie „Hola hola – stop. Możecie rozbudowywać strony pod kątem wielkości, ale zadbajcie o to, żeby to było zoptymalizowane pod kątem wczytywania”. Za chwilę doszlibyśmy do sytuacji, gdyby utrzymać ten trend, że w 2024 roku strony mobilne ważyłyby po 6-7MB, tak? To już by była troszeczkę przesada. Raz, że kwestie serwerowe, zasoby, wczytywanie tego, przepustowości łącza i tak dalej – to wszystko jest infrastruktura i musimy na to patrzeć szerzej.

To, że strona jest duża i to, że strony rosną, to nie jest kwestia tylko tego, że ja, jako użytkownik, dłużej czekam, aż się załaduje. To jest konieczność postawienia infrastruktury serwerów, świadłowodów i tak dalej. Przecież to wszystko trzeba rozbudowywać. Im więcej wrzucamy rzeczy do swojego garażu, tym on musi być większy. Albo go posprzątamy i uporządkujemy, albo będziemy musieli dobudować piętro lub kolejną halę magazynową. W którąś stronę trzeba pójść. Dobudowywanie tych hal magazynowych i powiększanie strychu jest znacznie bardziej kosztowne i mniej optymalne z punktu widzenia operacyjnego, niż optymalizacja tego, co już mamy.

Także to jest wynikowa tego, że Google musiało jako trendsetter internetowy postawić gdzieś granicę i zmusić ludzi do optymalizacji tych zasobów, którymi już gdzieś świat Internetu dysponuje.

I teraz, jeżeli chodzi o to, czy warto o to kruszyć kopię.

Tutaj zależy bardzo od tego, w którym momencie my, jako właściciele strony internetowej jesteśmy. No bo tak – tak, jak mówiłem wcześniej, jeśli jesteśmy w bardzo dużej niszy i właściwie nie mamy konkurencji, to nawet jak ta strona będzie się ładowała i 30 minut, a ktoś bardzo chce ten produkt kupić to i tak poczeka.

Wiesz, ja na przykład bardzo mocno teraz czekam, żeby kupić PS5. Już pół roku próbuję walczyć, zapisuję się do newsletterów, na zapisy i ciągle gdzieś mnie to omija i przepada mi to PlayStation. Nie udaje mi się tego dostać. Ale gdyby mi ktoś powiedział „Wojtek, na tej stronie jest na pewno, musisz tylko poczekać 30 minut, aż się załaduje”, no to ja bym poczekał. Odpaliłbym sobie w tle, niech się załaduje i w końcu kupię, bo po prostu chcę mieć ten produkt.

Ale jeżeli mówimy o branży bardzo wymagającej, jak na przykład modowa i tak dalej, no to tutaj już jest bardzo istotne, jeśli na przykład byłbyś fanem mody. Trzeba pamiętać też o window shopersach, czyli ludziach, którzy po prostu przeglądają witryny i sklepy, nic nie kupując. Po prostu chcą być na bieżąco, jakie są trendy w modzie i tak dalej. Jeśli przeglądasz sobie taką stronę i masz czekać po 10 sekund na załadowanie się każdego produktu, żeby zobaczyć, jak dokładnie w szczegółach ten produkt wygląda, no to zrezygnujesz bardzo szybko. Jeśli jesteś w stanie przeglądać szybko, to pochłaniasz duże ilości wiedzy, nie tracąc na to czasu, więc tutaj mamy tą drugą stronę medalu, gdzie faktycznie ta szybkość wczytywania będzie bardzo istotna. Także tutaj na to trzeba zwrócić uwagę.

Ja bym też poruszył tutaj taki temat przez wielu, mam wrażenie, specjalistów i nie tylko zapomniany i gdzieś traktowany po macoszemu. Mamy coś takiego jak dwell time. Czym jest dwell time? To jest czas, który Google sobie może bada, może nie – aczkolwiek ja uważam, że tak, bo wszystkie eksperymenty i testy, które prowadziłem, na to wskazują. To polega na tym, że na przykład sobie Marku wpiszesz na przykład „wieczorowa koszula”. No i wchodzisz sobie na pierwszy wynik, który ci się pojawi w wyszukiwarce, wchodzisz na stronę, ale widzisz, że tam w ogóle nie ma koszul wieczorowych, tylko są jakieś koszule casualowe. Więc od razu robisz wstecz i powracasz do wyników wyszukiwania. No i tu jest właśnie ten czas, który Google sobie bada. Bo jeśli wszedłeś na wynik wyszukiwania i bardzo szybko z niego się wycofałeś znowu do wyników wyszukiwania, to znaczy, że na tej stronie nie znalazłeś tego, czego szukałeś. No i to jest dla Google bardzo ważny sygnał „kurcze poleciliśmy naszemu kochanemu użytkownikowi, na którym zarabiamy finalnie pieniądze, coś, co nie było mu potrzebne”.

Więc to jest troszeczkę weryfikacja rankingu, który prezentuje nam wyszukiwarka przez samych użytkowników, no bo finalnie ktoś musi sprawdzić te wszystkie algorytmy, czy dają dobre informacje. Kto to sprawdza? Użytkownik. Jeśli użytkownikowi ten wynik nie pasuje, to znaczy, że algorytm popełnił jakiś błąd i trzeba go poprawić.

To jest ważny element – jeśli ktoś wejdzie na twoją stronę i zanim się załaduje, to stwierdzi „nie chce mi się czekać” i się wycofa, to Google też może stwierdzić, że ten dwell time jest niski, czyli nie dostarczyliśmy tego, czego użytkownik oczekiwał. A Google nie będzie wnikał, dlaczego nie ma tam tego, co cię interesuje i czy to był długi czas ładowania, czy brak asortymentu, czy brak odpowiedzi na pytanie, które zadałeś. To już Google nie interesuje, po prostu może potraktować ciebie później zdecydowanie gorzej w ustalaniu rankingu, ponieważ twoja strona gdzieś tam użytkownikom się nie podoba i z jakiegoś powodu szybko ją opuszczają i wracają do wyszukiwania tego samego, co wcześniej.

Także podsumowując – to wszystko zależy od konkurencji, która się pojawia, od naszej niszy i naszych możliwości. Teraz musimy pamiętać, że masz e-Commerce i widzisz, że ten LCP powinien być na 2.5s, a ty masz 2.6s. No i teraz stajesz przed wyborem „muszę zmigrować się na inny CMS, to będzie kosztowało moją firmę kilkaset tysięcy złotych”, żeby uzyskać 0.1s ładowania. Odpowiedzmy sobie sami na pytanie, czy to ma zasadność biznesową, czy nie.

A ile zostało tak mniej więcej czasu do tego, żeby ten Core Web Vitals wszedł na dobre do algorytmów Google?

Czasu to już, wydaje mi się, nie ma tak naprawdę.

Update był już przesuwany chyba dwukrotnie, miał funkcjonować od maja, teraz na połowę czerwca ma się chyba pojawić. Jestem ciekawy, czy się pojawi, czy znowu będzie przesunięcie.

Trzeba po prostu działać. Ja bym nie patrzył pod kątem żadnych algorytmów na to, ile Google nam daje czasu, żeby to zrobić. Po prostu róbmy to, bo trzeba pamiętać – słuchają nas osoby z e-Commerce – e-Commerce to jest środowisko, które trzeba cały czas optymalizować. To jest koło optymalizacji, czyli bierzemy naszą stronę, wdrażamy tam jakiś element, analizujemy, co się wydarzyło po wdrożeniu. Jeśli się okaże, że jest ok, to znowu poprawiamy. Trzeba cały czas poprawiać, poprawiać i poprawić.

Jeśli na przykład dzisiaj ma ktoś LCP na poziomie 0.5s, to nie znaczy, że ma jeszcze 2 sekundy zapasu i jeszcze może coś tam popsuć, a i tak będzie ok. Jak masz 0.5s na LCP, to kurcze pomyśl, żeby mieć 0.1s. Skoro jest to możliwe, to walcz o jak najlepszy wynik. Niekoniecznie patrzeć tak sztywno na te elementy. Trzeba optymalizować cały czas tak, żeby faktycznie użytkownik był zadowolony i wtedy żaden taki update nas nie zaskoczy.

Teraz sobie możesz wyobrażać Marek, ile firmy developerskie mają zleceń na poprawę tych elementów. Wszyscy są zakolejkowani na maksa, bo wszyscy właściciele e-Commerce teraz walczą o to, żeby mieć jak najlepszy czas wczytywania strony. Ci, którzy pomyśleli o tym wcześniej, śpią spokojnie, bo już to dawno zrobili po niższych stawkach. A teraz wiadomo, im większe zapotrzebowanie na profesjonalnych programistów, którzy to poprawią, tym są drożsi przez to.

Także wszystko rośnie, trzeba cały czas nad e-Commerce pracować i nie patrzeć tylko sztywno na wytyczne, tylko poprawiać go cały czas pod użytkownika.

Wiesz, tak sobie myślę, że taka ciągła optymalizacja to jest w ogóle super rzecz, ale jak znam życie, to też trochę jest to taka wizja romantyczna. To znaczy dużo właścicieli sklepów pewnie nie do końca myśli o optymalizacji jako procesie ciągłym i taka aktualizacja, szczególnie głośna, też jest jakimś tam czynnikiem motywującym.

No to na pewno.

Pytanie do ciebie – jak ty właśnie widzisz rynek i jak oceniasz to, jak polski e-Commerce sobie radzi z tą optymalizacją?

Pytanie, czy w ogóle musi sobie radzić?

Gdybyśmy teraz tak poteoretyzowali trochę. Wyobraź sobie sytuację, gdzie pojawia się update algorytmu, gdzie czas wczytywania strony tak, jak w przypadku Core Web Vitals, będzie czynnikiem rankingowym. No i teraz załóżmy hipotetyczną sytuację, że wszyscy właściciele e-Commerce w Polsce dogadali się prywatnie „chłopaki, dziewczyny – nic z tym nie robimy, totalnie nie ruszamy tego tematu”.

No i co ma się zadziać? Nic się nie zadzieje, nikt nie będzie lepszy, nikt nie będzie gorszy, więc nic się nie ruszy tak naprawdę.

Odpowiedziałem gdzieś ostatnio na komentarz chyba Damiana Sałkowskiego z Senuto, jak wrzucili raport szybkości użytkowania stron i jak mocno Core Web Vitals może wpłynąć na przetasowanie, że właśnie ci, którzy poprawią te parametry, przeskoczą tych, którzy ich nie poprawią.

Tylko pytanie, czy ta masa wszystkich e-Commerce sprawi, że faktycznie coś się zmieni, no bo jeżeli faktycznie mamy branżę na przykład z butami i mamy tam kilkadziesiąt tysięcy sklepy w tej branży w polskim e-Commerce i 5 sklepów poprawi ten czynnik, a reszta nie – no to nic się nie wydarzy, bo pamiętajmy, że ten czas wczytywania strony to nie jest jedyny czynnik rankingowy.

Ja też zauważam, że dochodzi do takiej sytuacji – tak jak powiedziałeś, że jest to taki element motywacyjny, żeby coś zmienić na stronie. Ja bym to nazwał paniką, bo momentami faktycznie wygląda to tak, jak panika „musimy to poprawić, bo będzie masakra”. Gdzieś czytam wpisy, że jak będzie ci się strona wczytywała dłużej, niż trzy sekundy, to w ogóle wyrzuci cię z wyników wyszukiwania. No nie. To nie jest prawda. To nie działa w ten sposób, bo to jest jeden z setek, jeśli nie tysięcy czynników rankingowych, które będą gdzieś tam na ten element wpływały.

Także ja bym tutaj tak mocno aż nie panikował. Wiadomo – jeśli nasze czasy wczytywania są bardzo słabe, no to warto coś z tym zrobić, aczkolwiek mam wrażenie, że jeżeli miałbyś e-Commerce, który ma bardzo słaby czas wczytywania, to już dawno rynek cię zweryfikował i użytkownicy dawno na ten sklep nie wchodzą, bo po co mają wchodzić i czekać, skoro mają konkurencję, która ładuje się szybciej.

Według mnie to jest naturalny element, który się po prostu pojawia i nie jest jakoś tam mocno wymuszony. Google nie wprowadziłoby takiego update w momencie, gdyby to miało spowodować wycięcie z wyników wyszukiwania olbrzymiej liczby stron internetowych. Nie pozwoliliby sobie po prostu na to. Dlatego są przesunięcia wdrożenia tego update, bo Google po prostu bada rynek i czeka, aż zdecydowana większość stron będzie w miarę przygotowana na to, żeby to dobrze działało. Dopiero wtedy to wdroży, ale tak jak mówiłeś, to jest bardzo ważne słowo – jest to czynnik motywacyjny. Tak, jak mówiłem wcześniej – Google jest trendsetterem, jeśli chodzi o technologie internetowe, więc oni muszą jakoś zmotywować tych właścicieli stron, żeby coś z tym w końcu zrobili i żeby ten Internet działał po prostu szybciej i wydajniej.

No a poza tym, jeśli chodzi o sam polski e-Commerce, bo to było gdzieś tam kluczowe pytanie, jak sobie radzi z całą sytuacją? Tutaj nie chodzi chyba tylko o polski e-Commerce, ale i światowy – trzeba zdać sobie sprawę przede wszystkim z tego, że zdecydowana większość sklepów stoi na platformach typu SaaS (Software as a Service), gdzie właściwie właściciel takiego biznesu nie ma wpływu na to, jaki jest kod tej witryny, jak wygląda baza danych tej witryny, na jakim hostingu to jest umieszczone. Po prostu płacimy kwotą abonamentową co miesiąc i dostajemy system jako usługę. No i to nie po stronie właściciela e-Commerce jest teraz poprawianie tych elementów, bo on nawet jak będzie chciał, to nic z tym nie zrobi – tylko po stronie wydawcy SaaS. Mamy mocne SaaS w Polsce, no to oni powinni się teraz skupić na tym, żeby te parametry u siebie poprawiać, optymalizować swój kod, skrypty i tak dalej, żeby działało to jak najlepiej.

I z jednej strony jest to fajne, bo zobacz jaka odpowiedzialność spada z barków właściciela e-Commerce, tak? Nie musi szukać programisty, płacić za to i tak dalej, bo zrobi to SaaS za niego. No ale z drugiej strony trzeba zmotywować SaaS, żeby zaczęły w tym kierunku bardzo mocno działać. Co zresztą się dzieje i to widać gdzieś na rynku. Także tutaj trzeba o tym pamiętać.

No i ostatnia rzecz, którą ja bym tutaj poruszył, to są WordPressy, czyli najbardziej popularny darmowy CMS na świecie i w Polsce również. Nie wiem, czy ty kiedyś budowałeś stronę opartą o WordPressa, Marek?

Budowałem.

No i co, robisz stronę i teraz tak: potrzebujesz jakiś ładny moduł, to pach -wtyczki.

Tak.

Po co napisać samemu i zlecić. Wtyczka, wtyczka, wtyczka – to wszystko wydłuża czas ładowania. Większość wtyczek korzysta z 3rd party sites, czyli pobiera skrypty ze stron trzecich, co znowu wydłuża czas ładowania i tak dalej, więc ten czas do interaktywności spada.

Więc z jednej strony mam wrażenie, że tutaj będzie najgorzej, no bo mam wrażenie, że najbardziej dotknięci będą właśnie ci przedsiębiorcy, którzy działają w oparciu o darmowe CMS właśnie, typu WordPress, no bo jest to bardzo kuszące zawsze na początku swojej przygody z e-Commerce i w ogóle z Internetem. No bo po co mam zapłacić ileś tam tysięcy złotych miesięcy lub developerowi za postawienie i pilnowanie sklepu, skoro mogę właśnie sobie zainstalować WordPressa, na to WooCommerce darmowego, kilka wtyczek, które tam poprawią moją kartę produktu wizualnie, no i jest fajnie, nie?

Tylko problem pojawi się w momencie, kiedy mamy ten biznes rozwinięty i będzie teraz konieczność poprawy tych elementów. To już będzie kosztowało bardzo dużo, żeby te elementy popoprawiać, posegregować, zoptymalizować i tak dalej.

Także na początku coś, co było kuszące, bo było darmowe, teraz może się okazać, że będzie bardzo drogie w optymalizacji i trzeba będzie robić migracje, przenosić na inne systemy, albo zatrudniać profesjonalnych developerów. I to może być, wydaje mi się, najbardziej narażony na ten update i ogólnie w ogóle na wszystkie zmiany zachodzące w marketingu i biznesie internetowym segment, czyli właśnie ci przedsiębiorcy, którzy na początku z oczywistych względów – bo nie chodzi o to, że my negujemy takie podejście, bo wiadomo, że jeśli można mieć coś za darmo i zacząć biznes, to róbmy to. No ale niektórzy zapędzili się z tym za daleko i myśleli, że to będzie za darmo zawsze, a w tym momencie się okaże, że trzeba ponieść duże inwestycje na poprawę tych elementów.

Właśnie o tym też chwilę temu mówiłem, że bardzo często – szczególnie e-Commerce – mają taką tendencję do przepakowania strony i często to przepakowanie strony wiąże się właśnie z tym, co mówisz, czyli każdy element idzie z jakimś tam modułem na zapleczu. No i każdy element ma swoje skrypty, każdy element doładowuje jakieś dodatkowe biblioteki. Czasami są to zasoby własne, czasami zasoby z zewnętrznego serwera. No i nagle się okazuje, że samych plików JS mamy kilkadziesiąt na stronie. I nie ma żadnego problemu, żeby je zoptymalizować, tylko pytanie jak? No bo do czegoś te skrypty są, często w ogóle się okazuje tak, że te sklepy internetowe… na przykład w procesie zakupowym jest 50 różnych skryptów, z czego de facto na tym procesie są potrzebne dwa, bo reszta odpowiada za zupełnie inne strony i może się okazać, że gdzieś tam w procesie zakupowym mamy skrypt, który ładuje karuzelę banerów ze strony głównej, której tam nie ma. A to też gdzieś tam wpływa na czas, więc ja myślę, że z punktu widzenia optymalizacji to rzeczywiście może być najtrudniejszy element, no bo często ci właściciele nawet tak naprawdę nie wiedzą, co się stanie, jeśli my usuniemy jakiś skrypt, albo skleimy dwa do kupy, albo spróbujemy jedną bibliotekę użyć do trzech różnych skryptów, zamiast ładować ją każdorazowo osobno. To na pewno będzie duże wyzwanie z punktu widzenia technologii.

Tak, takim przykładem może być, chociażby dodatkowa wtyczka, która pozwoli ci zainstalować Analytics na WordPress. Wydaje ci się, „ok, co ona może pobierać?”, bo jest to pole, którym wstukujemy nasz kod śledzenia, który ma się wyświetlić w sekcji HEAD.

Ale może się okazać, że ta wtyczka pobiera na przykład czcionkę, żeby ładnie w twoim panelu WordPress po stronie administratora wyświetlić logo tej wtyczki. I to jest kolejny skrypt, który musi zadziałać w tle. Są to często właśnie takie elementy, które są zupełnie zbędne, no ale nie ma się co oszukiwać – komu ma zależeć, żeby to zoptymalizować? Na pewno nie twórcy wtyczki, która jest za darmo.

Tu zwrócę też uwagę na nawet nie tyle same wtyczki, które dodają coś małego, ale na same szablony graficzne. Często jest tak, że te szablony graficzne mają kilkadziesiąt różnych w ogóle odsłon graficznych, czyli jeden szablon przychodzi w jakichś tam 30 wersjach. Każda z tych wersji ma coś swojego, czyli to mogą być jakieś różne karuzele, czy inne pierdoły, które niekoniecznie są potrzebne. No i klient decyduje się na jeden motyw graficzny, no bo trudno, żeby się zdecydował na wszystkie na raz, a na stronie w źródle ma skrypty, które obsługują te wszystkie 30 motywów, które w ogóle nie są potrzebne. No i później w ogóle wymyślenie, który skrypt jest potrzebny, a który nie w tym konkretnym widoku, właściwie graniczy z cudem. To trzeba już po prostu wiedzieć.

No zdecydowanie.

Od razu jak o tym powiedziałeś, to pomyślałem o visual web builderach. Przecież tam jest tyle naładowane skryptów i wszystko ładuje się JS-em. Naprawdę tego jest w opór, a najbardziej popularny chyba teraz sposób budowania stron przez „amatorów”, to jest visual web builder, gdzie drag&drop przesuwamy sobie po prostu elementy. No i to fajnie wygląda po stronie administracyjnej, łatwo się buduję tę witrynę, ale tak bardzo obciąża czas ładowania witryny, że to jest po prostu masakra, no i ciężko to potem zaoptymalizować. Nawet doświadczony developer WordPress będzie miał duży problem, żeby stronę zbudowaną na visual web builderze porządnie zoptymalizować pod kątem oskryptowania, bo po prostu taka specyfika budowy strony wiąże się po prostu z oskryptowaniem.

Wojtek, odniosę się do tej naszej polskiej kreatywności w e-Commerce, która rzeczywiście często nie zna granic. Czy podejście w stylu „posprzątam sobie na stronie głównej, żeby tam osiągnąć dobry wynik, a reszta zostaje tak, jak była” w ogóle coś poprawi tym właścicielom? Czy trzeba patrzeć na każdą podstronę z osobna.

To znaczy, poprawi… wyniki dla strony głównej. Ale dla pozostałych podstron już nie.

To jest ten problem, że faktycznie gdzieś ten Core Web Vitals, przynajmniej możemy się spodziewać, że działa w formie „granular”, czyli wybiórczości. Każda podstrona jest oceniana oddzielenie. Zresztą to można sprawdzić – wystarczy sobie odpalić PageSpeed Insights, wstukać adres strony głównej i zobaczyć, jaki jest wynik i problemy na tej stronie. A potem to samo ze stroną produktową, informacyjną, strony koszyków, blogowe, etc. Każda z nich będzie miała inny wynik.

Tak samo, jak na przykład weźmiemy sobie, chociażby stronę produktową, tak? Jeden produkt będzie miał dwa zdjęcia w naszym sklepie, a inny produkt będzie miał tych zdjęć 15, z różnymi aranżacjami. To tam będą wyniki zupełnie inne, no bo tych elementów będzie zdecydowanie więcej. Czyli nawet jeden typ podstrony może mieć różne czasy wczytywania w zależności od zawartości tych witryn, co sprawia, że powinniśmy rozpatrywać każdą stronę osobno.

Aczkolwiek prawda jest taka, że jeżeli na przykład dobrze zoptymalizujemy sobie stronę produktową ogólnie, no to raczej wszystkie produkty, które mamy na stronie, powinny się wczytywać w miarę szybko, no bo co do założenia poprawimy te najbardziej kluczowe elementy.

Więc wiadomo, najlepiej byłoby się rozdrobnić na każdą pojedynczą podstronę, ale znowu nie dajmy się zwariować. Jeśli mam milion produktów w sklepie, to nie będę każdej podstrony monitorował osobno i sprawdzał osobno każdej podstrony, jak to faktycznie wygląda.

Ale jeśli mamy na przykład jakieś produkty-gwiazdy w sklepie, czyli wiemy, że te produkty się najlepiej sprzedają, to warto poświęcić dodatkowy czas i takie mrugnięcie oka w drugą stronę, żeby je już dopieścić maksymalnie i żeby było super fajnie i jak najlepiej dla użytkownika.

Powiedziałeś trochę o tym, jak pomierzyć sobie te wyniki. Padło parę narzędzi, ja je wszystkie postaram się podlinkować do notatek do odcinka. I trochę zaspoileruję – mam nadzieję, że nasi słuchacze rzeczywiście po nagraniu i odsłuchaniu odcinka wejdą w PageSpeed lub w Chrome Dev Tools, puszczą sobie audyt, no i tam, poza takimi ogólnymi wynikami, pojawi się też dużo mniej lub bardziej ciekawych danych, zależy, co kto lubi. Ale tych danych jest dużo – to są takie „sugestie”, co można poprawić, czy w ogóle lista błędów, które się gdzieś pojawiają na sklepie i wpływają na ten wskaźnik, a potem czynnik rankingowy. Czy masz jakieś fajne wskazówki, jak można poprawić poszczególne elementy w taki sposób, żeby to faktycznie dało duże efekty?

To znaczy, jeśli mówimy o czasie interakcji i CLS, czyli przesunięciu contentu, to tutaj prostych rozwiązań nie ma. CLS – wyłączmy reklamy. No ale nie do wszystkich pewnie to trafi. Tutaj jedynie po stronie administracyjnej możemy sprawić, żeby to funkcjonowało lepiej.

Jeśli chodzi o interaktywność, to jest to niestety kwestia bardziej zaawansowanych zmian w skryptach na stronie.

A jeśli chodzi o LCP, to w ogóle jak sprawdzić, co jest LCP? Wyobraźmy sobie, że ktoś wchodzi teraz na twoją stronę, sprawdza wielkość obrazków, ale jest ich dużo – to który jest LCP i jest widoczny above the fold, o którym mówiliśmy?

To można bardzo łatwo sobie sprawdzić w Chrome Developer Tools. Można wtyczkę zainstalować w Chrome no i prosta instrukcja właściwie – wystarczy uruchomić sobie tego Dev Toolsa, odpalić sobie naszą stronę, tam jest taka zakładka, która nazywa się „performance”. Wystarczy sobie ją otworzyć i tam zaznaczyć sobie taką opcję jak screenshot. Jak sama nazwa wskazuje, ta wersja deweloperska będzie badała wszystko na zasadzie screenshotów, które będzie widziała, jak ta strona będzie się ładowała. I na tej podstawie, jak dasz sobie start, to ona załaduje tą naszą stronę w wersji deweloperskiej, ładując po kolei wszystkie elementy zgodnie z tymi zaleceniami. No i na wykresie będzie jasno oznaczy element LCP, czyli co było największym elementem do załadowania na stronie pod kątem rozmiaru i ile zajęło to czasu. No i wtedy mamy prosty hint dla nas, że to jest ten element, na którym trzeba się skupić. Jeśli mamy na stronie głównej sto zdjęć, to nie trzeba optymalizować wszystkich – znajdźmy ten, który jest LCP, bo to on wpłynie bezpośrednio na wynik tego testu i współczynnik LCP, więc optymalizujmy to, co trzeba optymalizować, zwłaszcza jeśli mamy niewielkie zasoby – nie każdy ma teraz możliwość, żeby optymalizować stronę w nieskończoność i cały czas o to dbać. Trzeba umieć też te zasoby odpowiednio kierować, więc taki prosty trik z Chrome Dev Tools od razu nam mówi, który element powinniśmy zoptymalizować na stronie (zdjęcie, video, tekst, przycisk, cokolwiek).

To też się może przydać, jeśli wynajmiemy sobie developera freelancera na przykład. Bo jeśli powiemy mu „dobrze, to proszę mi zoptymalizować LCP”, no to jest mała informacja dla developera, bo on będzie próbował wielu rzeczy, przez co możemy też ponieść większe koszty. A jeśli wskażemy mu „ok, ten zasób z tego screena z Dev Tools proszę mi zoptymalizować”, to już będzie prostsze, bardziej ukierunkowane i ograniczy nasze koszta.

A jeżeli chodzi o perspektywę bardziej techniczną? Wrócę na chwilę do tego audytu – tam często jest tak, że tych sugestii jest bardzo dużo i one dotyczą wielu różnych obszarów, np. minifikacji plików, ładowania synchronicznego skryptów. Nie wszystko też pamiętam. Tego potrafi być dużo. Czy zadziała tutaj zasada Pareto, że poprawiamy 20% sugestii, a poprawia się wynik o 80%? Czy to wszystko jest równoważne i trzeba lecieć od góry do dołu?

Ja myślę, że można mocno pomyśleć o zasadzie Pareto i te trzy czynniki, o których mówiliśmy na początku, czyli LCP, FID, CLS to są te najważniejsze elementy, które się pojawią. Oczywiście tak, jak mówię – zasada Pareto co do zasady. Wiadomo, że jeśli ktoś ma mocno stronę załadowaną skryptami, to pewnie też może to mocno opóźnić stronę, ale też polecam sobie wejść na stronkę PageSpeed Insights. Tam są zbierane dane nie tylko na temat naszej strony i trzeba o tym pamiętać. Zawsze można wejść na PageSpeed Insights, wstukać stronę konkurencji i zobaczyć, co oni mają zoptymalizowane i jaki mają ogólny czas wczytywania strony. Na tej podstawie można łatwo określić, w którym kierunku iść, żeby te czasy jak najbardziej poprawiać.

Sprawdzajcie, co zrobiła konkurencja, bo to będzie widać i jaki uzyskali dzięki temu efekt. W PageSpeed Insights to będzie widać, jeśli sobie wstukacie adres konkurencji, to widać, jakie oni mają te współczynniki i jaki jest ogólny czas wczytywania strony. Bo jeśli na przykład zobaczycie, że ten na przykład LCP mają na bardzo dobrym poziomie, a mimo to współczynnik wczytywania strony jest u nich bardzo niski, to znaczy, że akurat trzy czynniki w ich przypadku w ogóle nic nie dały w całej tej ocenie. Tutaj trzeba się wtedy skupić na pozostałych elementach i po kolei je optymalizować.

Tak, jak mówiliśmy – większości nie da się zoptymalizować w przypakdu SaaS, bo to wymagałoby przepisania całego skryptu, na którym stoi SaaS, co wiadomo – nie jest takie proste, bo SaaS obsługują setki, jeśli nie tysiące sklepów, no i nie jest to takie łatwe, żeby zrobić update globalny, żeby wszyscy byli zadowoleni.

Także temat nie jest łatwy, ale PageSpeed Insights dla początkujących ludzi, którzy chcą zobaczyć w ogóle, jak to wygląda, jak robi to konkurencja, na co warto zwrócić uwagę w konkretnej branży, to PageSpeed Insights jest bardzo fajnym narzędziem, które pozwoli podejrzeć, co zrobiła konkurencja.

To ostatnia sprawa przed podsumowaniem. Mówisz o PageSpeed Insights i mam też takie wrażenie, że to jest wskaźnik-wyrocznia. To znaczy, często firmy wchodzą na PageSpeed Insights, widzą skalę od 0 do 100, widzą swój wynik… no i właśnie. Jaki wynik rzeczywiście jest dobry, a jaki wynik jest nieakceptowalny? Ja już się spotkałem z bardzo różnymi podejściami, niektórzy mówią, że jak nie jest 90 w górę, to nie ma o czym rozmawiać. Inni trzymają się 60-70 i są całkiem zadowoleni. A gdzie jest ten standard, którego warto się trzymać?

Standard, którego warto się trzymać, jest taki, żeby użytkownicy byli zadowoleni.

Ja mogę ci podać taki przykład i widziałem wiele takich kombinacji niesamowitych. Na przykład bardzo prosty sposób, żeby uzyskać bardzo wysoki współczynnik PageSpeed Insights na WordPressie (i zresztą jakiejkolwiek platformie) – zablokuj w robots.txt wszystkie zdjęcia, skrypty i CSS dla robota wyszukiwarki. Masz 100/100, ale czy to sprawiło, że użytkownikowi strona ładuje się szybciej? No nie, bo po prostu zablokowałeś robotowi dostęp do tych elementów, żeby uzyskać fajny wynik w PageSpeed Insights, co tak naprawdę nic nie dało, bo raz, że użytkownik nie zobaczy różnicy, a dwa – finalnie polecisz pewnie w pozycjach, bo Google zauważy, że zablokowałeś mu pełno zasobów, które nie powinny być zablokowane.

Także jest to takie troszeczkę wszystko grubymi nićmi szyte, bo można bardzo szybko poprawiać i manipulować wynikiem, a nie ma to realnego przełożenia na użytkownika.

Ja bym przede wszystkim zwracał uwagę na field data, czyli wejdź sobie na przykład w Analytics i zobacz, jaki jest średni czas ładowania różnych podstron na różnych urządzeniach. Nie patrz na współczynnik liczbowy PageSpeed Insights, tylko na czas. Są badania rynkowe, które pokazują, że powyżej jakiegoś czasu ładowania witryny użytkownicy rezygnują. Nie chciałbym tych badań przytaczać, bo mógłbym popełnić błędy w danych, a nie o to chodzi.

Prawda jest taka, że liczy się użytkownik i badajmy, jak strona się czasowo wczytuje użytkownikom, a nie jaki mamy wynik w PageSpeed. To jest wyłącznie taki wskaźnik, który nam może mówić, czy idziemy w dobrym kierunku, czy nie. Ale użytkownik jest najważniejszy finalnie.

Widziałem wiele e-Commerce, które mają na PageSpeed Insights wynik 20-25/100. Niby dramat, a tak naprawdę olbrzymia konwersja, mnóstwo użytkowników i tak dalej. Więc jest to wynik, na którym można się opierać, ale nie jest to wyrocznia. Badajmy się GTmetrixem, Pingdoomem i patrzmy, jak faktycznie szybko się to ładuje, a nie tylko wyłącznie wynik PageSpeed Insights, bo czasami – tak, jak mówisz – nie da się go poprawić w łatwy sposób.

Wojtek to była rozmowa pełna merytorycznej wiedzy, trochę odczarowania mitów i zdroworozsądkowego podejścia do tematu, za co słuchacze będą na pewno wdzięczni. Szczególnie że tak, jak mówiłeś – często wdrożenie poprawek pod kątem właśnie aktualizacji z tą szybkością może być dość kosztowne. Więc może po tym odcinku kilku właścicieli zastanowi się, czy to na pewno jest dobry moment.

Żeby też nie był taki wydźwięk „a ok, to nic nie robimy z tym”.

Robić trzeba. Optymalizujmy cały czas sklep pod użytkownika, żeby on był zadowolony z użytkowania tego sklepu.

Myślę, że to jest jeden z fajniejszych wniosków. Nie ma sensu walczyć z wyszukiwarką od algorytmu do algorytmu, tylko bardziej trzeba walczyć codziennie o to, żeby użytkownikom było fajnie w twoim sklepie internetowym. Myślę, że to jest taki kierunek, który warto obrać, bo wtedy sądzę, że Google doceni to, co robimy niezależnie od tego, jaka aktualizacja się pojawi w przyszłości.

Zdecydowanie tak.

To na koniec ostatnia rzecz i pytanie, które zadaję każdemu gościowi. Gdybyś miał zostawić słuchaczy z jedną myślą, apelem, hasłem – czyli jedną rzeczą, którą chciałbyś, żeby każdy po odsłuchaniu zostawił sobie w sercu i zapamiętał na długo – co by to było?

To nie jest łatwe pytanie. Trochę tak, jakbym miał jedno życzenie od Dżina.

Ale myślę, że ogólnie nie dajmy się zwariować, bo mam wrażenie, że ten Core Web Vitals stał się jakąś taką jedyną słuszną drogą i prawdą objawioną. Tak nie jest – to jest tylko jeden z bardzo wielu czynników rankingowych.

Jeśli wasza strona ładuje się sensownie i macie użytkowników, którzy korzystają z tej witryny, to nie stanie się nic takiego, że nagle po update całkowicie wylecicie z wyników wyszukiwania. Nie dajcie się nabrać, jak ktoś wam powie „musi pan / pani to zrobić w swoim biznesie, bo jutro was nie będzie w wyszukiwarce”. To jest scam i nieprawda, brak wiedzy, jak działają te mierniki i po co powstały.

Także nie dajmy się zwariować, zdroworozsądkowo – tak, jak mówiłeś też Marek, po prostu dbajmy o naszego użytkownika, a nie o to, żeby gdzieś tam nasz parametr był wysoki i wyśrubowany.

Super. Wojtek, dzięki za twoją wiedzę. Trzymaj się!

Dzięki wielkie trzymaj się i do usłyszenia niebawem.