PageSpeed Insights w PrestaShop – jak czytać wyniki i poprawić szybkość sklepu?

PageSpeed Insights pomaga ocenić, jak szybko ładuje się konkretny adres sklepu PrestaShop i jakie problemy mogą pogarszać doświadczenia użytkowników. Narzędzie nie wykonuje jednak pełnego audytu sklepu, nie zna jego architektury i nie potrafi samodzielnie naprawić znalezionych błędów.

Największym błędem jest traktowanie wyniku PageSpeed jako celu samego w sobie. Sklep może uzyskać 95 punktów, a nadal wolno otwierać kategorie lub dodawać produkty do koszyka. Może też osiągać 70–80 punktów i działać płynnie dla większości klientów.

Dlatego wynik trzeba interpretować razem z danymi rzeczywistych użytkowników, metrykami Core Web Vitals, czasem odpowiedzi serwera oraz zachowaniem najważniejszych podstron sklepu.

W skrócie

PageSpeed Insights pokazuje dwa różne rodzaje danych:

• dane laboratoryjne, czyli wynik pojedynczego testu przeprowadzonego w symulowanym środowisku,
• dane rzeczywistych użytkowników, zbierane w ramach Chrome User Experience Report.

W przypadku sklepu PrestaShop najważniejsze nie jest osiągnięcie 100 punktów. Priorytetem powinno być zapewnienie dobrych wartości LCP, INP i CLS oraz sprawnego działania stron kategorii, produktów, koszyka i procesu zakupowego.

Za dobre wartości Core Web Vitals Google uznaje:

Wartości są oceniane na podstawie 75. percentyla, czyli z uwzględnieniem także użytkowników korzystających z wolniejszych urządzeń i połączeń.

Co to jest PageSpeed Insights?

PageSpeed Insights, często określane skrótem PSI, to bezpłatne narzędzie Google służące do badania wydajności pojedynczych stron internetowych na urządzeniach mobilnych i komputerach.

Po wpisaniu adresu strony narzędzie analizuje między innymi:

• czas wyświetlenia najważniejszej treści,
• ilość kodu JavaScript blokującego przeglądarkę,
• stabilność elementów podczas ładowania,
• wielkość obrazów i pozostałych zasobów,
• czas odpowiedzi serwera,
• sposób ładowania CSS, fontów i skryptów zewnętrznych,
• dostępność, SEO i wybrane dobre praktyki techniczne.

PageSpeed Insights nie analizuje całego sklepu jednocześnie. Każdy wprowadzony adres jest osobnym testem. Wynik strony głównej nie mówi więc, jak działa karta produktu, kategoria, wyszukiwarka, koszyk czy finalizacja zamówienia.

Google wykorzystuje w PageSpeed Insights dane laboratoryjne generowane przez Lighthouse oraz dane terenowe pochodzące od rzeczywistych użytkowników Chrome.

Dane laboratoryjne a dane rzeczywistych użytkowników

Rozróżnienie tych dwóch źródeł jest kluczowe dla prawidłowej oceny sklepu PrestaShop.

Dane laboratoryjne

Dane laboratoryjne powstają podczas pojedynczego, kontrolowanego testu. Narzędzie symuluje określone urządzenie, przepustowość sieci i wydajność procesora.

Ta część raportu zawiera kolorowy wynik od 0 do 100:

• 90–100 — wynik dobry,
• 50–89 — wynik wymagający poprawy,
• 0–49 — wynik słaby.

Dane laboratoryjne dobrze sprawdzają się podczas diagnozowania zmian. Można na przykład wykonać test przed wdrożeniem nowego modułu i po jego uruchomieniu.

Nie należy jednak traktować pojedynczego pomiaru jako niepodważalnego wyniku. Rezultat może zmieniać się między kolejnymi testami z powodu obciążenia serwera, sposobu routingu ruchu, dynamicznych reklam, skryptów zewnętrznych lub chwilowej dostępności zasobów.

Dane rzeczywistych użytkowników

Dane terenowe pokazują, jak stronę odczuwali prawdziwi użytkownicy Chrome w ciągu ostatnich 28 dni. Obejmują różne urządzenia, połączenia internetowe i warunki korzystania ze sklepu.

Właśnie tutaj oceniane są Core Web Vitals.

Dane rzeczywistych użytkowników są ważniejsze przy ocenie doświadczenia klientów, ale mają jedną wadę: zmiany nie pojawiają się natychmiast. Nawet po poprawieniu strony potrzeba czasu, aby nowe pomiary zastąpiły dane z poprzedniego okresu.

Jeżeli podstrona ma zbyt mało wizyt, PageSpeed Insights może pokazać dane dla całej domeny zamiast dla konkretnego adresu. Przy jeszcze mniejszej liczbie próbek sekcja danych rzeczywistych użytkowników może nie być dostępna.

Jakie metryki PageSpeed są najważniejsze?

W raporcie można znaleźć wiele skrótów i wskaźników. Nie wszystkie mają jednak takie samo znaczenie.

LCP — Largest Contentful Paint

LCP mierzy czas potrzebny do wyświetlenia największego istotnego elementu widocznego na ekranie.

W sklepie PrestaShop takim elementem często jest:

• główny baner,
• zdjęcie produktu,
• grafika kategorii,
• duży blok tekstowy,
• pierwszy slajd karuzeli.

Dobra wartość LCP nie powinna przekraczać 2,5 sekundy.

Problemy z LCP mogą wynikać z:

• zbyt ciężkiego zdjęcia głównego,
• późnego wykrycia obrazu przez przeglądarkę,
• wolnej odpowiedzi serwera,
• kodu CSS blokującego wyświetlenie strony,
• niewłaściwego lazy loadingu,
• slidera, który czeka na uruchomienie JavaScriptu,
• fontu blokującego wyświetlenie tekstu.

W PrestaShop częstym błędem jest objęcie lazy loadingiem głównego obrazu produktu albo banera znajdującego się od razu na ekranie. Przeglądarka zaczyna wtedy pobierać najważniejszy obraz zbyt późno.

INP — Interaction to Next Paint

INP mierzy szybkość reakcji strony na działanie użytkownika.

Może to być:

• otwarcie menu,
• wybór wariantu produktu,
• kliknięcie filtra,
• zmiana liczby sztuk,
• rozwinięcie opisu,
• przejście do kolejnego slajdu,
• dodanie produktu do koszyka.

Dobra wartość INP wynosi maksymalnie 200 milisekund.

Wysoki INP jest zwykle związany z nadmiarem kodu JavaScript lub wykonywaniem zbyt wielu operacji w głównym wątku przeglądarki.

W sklepach PrestaShop warto wtedy sprawdzić między innymi:

• rozbudowane menu,
• filtry fasetowe,
• moduły wariantów,
• kalkulatory cen,
• konfiguratory produktów,
• slidery,
• systemy rekomendacji,
• skrypty analityczne,
• czaty i narzędzia marketing automation.

INP zastąpiło wcześniej stosowaną metrykę FID jako jeden z trzech głównych wskaźników Core Web Vitals.

CLS — Cumulative Layout Shift

CLS mierzy, jak bardzo układ strony przesuwa się podczas jej ładowania.

Użytkownik może na przykład próbować kliknąć produkt, ale w ostatniej chwili nad listą pojawi się baner i przesunie cały układ. Takie sytuacje są irytujące, utrudniają zakupy i mogą powodować przypadkowe kliknięcia.

Dobra wartość CLS nie powinna przekraczać 0,1.

Najczęstsze przyczyny problemów z CLS w PrestaShop to:

• brak określonych wymiarów obrazów,
• późno ładowane fonty,
• banery bez zarezerwowanej przestrzeni,
• pasek darmowej dostawy dodawany po załadowaniu strony,
• dynamicznie wczytywane ceny lub raty,
• moduł opinii zmieniający wysokość sekcji,
• komunikat dotyczący plików cookies,
• elementy personalizowane po stronie JavaScript.

TTFB — Time to First Byte

TTFB mierzy czas od wysłania żądania do otrzymania pierwszego fragmentu odpowiedzi serwera.

Nie jest obecnie jednym z trzech Core Web Vitals, ale w PrestaShop ma bardzo duże znaczenie diagnostyczne.

Jeżeli serwer potrzebuje dwóch lub trzech sekund, aby rozpocząć przesyłanie dokumentu HTML, poprawa zdjęć lub minimalizacja CSS nie rozwiąże głównego problemu.

Wysoki TTFB może wskazywać na:

• wolne zapytania do bazy danych,
• przeciążony serwer,
• nieprawidłową konfigurację PHP,
• moduł wykonujący kosztowne operacje,
• integrację oczekującą na odpowiedź zewnętrznego API,
• niewłaściwą konfigurację cache,
• rozbudowane override’y,
• zbyt dużą liczbę operacji wykonywanych w hookach.

TBT — Total Blocking Time

TBT jest metryką laboratoryjną pokazującą, jak długo główny wątek przeglądarki był blokowany przez długie zadania.

Wysoki TBT często idzie w parze z problemami z interaktywnością. Może wskazywać na nadmierną ilość JavaScriptu lub skrypty wykonujące zbyt wiele operacji podczas uruchamiania strony.

Czy wynik 100/100 w PageSpeed Insights jest potrzebny?

Nie. Wynik 100/100 nie powinien być głównym celem prac nad sklepem internetowym.

Sam Google wskazuje, że osiągnięcie idealnych 100 punktów jest bardzo trudne i nie jest oczekiwane. Im wyższy wynik, tym więcej pracy potrzeba do uzyskania każdego kolejnego punktu. Poprawa wyniku z 99 do 100 może wymagać podobnego wysiłku jak podniesienie go z 90 do 94.

W sklepie e-commerce należy również zachować funkcje potrzebne do prowadzenia sprzedaży. PrestaShop może korzystać z:

• analityki,
• systemu zgód,
• modułu płatności,
• narzędzi remarketingowych,
• porównywarek cen,
• systemu opinii,
• czatu,
• personalizacji,
• integracji z zewnętrznymi platformami.

Część z tych elementów obniża wynik testu, ale może być istotna biznesowo.

Właściwym celem nie jest więc usuwanie wszystkiego, co obniża punktację. Należy określić, które elementy generują wartość, a które tylko zwiększają ilość kodu i liczbę żądań.

Znacznie lepszym celem niż „100 punktów” jest:

• poprawne przejście Core Web Vitals,
• szybkie pojawienie się głównej treści,
• płynna reakcja menu, filtrów i wariantów,
• krótki czas odpowiedzi serwera,
• stabilny układ,
• sprawne działanie koszyka,
• brak pogorszenia konwersji po wdrożeniu zmian.

Dlaczego wynik mobilny jest niższy od desktopowego?

Niższy wynik mobilny jest typową sytuacją.

Test mobilny symuluje słabsze urządzenie i bardziej ograniczone połączenie. Skrypty, które na szybkim komputerze wykonują się niemal niezauważalnie, na telefonie mogą blokować stronę przez znacznie dłuższy czas.

Różnica między urządzeniami może ujawnić:

• zbyt dużą ilość JavaScriptu,
• ciężkie zdjęcia ładowane również na telefonach,
• źle zaprojektowane menu mobilne,
• rozbudowane slidery,
• niepotrzebne animacje,
• zbyt wiele narzędzi marketingowych,
• elementy desktopowe ukryte tylko przez CSS, ale nadal pobierane.

Nie należy więc próbować „wyrównać” wyniku mobilnego i desktopowego za wszelką cenę. Trzeba znaleźć konkretne zasoby i procesy, które najbardziej obciążają słabsze urządzenia.

Najczęstsze przyczyny słabego wyniku w PrestaShop

PageSpeed Insights pokazuje objawy techniczne. Nie zawsze poprawnie wskazuje ich źródło w architekturze sklepu.

W praktyce problem zwykle znajduje się w jednym lub kilku poniższych obszarach.

Wolna odpowiedź serwera

Jeżeli wygenerowanie strony trwa zbyt długo, przeglądarka późno otrzymuje kod HTML i późno rozpoczyna pobieranie pozostałych zasobów.

Przyczyna może znajdować się w bazie danych, konfiguracji PHP, wydajności hostingu, kodzie modułów albo komunikacji z zewnętrznymi systemami.

Samo włączenie kompresji obrazów nie rozwiąże wtedy głównego problemu.

Zbyt wiele modułów wykonujących kod na każdej stronie

PrestaShop wykorzystuje system hooków. Moduł podpięty do popularnego hooka może uruchamiać się na stronie głównej, kategoriach, produktach i wielu innych podstronach.

Nie każdy aktywny moduł musi być problemem. Ważniejsze jest to, co wykonuje podczas generowania strony.

Szczególnej uwagi wymagają moduły:

• pobierające dane z zewnętrznego API,
• przeliczające ceny,
• generujące rekomendacje,
• synchronizujące stany,
• modyfikujące koszyk,
• wykonujące rozbudowane zapytania SQL,
• wstrzykujące biblioteki JavaScript na każdej stronie.

Ciężki lub przestarzały szablon

Szablon może zawierać wiele bibliotek, które są pobierane nawet wtedy, gdy dana funkcja nie jest wykorzystywana na konkretnej podstronie.

Przykładowo karta produktu może ładować kod slidera ze strony głównej, bibliotekę galerii używaną tylko na blogu i style modułu, którego element nie występuje w danym widoku.

Problemem może być także bardzo duży DOM, nadmiar zagnieżdżonych elementów oraz rozbudowane komponenty budowane przez JavaScript.

Obrazy niedopasowane do miejsca wyświetlania

Zdjęcie o szerokości 2500 pikseli nie powinno być pobierane, jeżeli w rzeczywistości wyświetla się w polu o szerokości 500 pikseli.

Warto zadbać o:

• właściwe rozmiary miniaturek PrestaShop,
• format WebP lub AVIF tam, gdzie jest obsługiwany,
• kompresję,
• responsywne warianty obrazów,
• prawidłowe wartości width i height,
• lazy loading elementów znajdujących się poza pierwszym ekranem.

Nie należy natomiast opóźniać ładowania najważniejszego obrazu odpowiadającego za LCP.

Skrypty zewnętrzne

Znaczną część problemów mogą powodować zasoby, które nie znajdują się bezpośrednio na serwerze sklepu.

Dotyczy to między innymi:

• Google Tag Managera,
• narzędzi analitycznych,
• pikseli reklamowych,
• czatów,
• map,
• systemów opinii,
• widgetów social media,
• systemów rekomendacji,
• narzędzi do nagrywania sesji,
• banerów zgód.

Nie oznacza to, że wszystkie należy usunąć. Trzeba jednak sprawdzić ich realne wykorzystanie, sposób uruchamiania i moment ładowania.

Nieprawidłowo skonfigurowany cache

Cache może znacząco skrócić czas generowania strony, ale tylko wtedy, gdy jest dopasowany do sposobu działania sklepu.

Niewłaściwa konfiguracja może powodować:

• wyświetlanie nieaktualnych cen,
• problemy z koszykiem,
• błędne informacje o dostępności,
• mieszanie języków lub walut,
• brak aktualizacji treści,
• pominięcie części użytkowników,
• tylko pozorną poprawę testu strony głównej.

W e-commerce nie należy wdrażać pełnego cache bez analizy elementów dynamicznych i kontekstu klienta.

Jak prawidłowo przetestować sklep PrestaShop?

Jeden test strony głównej nie wystarczy do oceny wydajności całego sklepu.

1. Sprawdź kilka typów podstron

Minimalny zakres powinien obejmować:

• stronę główną,
• kategorię z dużą liczbą produktów,
• kartę prostego produktu,
• produkt z wariantami,
• stronę wyników wyszukiwania,
• blog lub poradnik, jeżeli występuje w sklepie.

Koszyk i checkout wymagają dodatkowych testów, ponieważ ich zawartość zależy od sesji, danych klienta, dostawy i wybranej metody płatności. Publiczny test pojedynczego adresu nie zastąpi pomiaru całej ścieżki zakupowej.

2. Zbadaj wersję mobilną

To właśnie słabsze telefony częściej ujawniają problemy z JavaScriptem, obrazami i interaktywnością.

Wynik desktopowy może wyglądać dobrze, mimo że użytkownicy mobilni nadal mają trudności z otwieraniem menu, zmianą wariantu lub korzystaniem z filtrów.

3. Wykonaj kilka pomiarów

Pojedynczy wynik może być przypadkowo lepszy lub gorszy. Warto przeprowadzić co najmniej trzy testy tego samego adresu i porównać przede wszystkim wartości konkretnych metryk.

4. Oddziel dane laboratoryjne od terenowych

Dane laboratoryjne pokazują bieżący test i pomagają znaleźć problemy.

Dane terenowe pokazują doświadczenia użytkowników z poprzednich 28 dni. Po wdrożeniu zmian nie należy oczekiwać, że natychmiast zmienią kolor na zielony.

5. Porównuj te same warunki

Porównując wynik przed wdrożeniem i po wdrożeniu, używaj:

• tego samego adresu,
• tej samej wersji urządzenia,
• podobnej pory testu,
• podobnego stanu cache,
• tej samej wersji sklepu.

Inaczej można błędnie przypisać zmianie technicznej różnicę wynikającą z warunków pomiaru.

Jak czytać sekcję „Możliwości” i „Diagnostyka”?

PageSpeed Insights może wyświetlać potencjalne oszczędności czasu lub transferu. Nie należy jednak automatycznie realizować zaleceń od góry raportu do dołu.

Najpierw trzeba ustalić, z którą metryką związany jest problem.

Jeżeli słabe jest LCP, należy sprawdzić:

• jaki element jest wskazany jako LCP,
• kiedy przeglądarka zaczyna go pobierać,
• czy czeka na CSS lub JavaScript,
• czy obraz ma właściwy rozmiar,
• czy serwer nie odpowiada zbyt wolno.

Jeżeli problemem jest TBT lub INP, należy przeanalizować:

• długie zadania JavaScript,
• biblioteki firm trzecich,
• obsługę menu, filtrów i wariantów,
• skrypty uruchamiane już podczas pierwszego renderowania.

Jeżeli słaby jest CLS, trzeba znaleźć konkretne elementy zmieniające położenie podczas ładowania.

Największe potencjalne oszczędności wskazane w raporcie nie zawsze przekładają się na największą poprawę biznesową. Usunięcie ważnego systemu analitycznego może podnieść wynik o kilka punktów, ale utrudnić ocenę kampanii i sprzedaży.

Co można poprawić samodzielnie?

Część prostych problemów można ograniczyć bez przebudowy sklepu.

Właściciel sklepu może między innymi:

• usunąć nieużywane slidery i banery,
• zmniejszyć wagę nowych zdjęć,
• sprawdzić rozmiary przesyłanych grafik,
• zrezygnować z nieużywanych narzędzi marketingowych,
• ograniczyć liczbę fontów i ich odmian,
• sprawdzić, czy obrazy poza ekranem korzystają z lazy loadingu,
• usunąć moduły, które rzeczywiście nie są wykorzystywane,
• skontrolować wynik po wdrożeniu nowego dodatku.

Przed wyłączeniem modułu trzeba jednak sprawdzić jego powiązania z koszykiem, płatnościami, wysyłką, synchronizacją i analityką.

Samo kliknięcie „wyczyść pamięć podręczną” może chwilowo zmienić sposób działania sklepu, ale nie jest trwałym rozwiązaniem problemów wydajnościowych.

Kiedy potrzebna jest analiza techniczna?

Pomoc programisty będzie potrzebna, jeżeli problem dotyczy:

• długiego czasu generowania HTML,
• wolnych zapytań do bazy danych,
• nadmiernego obciążenia procesora,
• błędów 503,
• niestabilnego checkoutu,
• kodu modułów,
• override’ów,
• sposobu wykonywania hooków,
• konfiguracji serwera,
• rozdzielania CSS i JavaScriptu,
• ładowania zasobów tylko na wymaganych podstronach,
• problemów z cache,
• integracji z systemami zewnętrznymi,
• przestarzałego szablonu.

W takiej sytuacji sam raport PageSpeed Insights jest jedynie punktem wyjścia. Potrzebna jest analiza logów, zapytań SQL, czasów wykonania kodu, zapytań sieciowych i zachowania sklepu pod obciążeniem.

Jeżeli sklep ma problemy wykraczające poza pojedynczy wynik PageSpeed, sprawdź zakres naszej usługi optymalizacji PrestaShop. Obejmuje ona analizę wydajności aplikacji, modułów, bazy danych, serwera oraz kluczowych procesów sprzedażowych.

Czy szybki sklep zawsze będzie miał wysoki wynik?

Nie zawsze.

Na wynik testu mogą wpływać elementy wymagane przez biznes, takie jak narzędzia zgód, płatności, analityka czy systemy marketingowe. Wynik może też zmieniać się pomiędzy testami bez wprowadzania zmian w sklepie.

Możliwa jest również odwrotna sytuacja: strona główna osiąga wysoki wynik, ale klient długo czeka na:

• zastosowanie filtra,
• zmianę wariantu,
• przeliczenie ceny,
• dodanie produktu do koszyka,
• wybór dostawy,
• przejście między etapami checkoutu.

PageSpeed Insights bada konkretną stronę, a nie pełne zachowanie aplikacji e-commerce.

Dlatego ocenę należy uzupełnić o:

• pomiar czasu odpowiedzi backendu,
• analizę zapytań AJAX,
• test procesu zakupowego,
• monitoring błędów,
• dane z Search Console,
• dane analityczne,
• obserwację współczynnika odrzuceń i konwersji,
• testy na rzeczywistych urządzeniach.

Czy szybkość sklepu wpływa na SEO?

Szybkość i Core Web Vitals są elementami szerzej rozumianego doświadczenia użytkownika. Google rekomenduje osiąganie dobrych wartości tych wskaźników zarówno ze względu na użytkowników, jak i wyniki wyszukiwania. Nie oznacza to jednak, że sama poprawa PageSpeed automatycznie zapewni wysokie pozycje.

Nadal kluczowe są między innymi:

• dopasowanie strony do intencji wyszukiwania,
• jakość i kompletność treści,
• architektura informacji,
• linkowanie wewnętrzne,
• dostępność produktów,
• poprawna indeksacja,
• reputacja domeny,
• linki zewnętrzne.

Szybki sklep z niedopracowaną ofertą nie musi wyprzedzić wolniejszego konkurenta, który lepiej odpowiada na potrzeby użytkownika.

Z drugiej strony słaba wydajność może utrudniać korzystanie ze sklepu, zmniejszać liczbę przeglądanych stron i powodować porzucanie zakupów.

Podsumowanie

PageSpeed Insights jest wartościowym narzędziem diagnostycznym, ale nie należy sprowadzać oceny sklepu PrestaShop do jednej liczby.

Najpierw trzeba sprawdzić:

1. Czy raport zawiera dane rzeczywistych użytkowników?
2. Która metryka Core Web Vitals nie spełnia zaleceń?
3. Jaki konkretny element odpowiada za słaby wynik?
4. Czy problem dotyczy serwera, kodu, obrazów czy skryptów zewnętrznych?
5. Czy podobny problem występuje również na kategoriach, produktach i w koszyku?
6. Czy proponowana zmiana nie pogorszy sprzedaży albo działania integracji?

Dopiero po takiej analizie można przygotować sensowny plan działania.

Jeżeli sklep wolno generuje strony, ma problemy z bazą danych, modułami, Core Web Vitals lub stabilnością procesu zakupowego, sama analiza PageSpeed może nie wystarczyć. W takich przypadkach wykonujemy profesjonalną optymalizację sklepu PrestaShop, rozpoczynając od ustalenia rzeczywistego źródła problemu, a nie od przypadkowego instalowania kolejnych modułów.

Najczęstsze pytania o PageSpeed Insights w PrestaShop