Wydajność sklepu internetowego - jak zmierzyć i przyspieszyć ładowanie

Które strony sklepu mierzyć i jak często

Sklep to kilka typów stron zbudowanych na różnych szablonach, a każdy ma inne problemy. Strona główna jest zwykle dopieszczona, a karty produktów z wieloma wariantami, galerią i opiniami ładują się najwolniej. Pomiar warto ustawić na stałej liście adresów: strona główna, dwie lub trzy duże kategorie, kilka kart produktów różnego typu, wyniki wyszukiwania i koszyk. Testy laboratoryjne powtarzaj kilka razy i porównuj medianę, a dane terenowe przeglądaj co miesiąc i po każdej większej zmianie, np. nowej aplikacji, wtyczce czy skrypcie reklamowym.

Ważny jest też podział na urządzenia. W większości sklepów dominuje ruch z telefonów, a to tam słabszy procesor i łącze najmocniej pokazują koszt ciężkich skryptów. Wynik dobry na komputerze i słaby na telefonie to typowy obraz sklepu z dużą liczbą skryptów zewnętrznych.

Wyniki pomiarów najlepiej zapisywać w prostym arkuszu: data, adres, typ urządzenia, wartości LCP, INP, CLS i TTFB oraz krótka notatka o zmianach wprowadzonych od poprzedniego pomiaru. Po kilku miesiącach taki rejestr pokazuje, które zmiany pogorszyły wyniki, a które je poprawiły, i oszczędza czas przy szukaniu przyczyny nagłego spadku. Jeśli sklep korzysta z narzędzia do monitoringu, które samo zbiera dane od użytkowników, arkusz zastępują jego raporty, ale notatki o zmianach nadal warto prowadzić ręcznie, bo żadne narzędzie nie wie, że marketing dodał wczoraj nowy piksel albo widżet.

Jak znaleźć przyczynę wolnego ładowania sklepu

Najczęściej odstającym wskaźnikiem w sklepach jest LCP, bo największym elementem strony produktu jest zdjęcie. Web.dev proponuje rozłożenie LCP na cztery części: czas do pierwszego bajtu (TTFB), opóźnienie rozpoczęcia ładowania zasobu, czas jego pobierania i opóźnienie renderowania elementu. Każda część ma inną przyczynę i inne rozwiązanie, więc rozkład pokazuje, gdzie szukać. Przykładowy rozkład dla karty produktu przed poprawkami i po nich:

[#chart:wpr85b]

Rozkład odczytasz w narzędziach deweloperskich Chrome, w panelu wydajności, albo w raporcie Lighthouse. Jeśli dominuje TTFB, problem leży po stronie serwera, bazy danych, pamięci podręcznej lub przekierowań. Jeśli dominuje opóźnienie ładowania, przeglądarka zbyt późno dowiaduje się o zdjęciu, np. bo jest ładowane leniwie albo wstawiane skryptem. Jeśli dominuje pobieranie, zdjęcie jest za duże. Jeśli dominuje renderowanie, stronę blokują skrypty i style.

Jak przyspieszyć ładowanie sklepu - kolejność działań

Poprawki warto wprowadzać od tych, które dotyczą największej liczby stron i najmocniej wpływają na zmierzone wskaźniki. W większości sklepów kolejność wygląda tak:

1. Czas odpowiedzi serwera - pamięć podręczna stron i obiektów, wydajny hosting, brak zbędnych przekierowań. TTFB to pierwsza część LCP, więc wolny serwer spowalnia wszystko, co dzieje się później.

2. Główne zdjęcie produktu i kategorii - odpowiedni rozmiar i format, brak leniwego ładowania. Web.dev zaleca, by nigdy nie ładować leniwie obrazu LCP, a obrazowi, który ma nim być, nadać atrybut fetchpriority=high.

3. Skrypty zewnętrzne - piksele, czaty, widżety opinii i narzędzia testów A/B ładowane później lub tylko tam, gdzie są potrzebne. To najczęstsza przyczyna słabego INP na telefonach.

4. Stabilność układu - wymiary zdjęć i banerów, zarezerwowane miejsce na elementy wstawiane skryptem, ostrożne ładowanie czcionek.

5. Aplikacje i wtyczki - przegląd, co naprawdę jest używane, i usunięcie dodatków, które ładują kod na każdej stronie.

Pamięć podręczna w sklepie wymaga ostrożności, bo koszyk, konto klienta i checkout muszą pozostać dynamiczne. Zasady na przykładzie WordPressa opisujemy we wpisie cache w WooCommerce - jak ustawić pamięć podręczną bez psucia koszyka, a wybór serwera - w tekście hosting dla WooCommerce - współdzielony, VPS czy managed.

Wolny sklep - objawy i najczęstsze przyczyny

Ten sam wynik w PageSpeed Insights może mieć zupełnie różne przyczyny. Zanim zaczniesz poprawki, dopasuj objaw do grupy przyczyn:

[#chart:wpr85c]

[#tip] Zanim zmienisz cokolwiek w sklepie, zapisz wyniki pomiaru dla stałej listy adresów. Bez punktu odniesienia nie da się ocenić, czy poprawka zadziałała, a dane terenowe z 28 dni zmieniają się powoli, więc efekt w raportach Google zobaczysz dopiero po kilku tygodniach.

Wydajność koszyka i checkoutu

Koszyk i proces zamówienia działają inaczej niż strony katalogu. Są generowane indywidualnie dla każdego klienta, więc nie korzystają z pamięci podręcznej stron, a każde kliknięcie, np. zmiana metody dostawy czy wpisanie kodu rabatowego, wysyła zapytanie do serwera. Narzędzia takie jak PageSpeed Insights mierzą je słabo, bo nie przejdą procesu zakupu, dlatego tu potrzebny jest pomiar ręczny lub automatyczny test przeglądarki. Przy przeglądzie checkoutu sprawdzamy przede wszystkim:

• czas odpowiedzi serwera przy dodaniu do koszyka i przeliczeniu kosztów dostawy,

• liczbę zapytań wysyłanych przy każdej zmianie w formularzu i czas ich obsługi,

• ładowanie widżetów punktów odbioru, bramek płatności i formularzy ratalnych,

• skrypty reklamowe i analityczne, które uruchamiają się na stronie zamówienia,

• działanie na słabszym telefonie, bo tam opóźnienia reakcji są najbardziej widoczne.

Spowolnienie checkoutu jest groźniejsze niż wolna strona główna, bo klient jest już zdecydowany na zakup. Każda sekunda czekania na przeliczenie dostawy to moment, w którym może zrezygnować. Dlatego po każdej zmianie w metodach dostawy, płatności lub wtyczkach checkoutu warto przejść zakup na telefonie i zmierzyć czas kluczowych kroków.

Jak połączyć pomiar wydajności ze sprzedażą

Wskaźniki wydajności są środkiem, a nie celem. Żeby ocenić, czy praca nad szybkością się opłaca, warto zestawić je z danymi sprzedażowymi: współczynnikiem konwersji na telefonach i komputerach, odsetkiem porzuceń na kartach produktów i w koszyku oraz przychodem z ruchu mobilnego. Jeśli sklep jest wyraźnie wolniejszy na telefonach, a konwersja mobilna odstaje od desktopowej bardziej niż w podobnych okresach, to mocna przesłanka, by zacząć poprawki właśnie tam.

Najprościej porównywać okresy przed zmianą i po niej, pamiętając o sezonowości, kampaniach i zmianach cen, które wpływają na wynik niezależnie od szybkości. Uczciwa analiza mówi, że poprawa wydajności zwiększa szansę na lepszą konwersję, ale nie jest jedynym czynnikiem, dlatego warto ją oceniać na kilku tygodniach danych, a nie na jednym dniu.

Budżet wydajności - jak nie stracić efektów po kilku miesiącach

Najczęstsza historia w sklepach wygląda tak: po optymalizacji wyniki są dobre, a po pół roku znów słabe, bo doszły nowe aplikacje, piksele, banery i sekcje na stronie głównej. Rozwiązaniem jest budżet wydajności, czyli zapisane granice, których zespół pilnuje przy każdej zmianie: docelowe wartości LCP, INP i CLS dla kluczowych stron, maksymalna waga zdjęć na karcie produktu i lista skryptów zewnętrznych, na które jest zgoda. Każdy nowy dodatek przechodzi pomiar przed wdrożeniem i po nim.

Budżet wydajności pomaga też w rozmowach z marketingiem i dostawcami narzędzi. Gdy nowy widżet pogarsza INP na telefonach o wyraźną wartość, decyzja o jego wdrożeniu staje się biznesowa: czy korzyść z narzędzia jest większa niż koszt wolniejszej strony. Bez pomiaru takie decyzje zapadają na wyczucie, a koszt widać dopiero w spadku konwersji.

Wydajność na platformie abonamentowej i własnym serwerze

Na platformach abonamentowych, takich jak Shopify, serwer i jego konfiguracja są po stronie dostawcy, więc pole do działania to motyw, aplikacje, zdjęcia i skrypty. Na własnym serwerze, np. przy WooCommerce czy PrestaShop, dochodzą konfiguracja serwera, bazy danych i pamięci podręcznej, a więc więcej możliwości i więcej odpowiedzialności. W obu przypadkach zasada jest ta sama: najpierw pomiar, potem poprawka, potem kolejny pomiar. Także przy decyzjach o przebudowie sklepu, np. przejściu na architekturę headless, pomiar powinien poprzedzać zmianę - piszemy o tym we wpisie sklep headless - co to jest i czy się opłaca.

Jak Vinson pomaga z wydajnością sklepu internetowego

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Mierzymy wydajność kluczowych stron sklepu na danych terenowych i laboratoryjnych, rozkładamy LCP na części, wskazujemy przyczyny i wdrażamy poprawki w kodzie, szablonach, konfiguracji pamięci podręcznej i ładowaniu skryptów. Pomagamy też ustalić budżet wydajności, który chroni efekty po kolejnych zmianach. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Jak sprawdzić wydajność sklepu internetowego?

Wpisz adres karty produktu i kategorii w PageSpeed Insights i zacznij od danych od prawdziwych użytkowników z ostatnich 28 dni, osobno dla telefonów i komputerów. Szczegóły przyczyn znajdziesz w teście Lighthouse. Sklepy na Shopify mogą też korzystać z raportu wydajności w panelu.

Jaki czas ładowania sklepu jest dobry?

Google za dobre uznaje LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1, mierzone na 75. percentylu odsłon (stan na czerwiec 2026 - sprawdź aktualną dokumentację Google). Dla czasu odpowiedzi serwera web.dev wskazuje orientacyjnie 0,8 sekundy lub mniej.

Dlaczego wynik w PageSpeed Insights zmienia się przy każdym teście?

Wynik punktowy pochodzi z testu laboratoryjnego, na który wpływają chwilowe obciążenie serwera, skrypty zewnętrzne i warunki sieci. Dlatego warto powtarzać test kilka razy i porównywać medianę, a o rzeczywistej szybkości sklepu wnioskować z danych od użytkowników.

Co najbardziej spowalnia sklep internetowy?

Najczęściej wolna odpowiedź serwera, zbyt duże lub leniwie ładowane główne zdjęcie oraz skrypty zewnętrzne, takie jak piksele, czaty i widżety. Która przyczyna dominuje w Twoim sklepie, pokaże rozkład LCP na części i lista skryptów w raporcie Lighthouse.

Czy sklep musi mieć wynik 100 w Lighthouse?

Nie. Wynik punktowy to wskazówka z testu laboratoryjnego, a dla klientów i oceny Google liczą się wskaźniki z danych terenowych. Lepiej osiągnąć dobre LCP, INP i CLS na kartach produktów na telefonach niż gonić za setką na stronie głównej.

Szybki sklep to nie jednorazowy projekt, tylko pomiar, poprawki i pilnowanie budżetu wydajności. Jeśli chcesz sprawdzić, co spowalnia Twój sklep, i wdrożyć poprawki w kodzie, sprawdź wsparcie programistyczne Vinson.