Najgorsze w wolnym sklepie jest to, że nie zobaczysz tego w żadnym raporcie. Nie ma błędu, nie ma alertu - jest tylko sprzedaż niższa, niż powinna być, i ktoś, kto zamknął kartę po dwóch sekundach czekania na zdjęcie produktu. Większość właścicieli sklepów nie wie, jak szybki naprawdę jest ich sklep, bo testują go na swoim szybkim łączu i swoim komputerze - a klient siedzi na telefonie, w pociągu, na 4G.
Dobra wiadomość: nie trzeba być programistą, żeby to sprawdzić. Wystarczy jedno darmowe narzędzie Google i piętnaście minut. Pokażę Ci dokładnie, gdzie kliknąć, co odczytać i które liczby naprawdę coś znaczą - a które możesz zignorować. Na końcu dostajesz prosty checklist plus moment, w którym warto już zawołać kogoś do roboty.
Zasada, według której pracuję, jest jedna: najpierw mierzę, potem naprawiam. Bez liczb każda zmiana to zgadywanie - a w sklepie zgadywanie kosztuje.
Zacznij od PageSpeed Insights - i koniecznie na telefonie
Wejdź na pagespeed.web.dev, wklej adres swojego sklepu i kliknij „Analizuj”. Po chwili dostajesz wynik. Najważniejsza rzecz, którą widzę u klientów jako notoryczny błąd: ludzie patrzą na zakładkę „Komputer” i się cieszą. A liczy się „Telefon komórkowy”.
Dlaczego mobile? Bo to na telefonach robi się dziś większość ruchu w e-commerce, Google ocenia stronę głównie po wersji mobilnej, a telefon jest po prostu wolniejszy - słabszy procesor, gorsze łącze. Wynik desktopowy potrafi być o 30-40 punktów wyższy i da Ci złudne poczucie, że wszystko gra. Patrz na telefon, bo tam jest prawda.
Zobaczysz dwie sekcje. Górna, kolorowa, to „dane z terenu” (jeśli sklep ma wystarczający ruch) - jak stronę realnie odczuwają prawdziwi użytkownicy w ostatnich 28 dniach. Dolna to test laboratoryjny na jednym przebiegu. Jeśli masz dane z terenu, ufaj im najbardziej - to nie symulacja, to Twoi klienci.
Co pomaga: zrób test 2-3 razy i weź środkowy wynik - pojedynczy pomiar potrafi skłamać przez chwilowe obciążenie serwera. Sprawdź też nie tylko stronę główną, ale kartę produktu i koszyk - to tam człowiek decyduje o zakupie.
Co znaczą te dziwne skróty: LCP, INP, CLS, TBT
To są Core Web Vitals - zestaw miar, którymi Google opisuje, jak strona „czuje się” dla człowieka. Brzmi technicznie, ale każda z nich odpowiada na proste pytanie. Rozbiję je po ludzku.
- LCP (Largest Contentful Paint) - „jak szybko widzę najważniejszą rzecz na ekranie”, zwykle duże zdjęcie produktu albo nagłówek. To najważniejsza liczba. Dobry wynik to do 2,5 s. Powyżej 4 s klient czuje, że się ślimaczy.
- INP (Interaction to Next Paint) - „czy strona reaguje, gdy w nią klikam”. Klikasz „Dodaj do koszyka” i nic się nie dzieje przez moment - to wysoki INP. Dobry wynik to poniżej 200 ms.
- CLS (Cumulative Layout Shift) - „czy mi się nie przeskakuje układ pod palcem”. Wszedłeś, chcesz kliknąć przycisk, a w tym momencie doładował się baner i klikasz w coś innego. Irytujące i kosztowne. Dobry wynik to poniżej 0,1.
- TBT (Total Blocking Time) - to miara z testu laboratoryjnego, „jak długo strona była zamrożona i nie dało się nic zrobić”, zwykle przez ciężki JavaScript. Wysoki TBT to prawie zawsze za dużo skryptów: wtyczki, czaty, narzędzia śledzące.
Nie musisz znać tych skrótów na pamięć. Wystarczy, że wiesz: LCP mówi „jak szybko widać”, INP i TBT mówią „jak szybko reaguje”, a CLS mówi „czy się nie trzęsie”. Więcej o tym, jak te miary działają konkretnie w sklepach na WooCommerce, rozpisałem w osobnym tekście o Core Web Vitals w WooCommerce.
Jak czytać wynik bez paniki
Liczba na górze (np. 38/100) to indeks złożony z kilku miar - jest poglądowa, nie traktuj jej jak wyroku. Ja patrzę na nią najpierw, żeby wiedzieć, czy w ogóle jest problem, a potem schodzę niżej, do konkretów.
Pod wynikiem PageSpeed pokazuje sekcję „Możliwości” - listę rzeczy do poprawy, posortowaną według tego, ile sekund każda z nich potencjalnie zwróci. To najcenniejsza część raportu, którą większość ludzi przewija. Czytaj ją z góry na dół: na samej górze siedzi Twój największy balast.
Typowe pozycje, które tam zobaczysz, i co realnie znaczą:
- „Wyświetlaj obrazy w formatach nowej generacji” / „Odpowiednio dobieraj rozmiar obrazów” - masz za ciężkie zdjęcia. Bardzo częsty i bardzo wdzięczny do naprawy punkt.
- „Ogranicz nieużywany JavaScript / CSS” - za dużo kodu z wtyczek i motywu ładuje się tam, gdzie nie jest potrzebny.
- „Skróć czas odpowiedzi serwera (TTFB)” - serwer długo myśli, zanim w ogóle zacznie wysyłać stronę. To sygnał problemu z hostingiem albo brakiem cache.
Co pomaga: nie rzucaj się na wszystko naraz. Weź jedną, najwyższą pozycję z listy, która obiecuje najwięcej zaoszczędzonych sekund, i to ona jest Twoim pierwszym celem. Naprawa od góry daje największy efekt najmniejszym kosztem.
Zajrzyj pod maskę - waterfall w przeglądarce
PageSpeed mówi „co” jest nie tak. Jeśli chcesz zobaczyć „dlaczego”, masz darmowe narzędzie wbudowane w przeglądarkę. W Chrome kliknij prawym na stronie sklepu, wybierz „Zbadaj” (albo wciśnij F12), przejdź na zakładkę Network (Sieć) i odśwież stronę. Zobaczysz tzw. waterfall - listę wszystkiego, co sklep pobiera, jeden plik pod drugim, z paskami pokazującymi, jak długo każdy się ładuje.
Nie musisz tego rozumieć w 100%. Szukasz trzech rzeczy:
- Najdłuższe paski - co ładuje się najwolniej? Jeśli to wielkie zdjęcia, masz winowajcę.
- Najwięcej pozycji - jeśli strona pobiera 200 plików, to prawie zawsze nadmiar wtyczek i skryptów zewnętrznych.
- Łączna waga na dole - ile megabajtów waży cała strona. Powyżej 3-4 MB na telefonie to już dużo. Dobrze zoptymalizowana karta produktu potrafi zejść poniżej 1,5 MB.
Na samej górze listy zobaczysz też pierwsze żądanie do swojego adresu - czas oznaczony jako „Waiting (TTFB)” to dokładnie ten moment, w którym serwer „myśli”. Jeśli to jest długie (powyżej 0,6-0,8 s), problem siedzi po stronie hostingu lub braku cache, a nie w obrazkach.
Gdzie najczęściej siedzi największy balast
Wina niemal zawsze rozkłada się na trzy obszary. W tej kolejności warto patrzeć:
- Obrazy. Najczęstszy i najłatwiejszy do naprawy grzech. Zdjęcie wgrane prosto z aparatu waży 4-6 MB, a w katalogu są ich setki. Rozwiązanie: kompresja, format WebP/AVIF, serwowanie obrazu w rozmiarze, w jakim faktycznie się wyświetla, i leniwe ładowanie tego, co poniżej pierwszego ekranu.
- Wtyczki i skrypty. Nie liczba się liczy, tylko co robią. Jedna źle napisana wtyczka, ładująca własny kod na całej witrynie, potrafi spowolnić sklep bardziej niż dwadzieścia lekkich. Tu pomaga audyt, który pokazuje, kto ile czasu zjada, i bezlitosne wycinanie zbędnych.
- Hosting i TTFB. Jeśli serwer długo odpowiada zanim cokolwiek wyśle, żadna optymalizacja obrazków tego nie uratuje. Tani współdzielony hosting za 10 zł to pierwszy podejrzany. Pomaga przyzwoity hosting pod WooCommerce plus dobrze skonfigurowany cache stron.
Jeśli prowadzisz sklep i chcesz zrozumieć, jak te trzy obszary łączą się w jeden spójny plan naprawy, opisałem to przy okazji przyspieszania sklepów WooCommerce - tam wydajność jest częścią całości, a nie łatką na koniec.
Checklist do samodzielnego przejścia
Usiądź na 15 minut i przejdź przez to po kolei. Notuj liczby - bez nich za miesiąc nie ocenisz, czy cokolwiek się poprawiło.
- Test w PageSpeed Insights na zakładce Telefon komórkowy (nie komputer).
- Sprawdziłem stronę główną, kartę produktu i koszyk osobno.
- LCP poniżej 2,5 s? (powyżej 4 s = pilne).
- CLS poniżej 0,1? (nic mi nie przeskakuje pod palcem).
- Zerknąłem na listę „Możliwości” i wypisałem 3 najwyższe pozycje.
- W zakładce Network sprawdziłem łączną wagę strony (cel: poniżej 2-3 MB na mobile).
- Sprawdziłem TTFB - czas „myślenia” serwera (cel: poniżej 0,6 s).
Jeśli wszystkie te punkty są na zielono - gratuluję, masz szybki sklep i nie tracisz na tym pieniędzy. Jeśli kilka świeci na czerwono, masz teraz coś cenniejszego niż przeczucie: konkretną listę, co naprawić.
Kiedy zrobisz sam, a kiedy zawołać developera
Niektóre rzeczy z tej listy ogarniesz samodzielnie albo z dobrą wtyczką: kompresja obrazów, włączenie podstawowego cache, usunięcie kilku oczywiście zbędnych wtyczek. To realne wygrane i warto je wyciągnąć.
Po pomoc warto sięgnąć, gdy: TTFB jest wysoki mimo cache (pachnie hostingiem albo bazą), nie wiesz, która z dwudziestu wtyczek tak naprawdę dławi sklep, albo - co widzę najczęściej - boisz się ruszyć cokolwiek, żeby nie wywalić sklepu w środku dnia sprzedażowego. To nie słabość. To moment, w którym ktoś z doświadczeniem zrobi w godzinę to, co Tobie zajęłoby weekend i sporo nerwów. Ile realnie kosztuje taka pomoc, rozpisałem osobno w tekście o tym, ile kosztuje przyspieszenie sklepu.
Kluczowe jest to, że teraz wchodzisz w taką rozmowę z liczbami w ręku. Wiesz, co jest nie tak, i nie dasz sobie wcisnąć „przebudowy od zera”, jeśli wystarczy uporządkować trzy rzeczy.
Zróbmy to razem
Jeśli zrobiłeś test i widzisz czerwone liczby, ale nie wiesz, od czego zacząć - podeślij mi link do sklepu. Zrobię bezpłatny przegląd, zmierzę to porządnie i wskażę dokładnie, co konkretnie dławi Twój sklep i co da się przyspieszyć najszybciej i najtaniej. Bez zobowiązań i bez „od X zł” - dostajesz konkret na piśmie.
Najczęstsze pytania
Jak często sprawdzać szybkość sklepu? Raz w miesiącu w spokojnym okresie, a poza tym po każdej większej zmianie: nowej wtyczce, zmianie motywu, dużym imporcie produktów. Sklep na WordPressie zwalnia po cichu, przez sumę drobnych dodatków - regularny pomiar wyłapie to, zanim odbije się na sprzedaży.
Dlaczego wynik PageSpeed skacze przy każdym pomiarze? Bo test laboratoryjny to jeden przebieg - chwilowe obciążenie serwera albo sieci potrafi zmienić wynik o kilkanaście punktów. Dlatego robię pomiar 2-3 razy i biorę środkowy, a gdy sklep ma dane z terenu, patrzę przede wszystkim na nie, bo opisują 28 dni realnych wizyt, a nie jedną symulację.
Czemu wynik na telefonie jest dużo niższy niż na komputerze? Test mobilny symuluje słabszy procesor i wolniejsze łącze, czyli warunki bliższe temu, w jakich kupuje większość ludzi. Różnica 30-40 punktów na korzyść komputera jest normalna i właśnie dlatego wynik desktopowy usypia czujność. Google ocenia stronę głównie po wersji mobilnej, więc to ona jest tą prawdziwą.
Czy muszę mieć 100/100, żeby sklep był szybki? Nie. Liczba na górze raportu to indeks poglądowy - ważniejsze są konkretne miary: LCP poniżej 2,5 s, CLS poniżej 0,1 i TTFB poniżej 0,6 s. Sklep z przyzwoitym wynikiem mobilnym i dobrymi Core Web Vitals zarabia lepiej niż taki, który goni punkty kosztem funkcji.
Powiązane: Core Web Vitals w WooCommerce - co realnie liczy Google · Przyspieszanie sklepu WooCommerce