70. PageSpeed – jak to zrobić i na co zwracać uwagę? – Paweł Kryst i Łukasz Górny – Convertis

G.F: Dzień dobry! Witam Was serdecznie:

Paweł: Cześć!

Łukasz: Cześć!  

G.F: No właśnie, dzisiaj wyjątkowy odcinek — zaprosiłem moich guru od Presty i innych rzeczy technicznych, bo sam nie jestem tego godzien. Zaprosiłem dzisiaj Pawła, który jest naszym Senior Programistą od Backendu i Łukasza od Frontendu. Dobrze mówię, czy coś powinienem inaczej powiedzieć?

Paweł: Mi się wydaje, że dobrze.

Łukasz: Dobrze.

G.F: No właśnie, chłopaki są skromni. A zaprosiłem ich dzisiaj, bo będziemy rozmawiać o PageSpeedzie, bo z naszej perspektywy to temat szeroki i głęboki. Jak przychodzą do nas klienci, to często mylą różne pojęcia, a z drugiej strony nie wiedzą, czego się spodziewać. Porozmawiamy dzisiaj od strony i technicznej i biznesowej itd. Więc taka pigułka wiedzy, specjalnie dla Was. Moje pierwsze pytanie: czym jest PageSpeed?

Łukasz: Tak można w skrócie powiedzieć: PageSpeed to jest tak naprawdę szybkość strony, ale to się tak rozwinęło trochę i w sumie na ten PageSpeed składa się wiele rzeczy. To nie jest tylko prędkość strony, ale ogólnie to jak ona działa: czy płynnie, czy stabilnie, czy jest wygodna itd. W sumie jest sporo różnych rzeczy z tym związanych.

G.F: Paweł, coś byś dodał do tego?

Paweł: Samo słowo zostało wymyślone przez Google i stało się jakby taką marką. Wszyscy wiedzą. PageSpeed, PageSpeed to już wiadomo, o co chodzi. Google wymyśliło taki mechanizm do analizy wydajności stron, bardzo, bardzo dawno temu, a parę lat temu ogłosiło, że indeks PSI, czyli jakby indeks wydajności strony, który oni odliczają, będzie miał wpływ na pozycję stron w wynikach indeksowania i wtedy się zaczęło, bo wszyscy zaczęli zwracać na to uwagę, żeby strona była szybka, wydajna i żeby szybko działała.

G.F: I właściwie, szaleństwo się zrobiło, bo jest na to wskaźnik, można sobie wejść na stronę Google, i sobie zmierzyć, że nasza strona na desktopie ma X punktów a na mobile X. Jeśli dobrze pamiętam, jest wskaźnik od 0 do 100 – im więcej, tym lepiej, tym lepiej teoretycznie wpływa na nasze SEO. I wszyscy się tym zaczarowali i chcą to mieć jak najwyżej – 99, 80, 100. Czy to w ogóle jest możliwe? Posiadanie tak wysokich rzeczy, tak wysokich wskaźników.

Paweł: No jest. 

Łukasz: Pewnie, że można.

Paweł: Spotykaliśmy się z takimi wynikami. Z niektórymi stronami, też nam się udało wyciskać takie speedy.

Łukasz: No tylko, że to wymaga dużo pracy jednak.

G.F: Co to znaczy dużo pracy?

Łukasz: Bo PageSpeed w sumie to nie tylko to, co widzimy, ale bardzo dużo rzeczy, których nie widzimy. Trzeba by zacząć od serwera, na którym jest strona, bardzo często. Potem na jakim oprogramowaniu. A potem jakie ma jeszcze tam dodatki, moduły, skrypty, wtyczki itd. itd. A potem dopiero, na końcu, jest warstwa frontowa, wizualna, to co widzi właściwie ta osoba. Także, trzeba tam dość głęboko czasami zajrzeć, żeby coś móc poprawić.

G.F: Paweł, coś byś dodał?

Paweł: No tak, tak, tak. Pracy czasami jest bardzo dużo i to zależy jaki ten wskaźnik się chce uzyskać. To jest taka krzywa logarytmiczna. Z czerwonego pola wyjść…

G.F: To znaczy?

Paweł: Dla tych, którzy nie znają tej strony, badania PageSpeed, ten wskaźnik od 0 do 90 ma 3 kolory: czerwony — to jest fatalnie, żółty — taki może być i zielony. I o ile z czerwonego wyjść na żółty no to parę rzeczy można zmienić i się udaje, o tyle z żółtego do zielonego to już trochę więcej pracy trzeba. A żeby wejść tam gdzieś pod poziom 90% czy dojść do 100 to wtedy ilość pracy rośnie. To już naprawdę trzeba dopracować bardzo dużo szczegółów. Ten analizator PageSpeed mierzy bardzo, bardzo dużo elementów i w związku z tym, bardzo dużo różnych elementów trzeba naprawić, poprawić, usprawnić. I to tak, jak to Łukasz mówił, to nie jest tylko kwestia strony wizualnej (wielkości strony, rozmiaru elementów strony, kolejności ładowania elementów na stronie), ale też na przykład wydajności serwera czy też dopasowania do urządzenia końcowego, czyli tego, które wyświetla stronę

Łukasz: Google teraz też szczególnie w ostatnich latach największy nacisk kładzie jednak na urządzenia mobilne, bo wszyscy przeglądają te telefony wszędzie. Tam nie ma czegoś takiego, że zaplanujesz sobie, że przejrzysz jakąś stronę, siadasz do komputera i przeglądasz. Nie, na telefonie to jest zawsze spontanicznie. Chcesz coś zobaczyć, wpisujesz w Google, wchodzisz na stronę. I wtedy PageSpeed ma znaczenie (to jest nawet poparte jakimiś tam testami, badaniami), bo jeżeli wchodzisz na jakąś stronę z Google i ta strona ładuje Ci się bardzo długo, to bardzo szybko się zniechęcasz, wychodzisz, cofasz, idziesz do następnej strony. 

G.F: No właśnie, tutaj jest pytanie, jak szybko itd., bo to nawet pół sekundy może być już problemem. Jak tak opowiadacie mi o tym PageSpeedzie to się zastanawiam czy w ogóle warto dążyć do tych 90-paru punktów, bo wiele dużych sklepów ma marne wyniki, czyli tam nawet 70-80 punktów na 100 i nie zawracają sobie tym głowy, pomimo że teoretycznie to wpływa na SEO. A z drugiej strony, jak chcemy pewnie osiągnąć to 90 punktów, 95 punktów, to musimy zrezygnować z wielu bajerów, które są prosprzedażowe, a które większość z tych sklepów stosuje. Czyli jakieś pop-upy, czy jakieś promocje marketingowe, jakieś rzeczy, które automatycznie, dynamicznie się ładują. Dobrze mówię, czy się mylę, Paweł?

Paweł: Wiesz co, ja bym sprawdził to, co mówisz, na jakimś przypadku, bo nie wiem, skąd wziąłeś informację, że wiele sklepów, które są topowe ma mały PageSpeed. Trzeba by zwrócić uwagę na dwie rzeczy. PageSpeed, jeżeli mówimy o tym indeksie Google’owym, to on mierzy dwie wersje: dla komórki i dla stacjonarnego komputera. Te wymagania wydajności dla wersji desktopowej są niższe i tam jest łatwiej osiągnąć te 90-parę procent czy punktów. Dla wersji komórkowej ten prób jest wyższy, to jest analizowane dla słabego połączenia sieciowego. Jak sobie wejdziemy na stronę PageSpeed to możemy sobie takim malutkim druczkiem tam przeczytać, że to są pomiary dla wolnej sieci internetowej i dla urządzenia chyba MotoG4, czyli takiego starego telefonu komórkowego. I tutaj ciężko jest uzyskać wysoki wynik, bo trzeba sprawić, aby strona była wydajna na wolnej sieci i na wolnym urządzeniu. Natomiast ja myślę, że duże sklepy topowe, zwracają na to uwagę; zwracają uwagę może nie tyle na sam indeks. Bo co nam mówi ten indeks? Ten indeks ma dwie rzeczy. Po pierwsze, podobno według Google, wysoki indeks PageSpeed poprawia nam pozycje w wyszukiwarce, ale druga sprawa to jest to faktyczny miernik tego, jak nasza strona jest przyjazna dla użytkownika. I tutaj nie ma co dyskutować, bo były badania, że jeżeli ktoś chodzi po sklepie internetowym i przeklikuje się ze strony na stronę po 2 sekundy, to on się szybko zmęczy i może nie dojść do koszyka i może stwierdzić, że: „A to odpuszczam. Nie robię tu zakupów, bo to jest kiepski sklep”. Więc sklepy powinny zwracać uwagę na PageSpeed i myślę, że te duże zwracają.

G.F: To ja tutaj zweryfikowałem to, co mówisz Paweł, bo wrzuciłem w PageSpeed dwa duże sklepy. Mamy początek października 2022 i Media Expert na komórce ma 57 a na stacjonarnym ma 93 – jest okej. Z drugiej strony jest Zalando, które na stacjonarnym ma 74, czyli taki kolor pomarańczowy/żółty, a komórka – uwaga, Zalando – 30.

Paweł: No to pewnie gdzieś jeszcze popełniają błąd albo są nieświadomi tego, albo mają takie inne walory i przewagi konkurencyjne, że nie zwracają uwagi, bo to jest kwestia też przewagi konkurencyjnej.

G.F: O właśnie. 

Paweł: Jeżeli ładujesz kasę w reklamę i, i tak masz sprzedaż, no to, co się przejmujesz. Albo masz tańsze produkty.

G.F: To jest pytanie. Ja tym punktem chce pokazać, że PageSpeed to nie Złoty Graal, który powoduje znaczące zwiększenie sprzedaży i należy wydawać niesamowicie dużo pieniędzy, żeby osiągnąć te najwyższe wyniki, bo to nie zawsze się opłaca. Trzeba przeanalizować. I z tego powodu my realizujemy dla sklepów, które do nas przychodzą, audyty PageSpeed, które zawierają kilka różnych elementów, czyli analizy PageSpeed dla strony głównej, strony kategorii, strony produkty, a z drugiej strony analizujemy takie ogólne dane: ładowania, HTML, pliki JavaScript, pliki CSS, obrazki, filmy, pliki fontów i jeszcze parę i do tego na końcu dostaje się całą listę rzeczy do zrobienia. Taki raport zajmuje między 8 a 13-15 stron w zależności od sklepu i tego, co jest do zrobienia. Później, po takim raporcie, gdy go przygotujemy i omówimy z klientem, ustalamy sobie kolejkę prac — co jest do zrobienia, co warto zrobić w danym sklepie, bo tak jak mówiliście, tych prac może być od groma. Pamiętacie, ile najmniej było prac technicznych po takim audycie? Żeby osiągnąć ten zielone kolory?

Paweł: Najmniej?

G.F: Ale zadałem pytanie!

Łukasz: Nie, raczej nie, najmniej to nie kojarzę. 

Paweł: Nie zawsze jest dużo.

G.F: Tak?

Paweł: Nie zawsze jest dużo, dlatego, że naprawdę bardzo różne sklepy do nas trafiają i nie wszystkie mają te wyniki złe. Czasami wystarczy parę rzeczy poprawić. 

Łukasz: Tak, czasami jest też tak, że duży wpływ ma raptem jedna lub dwie jakieś zmiany i poprawa tych dwóch elementów bardzo mocno zmienia końcowy wynik. Na przykład optymalizacja obrazków to jest moim zdaniem kluczowa rzecz, jeśli chodzi o PageSpeeda, to jest dostosowanie obrazków odpowiednio. 

G.F: Ja tutaj sobie patrzę nasze ostatnie cztery audyty, które realizowaliśmy i rzeczywiście to jest od 10-20 godzin do widzę 40-50 godzin w zależności od sklepu, to już takie największe, które chcą dość do największych wyników, ale też mają dość duże, różne błędy. I teraz…

Paweł: Ja jeszcze Ci przerwę, jeszcze jedna rzecz dopowiem. 

G.F: No, dajesz. 

Paweł: Analiza tych wyników — to tu się często popełnia pewien błąd. 

G.F: To znaczy analiza których wyników, dopytam?

Paweł: Tych z PageSpeeda, ze strony PageSpeed. 

G.F: No, właśnie, tu miałem też się pytać. 

Paweł: Wchodzisz i mówisz, że strona ma 50%. Okej, ale zobacz, że tam jeszcze jest na górze coś takiego jak: „Dane z ostatnich 28 dni”. I teraz trzeba wiedzieć, jak to czytać. Ten wynik, który jest w tym kółeczku, to są wyniki chwilowe, jak Google analizuje Twoją stronę w tym momencie, dla tego urządzenia końcowego, takiego słabego. I to wychodzi jakość. A jak sobie zobaczysz te górne wyniki i spojrzysz, to na przykład dla podanych przez Ciebie sklepów, wcale nie jest najgorzej. Wszystkie/większość jest na zielono. Dlaczego? Dlatego, że to jest realny odczyt z urządzeń końcowych. Google wypuściło kiedyś silnik do Chroma, który zaczął mierzyć tzw. Web Vitals, czyli to są te wskaźniki, które bez naszej wiedzy, kiedy chodzisz sobie po stronie internetowej, one wysyłają do Google informacje, o bieżącej aktualnej wydajności na Twoim komputerze, na Twoim telefonie. I to jest w Edge zaszyte, to jest w Chrome zaszyte i to jest w Firefoxie zaszyte. I te wyniki z górnego pola to są wyniki z realnych użytkowników. Czyli Twoja strona może mieć bardzo słaby wynik w tym kółeczku – chwilowy, Google zmierzył go na starej komórce, że kiepsko wygląda – ale realnie użytkownicy Twojego sklepu mają bardzo dobry User Experience, bo na średnio jakimś tam komputerach czy telefonach, ta strona u nich chodzi zarąbiście. 

G.F: Okej, tutaj doprecyzowując, jak sobie wejdziecie na pagespeed.web.dev (to jest strona po prostu PageSpeed Insights) i wpiszecie sobie dowolną domenę, to u góry możecie wybrać później komórkę lub komputer stacjonarny i w pierwszym polu macie, jakie wrażenia mają użytkownicy — to jest to, o czym mówi Paweł, czyli średnia z ostatnich 28 dni. A później jest, rozpoznaj problemy z wydajnością i to są te chwilowe wyniki tu i teraz, które właśnie dla tych stron, które przytoczyłem, są bardzo niskie, a te wyniki powyżej dużo lepsze, bo w większości są na zielonym lub tam pomarańczowym, chociaż Media Express ma jeden z czynników na polu czerwonym. No właśnie, to chciałem powiedzieć. Jak to czytać? Bo jeśli mamy średnią z 28 dni… 

Paweł: I teraz pytanie, na czym się skupiasz, jako właściciel sklepu. Jeżeli skupiasz się na użytkowniku i chcesz, żeby Twoi klienci szybko przeglądali stronę, szybko znajdowali produkt, żeby to ich nie męczyło, no to wystarczy osiągnąć te górne wyniki na jakimś tam poziomie. Jeżeli byś chciał poprawić sobie indeks, chociaż szczerze przyznam, ja dokładnie nie wiem, czy pozycja w indeksie nie jest szacowana na podstawie tych średnich wyników. Czasami chwilowy wynik można mieć słaby, bo wpływa na niego jeszcze parę rzeczy oraz jest mierzony dla bardzo słabego urządzenia, a średnia wychodzi pozytywna. 

G.F: No właśnie. Okej, to jak już wiemy, jak czytać ten audyt, to robimy. I każdy z Was zajmuje się pewną częścią tego audytu. I Ty Łukasz zajmujesz się Frontem a Ty Paweł bardziej Backendem. Łukasz, powiedz mi, na co Ty zwracasz uwagę, jak robisz analizę tego audytu. 

Łukasz: No to takie kluczowe rzeczy: to są przede wszystkim obrazki, potem są rzeczy, które są ładowane dodatkowo (ilość elementów, która jest ładowana przy wczytywaniu strony) – staramy się jakoś zmniejszyć tę ilość tych elementów, ewentualnie jakoś to tak zmodyfikować, żeby się ładowały szybciej, wydajniej. Dużo jest też modyfikacji związanych z pamięcią podręczną. Co jeszcze z taki kluczowych rzeczy… kluczowe, przynajmniej dla mnie, ja jestem taki, że drażnią mnie takie skaczące strony, na pewno wiecie, o co chodzi. Włączasz sobie jakąś stronę, jakiś artykuł w internecie, na telefonie, zaczynasz skrolować i nagle ładują się w tle jakieś bloki dodatkowe i strona Ci się nagle gdzieś przewinęła i znowu szukasz, gdzie byłeś. To jest bardzo częste zjawisko. Przy wejściu na jakąś stronę, ona się początkowo załaduje, ale za chwilę zaczynają się pokazywać kolejne elementy i one, te elementy, sprawiają, że reszta tego kontentu się przesuwa, troszkę to wszystko się rusza. I to też jest jednym z takich elementów punktowanych przez Google. Co jeszcze? Też bardzo istotne są fonty na stronach — te czcionki ekranowe. Często jest tak, że jest ładowanych ich bardzo dużo, a okazuje się, że są wykorzystywane tylko dwie lub trzy. Też bardzo często spotykam się z problemem ikonek czy jakiś takich malutkich grafik, które są ładowane z całej paczki ikon. W tej paczce ikon, ich jest tam ze 150, a na stronie wykorzystywane są trzy albo cztery. Jakiś koszyk, jakiś ludzik, jakaś lupka. To są takie detale. Można po prostu 90% zbędnych rzeczy wywalić czasami i skrócić znacznie czas ładowania tego wszystkiego. I też ważne są te obrazki. Teraz Google od jakiegoś czasu (czy Google, Google, bo Chrom), w Chromie, ogólnie na silniku Chromium jest wspierane teraz natywne leniwe ładowanie. Kiedyś się wykorzystywało różne takie techniki, skrypty, które sprawiają, że obrazek sobie gdzieś tam się ładuje w tle, później troszeczkę, a teraz jest to wbudowane po prostu w przeglądarkę. Czyli strona się załaduje, a dopiero jak zaczynamy ją przewijać, to sukcesywnie nam się doładowują kolejne obrazki. A nie, że czekamy, aż wszystko się załaduje i dopiero strona jest zdatna do używania. 

G.F: Okej, dzięki. A Paweł, a Ty? Co sprawdzasz?

Paweł: Ja właściwie, można powiedzieć, że to samo, tylko posługuje się głównie analizami tego, co podpowie mi ten analizator PageSpeed. Bo ten sam silnik jest zaszyty, mówię o kontroli, PageSpeed jest zaszyty, w narzędziach deweloperskich w Chromie. Jak się otworzy narzędzia deweloperskie w Chromie, to można sobie bardzo dokładnie przeanalizować, tylko też trzeba wiedzieć, jak to czytać. Chodzi ostatecznie o to, żeby strona się szybko ładowała i szybko wyświetlała. Ważne jest to co się, jakie są rozmiary i w jakiej kolejności. Więc jest bardzo dużo rzeczy do zanalizowania. Wiadomo, że na początku ładuje się HTML, potem powinien się załadować CSS, żeby oscylować stronę, a potem załadować się JS – JaveScript główny, który zapewni funkcjonowanie, interaktywność tej strony, ewentualnie też ją jeszcze doformatuje. Natomiast w praktyce okazuje się, że wygląda to różnie. Są na przykład skrypty zewnętrzne do analizatorów: Google Tag Manager, jakieś Facebooki…

Łukasz: Cross-selling jakiś. 

Paweł: Cross-selling, który zawsze w instrukcjach ma zapisane, że musisz to wstawić w nagłówku strony jak najwyżej. No i klienci tak robią. Efekt jest taki, że ładuje się najpierw HTML, potem te skrypty, a dopiero potem to, co jest potrzebne do wyrenderowania strony. I tak samo, to co już Łukasz powiedział, że Google PageSpeed mierzy czas wyrenderowania tego widocznego obszaru strony. Czyli jeżeli my wchodzimy na jakiś sklep, on się uruchamia i to, co nam się wyrenderuje jest mierzone. A bardzo często jest tak, że jeżeli nie ma tego Lady Loading, tego ładowania leniwego, to zaczynają się ładować wszystkie obrazki, na przykład 300 obrazków 20 produktów, które są poniżej. Są takie rzeczy, że klienci mają na kafelku dwa obrazki, jeden jest po najechaniu myszką. I na przykład jak jest 20 kafelków produktów, to daje nam to już 40 obrazków. I okazuje się, że przy wczytywaniu strony, strona ładuje wszystkie te 40, a my to tak optymalizujemy, żeby załadowało się tylko tamte 5 widocznych, a to, co jest po najechaniu myszką, doładowuje się dopiero po najechaniu myszką. Czasami zdarza się tak, że na przykład klient zrobi sobie takie fajne menu, gdzie po najechaniu otwiera się podmenu i tam są obrazki, a menu zazwyczaj jest bardzo wysoko na stronie.

Łukasz: W kodzie. 

Paweł: W związku, z czym przeglądarka od razu zaczyna ładować te duże obrazki, które są w menu, a które są niewidoczne właściwie. A to, że ładują się obrazki w menu, powoduje, że z opóźnieniem ładują się później obrazki, które są potrzebne do wyświetlenia. Jest bardzo dużo takich elementów. 

Łukasz: No tutaj Paweł na przykład dużą rolę miał przy przerabianiu w ogóle obrazków na nowe formaty – WebP, to też jest dość szeroki temat, można powiedzieć. 

Paweł: Google promuje format WebP. Z tym, czy jest on mniejszy, to czasami różnie bywa, bo to też jest często kosztem jakości i też jest kwestia wielkości tych obrazków. Są tacy klienci, którzy stawiają na stronę wizualną i po prostu potrzebują mieć duże obrazki, ładne, duże kafelki produktów albo duże slidery na całą szerokość strony. I oni takie chcą, bo to jest związane z ich wizją marketingową. I to jest to, co mówisz, że trzeba pójść na jakiś kompromis. Czasami nie warto walczyć o to 100% PageSpeeda, bo na przykład klient ma taką politykę i taki jest jego cel biznesowy, że on chce mieć te duże obrazki, ładnie pokazane z bardzo dużą rozdzielczością, bez pikselozy i on będzie miał słaby PageSpeed, bo to mu się będzie długo ładowało, ale on tak chce, bo tak ma być, bo tak promuje swoją stronę. 

G.F: No właśnie i tutaj dochodzimy do tego, że, jak widzicie Moi Drodzy, jest sporo tych rzeczy i zrobienie tego audytu trochę zajmuje. Tu będzie trochę autoreklama, jak to u nas wygląda, jak my to robimy. U nas taki audyt kosztuje ok. 1,5 tysiąca złotych netto. Jego zrobienie zajmuje parę dni, musimy zaangażować zespół, żeby to dobrze zrobić. W wyniku tego audytu dostajecie nie tylko podsumowanie wszystkich, takich najważniejszych rzeczy, które są do zrobienia, ale także na końcu dla każdego zadania jest określona pracochłonność — mała, średnia, duża, czyli na przykład powyżej 10 godzin dla każdej rzeczy. Komu to zlecić — nam czy komuś innemu (Adminowi od serwera, czy wewnętrznie trzeba to zrobić). I określamy też priorytet, czyli jak ważne to jest, ze względu na PageSpeed i na inne parametry, które tutaj sobie z klientem omawiamy. Zawsze ten raport jest wysyłany, a z drugiej strony jest z klientem omawiany, żeby wytłumaczyć i odpowiedzieć na wiele pytań, bo zazwyczaj takie pytania są i to trzeba sobie wziąć pod rozwagę. Tak jak mówiłem, taki raport ma od 7 do 13-15 stron, w zależności od sytuacji, ile tam jest obrazków, ile jest przykładów. Natomiast sporo później z tego wynika. I tu jest jeszcze ważne, jak często robić taki audyt PageSpeed. Paweł powiesz coś? Łukasz?

Łukasz: Ja bym powiedział, że tak raz w roku może. Tak zdroworozsądkowo. 

Paweł: Ja jestem tego samego zdania. Uważam, że raz w roku należałoby robić taki PageSpeed audyt. Zresztą sprawdzić sobie indeks wydajności to każdy może, bo strona, ta, którą podałeś pagespeed.web.dev jest dostępna, więc obowiązkowo każdy właściciel czy menadżer sklepu, powinien nawet raz w miesiącu wejść, wyklikać sobie dwa, trzy adres ze swojego sklepu — bo to trzeba powiedzieć — i sprawdzić. Jeżeli gdzieś pojawi mu się, że coś jest na żółto, na czerwono, to po prostu powinien zlecić taki audyt.

G.F: Powiedziałeś bardzo ważną rzecz, że: PageSpeed pokazuje wyniki dla danej strony. Czyli jak robimy to dla strony głównej, to jeszcze brakuje nam dla strony kategorii i dla strony produktu i ewentualnie dla jakiejś strony informacyjnej lub jakieś innej specyficznej.

Paweł: tak, my w audycie, robimy dla trzech podstawowych elementów w sklepie internetowym, czyli dla strony głównej, dla strony kategorii i dla strony produktów. Na tych trzech różnych typach podstron, czasami różne problemy wychodzą.

G.F: A jak trzeba to jeszcze więcej, bo niektóre sklepy mają specyficzną budowę i są ważne inne strony i tam też należy to wykonać i na podstawie tego wziąć i sprawdzić. Tutaj trzeba wspomnieć, że w sklepie, jeśli jest dużo zmian, dzieje się dużo, to warto sprawdzać, czy ktoś przez przypadek po drodze nie zgubił szybkości stron, albo coś zostało zmienione i nikt tego nie zauważył. Bo wytestowanie wszystkich możliwych scenariuszy jest problematyczne i czasami wychodzą takie pomyłki. I to się u nas zdarzało, mówiąc otwarcie. Rzadko, ale się zdarzało jednak. Widzimy to też po klientach, którzy do nas przychodzą, że pewne rzeczy nie zostają sprawdzone i jeśli jest dużo zmian to czasami trudno co chwile po każdej zmianie robić poprawki PageSpeed, ale warto jest, raz na jakiś czas zobaczyć co się dzieje. Tutaj Paweł z Łukaszem sugerują raz w roku. Ja nie wiem. Ja bym też podszedł, że warto co miesiąc, co dwa na pewno sobie wyklikać i zobaczyć czy tam się nic przez przypadek nie stało. Dobrze mówię?

Paweł: Zgadza się.

Łukasz: No, szczególnie jak cały czas trwają pracę nad sklepem, ciągle coś tam się dzieje, zmienia, dochodzi. Zmienia się czasami jakaś osoba decyzyjna w zespole, która prowadzi dany sklep i coś przyjdzie tej osobie do głowy czy coś zechce dodać i ktoś inny, kto jest nad tą osobą, tego nie skontroluje i potem może wyjść tak, że trzeba co poprawiać.

G.F: I jest zonk. No właśnie.

Łukasz: Zależy. Są duże firmy, są i małe firmy – w dużych firmach na pewno trudniej na tym zapanować.

G.F: I to jest właśnie to. I tutaj jest jeszcze ważna rzecz, która mi na końcu przyszła, że należy audytu PageSpeed nie mylić z audytem wydajnościowym czy audytem technicznym samego sklepu i paroma innymi, bo są to różne rzeczy. Audyt wydajnościowy jest, wtedy gdy obciążamy sklep bardzo dużym ruchem i nie tylko. Audyt PageSpeed — patrzymy, jak jest teraz. Dobrze mówię Paweł? Czy coś pominąłem? Bo wiesz, ja to jestem kiepski w te klocki, Ty to robisz zazwyczaj.

Paweł: Mniej więcej. Tzn. testy obciążeniowe to jest może jeszcze coś innego. Natomiast ten PageSpeed jest takim testem dymnym, tak że możemy sobie wejść na tę stronę i zobaczyć sobie czy coś tam się na czerwono się nie świeci i wtedy zaczynamy szukać. Dlaczego, my zalecamy raz na rok zrobić nawet jak wszystko może działa jakoś i nawet wyniki są w miarę? Dlatego, że jak robimy ten test PageSpeed to wychodzą różne rzeczy. Po prostu jak się skupimy na tym i dobrze to przeanalizujemy, to się okazuje, że coś jest nie tak w zupełnie innym miejscu, którego nie podejrzewaliśmy. I na przykład wykonanie audytu wydajności czasami jest zaleceniem po audycie PageSpeed. W audycie PageSpeed możemy wykryć, że strona się długo generuje — HTML generowany przez PHP się bardzo długo generuje i na poziomie analizy PageSpeed tutaj nie ma sensu ani zasobności, żeby się na tym skupiać, ale jednym z wniosków jest: trzeba wykonać analizę wydajności, bo coś jest nie tak. Jest za wolno. Serwer za wolno generuje sklep. I nie robimy tego w analizie PageSpeed, żeby ona nie była za droga, bo audyt wydajności to jest kolejny level jest tam trochę więcej roboty też, bo trzeba sprawdzić serwer, trzeba przeanalizować, co się dzieje na serwerze, zrobić debug plików PHP, zrobić analizę konfiguracji (my tu mówimy o PrestaShop, bo zajmujemy się PrestShopem, tak więc analizę konfiguracji PrestaShop), wiele różnych elementów. I wtedy już bardziej w techniczne rzeczy wchodzimy.

G.F: Więc może tym ostatnim słowem od Pawła zakończmy ten odcinek, bo nie ma co rozwijać tego tematu, a już gadamy 35 minut. Może coś się wytnie, więc tego nie zobaczycie Drodzy Słuchacze, bo mieliśmy różne historie, jak to w życiu bywa. Chłopaki, koniec dnia. Coś byście jeszcze dopowiedzieli na koniec? Czy pozdrawiamy wszystkich dookoła?

Paweł: My z Łukaszem o PageSpeedzie to jeszcze możemy mówić.

Łukasz: Tak!

G.F: Ja myślę, że na następny odcinek musimy wziąć jakiś konkretny case, bo dzisiaj to takie podstawy podstaw. Może na naszym kanale Prosta Presta zrobimy jakieś case study z jakiegoś sławnego sklepu.

Łukasz: Właśnie tak chciałem wtrącić, bo tak mi w którymś momencie Paweł wszedł w słowo, ale mieliśmy taki przypadek, że podniesienie PageSpeeda wiązało się praktycznie z przebudową całej konstrukcji strony, bo była, oparta o tzw. Elementora. A Elementor jest z natury niezoptymalizowany i ma strasznie dużo „śmieciokodu” i zrobienie tego samego w sposób czysty, prosty, tak jak należy, przyniosło dopiero oczekiwane efekty, ale pracy przy tym przez to było bardzo, bardzo dużo.

G.F: I tym optymistycznym akcentem, a może nie, zakończymy na dzisiaj. Dzięki wielkie chłopaki za podzielenie się i za wyjście naprzeciw kamery i opowiedzenie paru słów. Wiem, że to nie jest dla Was proste, bo to chyba pierwszy raz, a może nie. Więc dzięki wielkie i pozdrawiam wszystkich przed radioodbiornikami i telefonami. I do usłyszenia! Hej!

Paweł: No cześć!

Łukasz: Dzięki. Cześć!