Wydajność · Core Web Vitals

Jak przyspieszyć sklep na Shoperze — co działa naprawdę (dane z audytów)

Jak mierzyć — i czego nie mierzyć

Jedno narzędzie wystarczy: PageSpeed Insights w trybie mobile. Wynik desktop wygląda ładnie w prezentacjach, ale 60–80% Twojego ruchu to telefony. Patrz na trzy metryki Core Web Vitals: LCP (największy element — cel < 2,5 s), INP/TBT (responsywność — cel < 200 ms) i CLS (skakanie layoutu — cel < 0,1). Mierz stronę główną, kategorię i kartę produktu — to trzy różne profile obciążenia.

5 hamulców sklepów Shoper — według częstości w audytach

1. Skrypty przez GTM. Piksele reklamowe, czaty, heatmapy, stare tagi „po byłej agencji". Rekordzista w naszych audytach: ponad 1,5 MB JS z samego kontenera — dwa razy więcej niż frontend sklepu.
2. Obrazy. Hero 2 MB w PNG, brak wymiarów (skacze layout — CLS), brak lazy loadingu pod foldem, brak WebP.
3. Nadmiar aplikacji frontowych. Każda aplikacja to skrypt; pięć „drobnych" widżetów potrafi dołożyć sekundę TBT. Zobacz które aplikacje naprawdę warto.
4. Ciężki szablon lub sekcje. Slidery ładujące 10 slajdów od razu, animacje na scrollu liczone w JS, webfonty bez strategii.
5. Brak warstwy cache/CDN. Zasoby statyczne serwowane bez optymalnej kompresji i cache na brzegu.

Studium przypadku: sklep modowy po audycie

Realny przykład z naszej praktyki (2026): sklep na Shoperze, mobile. Stan wejściowy: PageSpeed 52, TBT 340 ms, zauważalne CLS. Po pierwszej rundzie zmian po stronie szablonu i obrazów (bez dostępu do GTM klienta!): PageSpeed 59, TBT 101 ms, CLS 0. Diagnoza dalszego hamulca była jednoznaczna: ~1,5 MB JavaScriptu wstrzykiwanego przez tagi marketingowe — czyli kolejny skok wymagał już porządków w GTM, nie w sklepie. To typowa struktura problemu w Shoperze: platforma i szablon odpowiadają za część wyniku, ale sufit wyznaczają tagi.

Plan działań — od największego efektu

1. Zinwentaryzuj GTM. Wyłącz martwe tagi, ogranicz triggery do stron, gdzie są potrzebne, rozważ opóźnienie niekrytycznych skryptów do interakcji. Efekt bywa większy niż wszystkie pozostałe punkty razem.
2. Uporządkuj obrazy. WebP, poprawne wymiary (width/height w HTML), lazy loading pod foldem, eager + wysoki priorytet tylko dla hero. W dobrych szablonach większość dzieje się automatycznie.
3. Zredukuj aplikacje frontowe. Funkcje wizualne przenieś do modułów szablonu (bez dodatkowych skryptów), aplikacje zostaw backendowym zadaniom.
4. Wybierz / zaktualizuj szablon pod wydajność. Lekki JS, leniwe sekcje, brak zbędnych bibliotek — w rodzinie Modern traktujemy wydajność jako element designu, nie dodatek po fakcie (porównanie szablonów).
5. Dołóż Cloudflare. Cache statyków na brzegu, kompresja, nowoczesne protokoły. To nasza wyspecjalizowana usługa — konfigurujemy Cloudflare dla sklepów Shoper od lat.
6. Mierz co miesiąc. Wydajność to proces: nowy tag, nowy baner, nowa aplikacja — każda zmiana może cofnąć efekt.

Czego nie robić — trzy mity

• „Wtyczka przyspieszająca załatwi temat". Loadery sztucznie opóźniające skrypty potrafią podbić liczby w teście, psując realny UX, mierzenie konwersji — a czasem i sam wynik. Usuwaj przyczyny, nie maskuj objawów.
• „Zmienimy hosting". Shoper to SaaS — infrastruktura jest częścią platformy. Dźwignie leżą we froncie, tagach i CDN, nie w „przenosinach serwera".
• „Wytniemy funkcje sprzedażowe dla 3 punktów". Licznik dostawy czy opinie potrafią dawać więcej konwersji, niż kosztują punktów. Optymalizuj wagę funkcji, nie ich istnienie.

Najczęstsze pytania

Adrian Zblewski

GrowCommerce — Platynowy Partner Shoper

Audytuję wydajność sklepów Shoper z PageSpeed API i realnymi śladami przeglądarki (nie „na oko"). Liczby w tym artykule pochodzą z naszych wdrożeń.