PageSpeed Insights pokazuje 40/100 — co z tym zrobić w sklepie
To jedno z najczęstszych pytań, jakie dostaję od właścicieli sklepów: „wpisałem adres w PageSpeed Insights, wyszło 38 na czerwono — czy przez to nie mam ruchu?". Odpowiedź brzmi: prawdopodobnie nie, ale to i tak warto naprawić. Wyjaśniam, co ten test naprawdę mierzy, które elementy realnie spowalniają sklep i w jakiej kolejności je poprawiać, żeby nie zmarnować budżetu na kosmetykę.
Spis treści
Co PageSpeed Insights naprawdę mierzy
Wynik od 0 do 100, który widzisz na górze raportu, to ocena syntetyczna — wyliczona z symulacji ładowania strony na średniej klasy telefonie przy spowolnionym łączu. To nie jest pomiar tego, jak Twój sklep działa u realnych klientów.
Pod spodem są trzy wskaźniki, które faktycznie mają znaczenie — Core Web Vitals:
| Wskaźnik | Co mierzy | Dobry wynik | Typowy winowajca w sklepie |
|---|---|---|---|
| LCP Largest Contentful Paint |
Kiedy pojawia się największy element widoczny na starcie | do 2,5 s | Baner na stronie głównej, zdjęcie produktu, wolny serwer |
| INP Interaction to Next Paint |
Jak szybko strona reaguje na kliknięcie | do 200 ms | Nadmiar skryptów: aplikacje, czaty, piksele, filtry |
| CLS Cumulative Layout Shift |
Ile treść „skacze" podczas ładowania | poniżej 0,1 | Obrazy bez wymiarów, baner cookies, doładowywane banery |
INP zastąpił dawny FID. Jeśli czytasz starszy poradnik, który mówi o First Input Delay — jest nieaktualny. INP jest znacznie trudniejszy do oszukania, bo mierzy reakcję na wszystkie interakcje w trakcie wizyty, a nie tylko pierwszą. W sklepach z rozbudowanymi filtrami i wieloma aplikacjami to zwykle najsłabszy z trzech wskaźników.
Dlaczego Twój wynik skacze o 30 punktów
Odśwież raport trzy razy pod rząd i prawdopodobnie zobaczysz 38, potem 52, potem 44. To normalne i nie znaczy, że test jest zepsuty — dane laboratoryjne pochodzą z pojedynczej symulacji, a ta zależy od chwilowego obciążenia serwera i tego, co akurat robi Twoja platforma.
Dlatego na ocenę syntetyczną patrz tylko orientacyjnie. Liczy się sekcja wyżej: „Sprawdź dane rzeczywistych użytkowników" (Chrome UX Report). To pomiar zebrany od ludzi, którzy faktycznie odwiedzili Twój sklep w ciągu ostatnich 28 dni — i to jego używa Google.
Jeśli tej sekcji w ogóle nie widzisz, oznacza to zwykle, że sklep ma za mało ruchu, żeby dane się uzbierały. Wtedy zostają wyłącznie dane laboratoryjne i tym bardziej nie warto się nimi przejmować ponad miarę.
Testuj to, co ma znaczenie. Większość ludzi testuje stronę główną, a ruch z wyszukiwarki wchodzi na kategorie i karty produktów. Zbadaj po jednym adresie z każdego typu — wyniki potrafią się drastycznie różnić, bo to zupełnie inne szablony.
Czy prędkość realnie wpływa na pozycje
Powiem to wprost, bo w tej sprawie krąży sporo nieporozumień: Core Web Vitals to bardzo słaby czynnik rankingowy. Strona z wynikiem 35, ale lepiej odpowiadająca na zapytanie, pobije stronę z wynikiem 95 i słabą treścią. Nie widziałem sklepu, który wskoczył na pierwszą stronę wyłącznie dzięki optymalizacji prędkości.
Prędkość ma natomiast bardzo realny wpływ na pieniądze, i to jest właściwy powód, żeby się nią zająć:
- Konwersja — każda sekunda oczekiwania to porzucone koszyki. Na urządzeniach mobilnych, gdzie dziś jest większość ruchu, efekt jest najmocniejszy.
- Koszt reklamy — wolna strona docelowa obniża jakość reklamy w Google Ads, co bezpośrednio podnosi stawkę za kliknięcie. Tu przekłada się to na fakturę co miesiąc.
- Budżet indeksowania — wolny serwer oznacza, że robot odwiedza mniej stron w tym samym czasie. W dużym sklepie to realny problem z indeksacją.
Wniosek praktyczny: optymalizuj prędkość dla konwersji i kosztu reklamy, nie dla pozycji. Jeśli sklep nie ma ruchu, przyczyny szukaj w treści i strukturze, nie w wyniku PageSpeed — pisałem o tym przy diagnostyce spadków widoczności.
Co faktycznie spowalnia sklep
Kolejność od najczęstszych, na podstawie sklepów, które audytowałem:
1. Obrazy — prawie zawsze numer jeden
Zdjęcia produktowe wgrane w oryginalnej rozdzielczości z aparatu, serwowane w JPG zamiast WebP, bez podanych wymiarów w kodzie. Baner na stronie głównej ważący 2 MB potrafi sam w sobie zepsuć LCP. To jednocześnie najłatwiejsza rzecz do naprawienia i największy zysk.
2. Aplikacje i skrypty zewnętrzne
Czat, popup z rabatem, widget opinii, dwa piksele reklamowe, mapa ciepła, narzędzie do testów A/B. Każde z nich dokłada skrypt, który blokuje reakcję strony na kliknięcia — czyli psuje INP. W sklepach regularnie znajduję aplikacje zainstalowane rok temu „na próbę" i nigdy nieużywane, a nadal ładujące swój kod przy każdej wizycie.
3. Szablon
Rozbudowane szablony ładują biblioteki, których dana strona wcale nie używa: karuzele, animacje, ikony, kilka wariantów czcionek. Przy platformach SaaS to najczęściej element, na który masz najmniejszy wpływ — i najczęstszy powód, dla którego sklep nie przekroczy pewnego pułapu.
4. Serwer i hosting
Czas odpowiedzi serwera (TTFB) powyżej 600 ms oznacza, że przeglądarka czeka, zanim w ogóle zacznie cokolwiek rysować. W modelu SaaS to kwestia po stronie dostawcy. Przy sklepach na własnym hostingu (WooCommerce, PrestaShop) to zwykle najtańszy pakiet współdzielony.
5. Czcionki
Cztery kroje ładowane z zewnętrznego serwera, każdy w kilku wariantach grubości. Drobiazg, ale dokłada się do CLS, bo tekst przeskakuje w momencie podmiany czcionki.
Co da się naprawić na Shoper i IdoSell, a czego nie
To jest część, której nie znajdziesz w ogólnych poradnikach — a decyduje o tym, czy warto w ogóle zaczynać.
| Element | Na SaaS (Shoper / IdoSell) | Efekt |
|---|---|---|
| Kompresja i format obrazów | TAK — masz pełną kontrolę | Duży |
| Usunięcie zbędnych aplikacji | TAK — przegląd listy i odinstalowanie | Duży (INP) |
| Wymiary obrazów w kodzie | CZĘŚCIOWO — zależy od szablonu | Średni (CLS) |
| Ograniczenie liczby czcionek | TAK — w ustawieniach szablonu | Średni |
| Odchudzenie szablonu z bibliotek | CZĘŚCIOWO — tylko własny szablon | Duży |
| Czas odpowiedzi serwera | NIE — to infrastruktura dostawcy | Duży |
| Sposób ładowania skryptów platformy | NIE | Średni |
Praktyczny wniosek: na platformie SaaS realistycznym celem jest zielony wynik Core Web Vitals w danych rzeczywistych użytkowników, a nie 90+ w ocenie syntetycznej. Do tej drugiej liczby zwykle nie dojdziesz i nie warto za to płacić — sufit wyznacza platforma. Jeśli uderzasz w ten sufit i to realnie kosztuje Cię sprzedaż, temat przenosi się z optymalizacji na wybór platformy.
Kolejność napraw — od największego zysku
- Przejrzyj listę zainstalowanych aplikacji i usuń te, których nie używasz. Godzina pracy, zero kosztów, natychmiastowa poprawa INP. Zacznij tutaj zawsze.
- Zoptymalizuj obrazy — WebP, rozsądna rozdzielczość (baner nie potrzebuje 4000 px szerokości), lazy loading poza pierwszym ekranem. Największy pojedynczy zysk na LCP.
- Podaj wymiary obrazów w kodzie — naprawia CLS, czyli irytujące przeskakiwanie treści pod palcem użytkownika.
- Ogranicz czcionki do dwóch krojów i niezbędnych grubości.
- Sprawdź baner cookies — bardzo częsty i niedoceniany sprawca CLS oraz opóźnień, bo ładuje się jako jeden z pierwszych i przesuwa całą treść. Przy okazji zweryfikuj, czy nie psuje Ci pomiaru sprzedaży — źle wdrożony Consent Mode potrafi zabrać połowę danych o konwersjach.
- Dopiero teraz rozmawiaj o ingerencji w szablon albo zmianie hostingu.
Punkty 1–5 to zwykle jeden–dwa dni pracy i wystarczają, żeby wyjść z czerwonego na pomarańczowy albo zielony w danych rzeczywistych. Punkt 6 kosztuje wielokrotnie więcej i ma sens dopiero wtedy, gdy reszta jest zrobiona.
Kiedy prędkość nie jest Twoim problemem
Trzy sytuacje, w których optymalizacja PageSpeed to zły priorytet:
Sklep nie ma ruchu z Google w ogóle. Jeśli w Search Console widzisz kilkadziesiąt wyświetleń miesięcznie, problemem nie jest prędkość, tylko to, że nie masz na czym się wyświetlać. Zacznij od kategorii, tytułów i treści — struktura kategorii i filtrów daje tu nieporównanie więcej.
Ruch spadł nagle. Prędkość nie zmienia się z dnia na dzień. Nagły spadek ma inną przyczynę i szukanie jej w PageSpeed to strata czasu — sprawdź listę ośmiu najczęstszych przyczyn.
Dane rzeczywistych użytkowników są zielone, a ocena syntetyczna czerwona. To bardzo częsty przypadek i oznacza po prostu, że u Twoich klientów sklep działa dobrze. Wynik syntetyczny jest wtedy ciekawostką, nie problemem do rozwiązania.
Najczęstsze pytania
Jaki wynik PageSpeed jest dobry dla sklepu internetowego?
Dla sklepu na platformie SaaS realistyczny cel to 50–70 w ocenie syntetycznej na urządzeniach mobilnych i — co ważniejsze — zaliczone Core Web Vitals w danych rzeczywistych użytkowników. Wynik 90+ na mobile jest w praktyce nieosiągalny dla rozbudowanego sklepu i nie warto za niego płacić. Patrz na dane z Chrome UX Report, nie na ocenę z symulacji.
Czy wolna strona obniża pozycje w Google?
Minimalnie. Core Web Vitals to bardzo słaby czynnik rankingowy — treść i dopasowanie do zapytania znaczą nieporównanie więcej. Prędkość realnie wpływa natomiast na konwersję, na koszt kliknięcia w Google Ads i na budżet indeksowania w dużych sklepach. To są lepsze powody, żeby się nią zająć, niż nadzieja na wzrost pozycji.
Dlaczego wynik jest inny za każdym razem?
Bo ocena syntetyczna pochodzi z pojedynczej symulacji, która zależy od chwilowego obciążenia serwera. Wahania o 20–30 punktów są normalne. Stabilne są dopiero dane rzeczywistych użytkowników zbierane przez 28 dni — i to na nie należy patrzeć przy ocenie efektów pracy.
Ile kosztuje optymalizacja prędkości sklepu?
Podstawowe prace — przegląd aplikacji, obrazy, czcionki, wymiary — to zwykle 1–2 dni pracy. Głębsza ingerencja w szablon to koszt liczony w tysiącach i sensowna dopiero po wyczerpaniu tańszych możliwości. Na platformie SaaS część rzeczy jest po prostu poza Twoim zasięgiem, bo należy do dostawcy.
Mam zielone wyniki, a sklep i tak nie sprzedaje. Co dalej?
To znaczy, że prędkość nie była problemem — i dobrze, jeden czynnik możesz skreślić. Szukaj przyczyny w widoczności (czy w ogóle się wyświetlasz na frazy z ruchem), w strukturze kategorii, w cenach na tle konkurencji i w samym procesie zakupowym. Zacznij od Search Console: jeśli nie ma wyświetleń, problem jest przed sklepem, a nie w nim.
Sprawdzę, czy prędkość to naprawdę Twój problem
W bezpłatnym mini-audycie pokażę, co realnie blokuje sklep — i powiem wprost, jeśli PageSpeed nie jest priorytetem.
Zamów bezpłatny audyt SEO i wydajności sklepu →