Witly Logo
Funkcjonalności
Case studies
Marko.pl — rekomendacje AI Yrke.pl — headless storefront Stylion.pl — trafność wyszukiwania
Cennik
Zaloguj się Umów konsultację
Wydajność

Przyspieszenie Shopify — optymalizacja i Core Web Vitals krok po kroku

Praktyczny przewodnik po optymalizacji Shopify: dlaczego mimo szybkiego hostingu sklep bywa wolny, jak poprawić Core Web Vitals i które rzeczy zmienisz samodzielnie — od audytu aplikacji po motyw. Na końcu: co zrobić, gdy chcesz pełnej kontroli nad frontem.

Bartosz Jagielski
Bartosz Jagielski4 lipca 2026

Dlaczego Shopify bywa wolny

Shopify to platforma hostowana — serwer, cache i CDN są po stronie Shopify, więc TTFB zwykle jest dobry i nie masz nad nim kontroli. To zmienia punkt ciężkości: w Shopify wolno robi się przez to, co dokładasz do frontu — aplikacje, motyw i skrypty firm trzecich.

Najczęstsze przyczyny wolnego Shopify:

  • Aplikacje — to numer jeden. Każda aplikacja potrafi wstrzykiwać JS i CSS na każdą stronę sklepu, nawet tam, gdzie nie jest używana. Sklepy ładujące ponad 8 skryptów aplikacji mają medianę mobile LCP powyżej 3 s; przy 3 lub mniej — poniżej 2 s
  • Ciężki lub przestarzały motyw — mocno modyfikowane, legacy motywy dokładają dużo Liquid, skryptów i zapytań
  • Nadmiar dynamicznego Liquid — wiele obliczeń w szablonie naraz obciąża renderowanie
  • Nieoptymalne obrazy i render-blocking JS — zbyt duże obrazy, skrypty marketingowe ładowane od razu, brak zarezerwowanych wymiarów
Zasada nr 1: zmierz stan wyjściowy w PageSpeed Insights, a dane pól sprawdź w raporcie Shopify (Sklep online → Szybkość). Zmieniaj po jednej rzeczy i porównuj — w Shopify największe skoki daje zwykle wycięcie zbędnych aplikacji.
Metryki

Core Web Vitals w Shopify — co mierzyć

Core Web Vitals to metryki, którymi Google ocenia realne doświadczenie użytkownika i które wpływają na pozycje w wyszukiwarce. Cele dla sklepu Shopify:

Cele Core Web Vitals
  • LCP (największy element) — poniżej 2,5 s
  • INP (reakcja na interakcję) — poniżej 200 ms
  • CLS (stabilność układu) — poniżej 0,1
  • TTFB — zarządzany przez Shopify (zwykle dobry)
Co je psuje w Shopify
  • LCP — zbyt duży obraz główny, ciężki motyw
  • INP — skrypty aplikacji blokujące wątek główny
  • CLS — banery i widgety aplikacji bez wymiarów
  • Waga JS — skrypty aplikacji na każdej podstronie
W Shopify walczysz o front, nie o serwer. TTFB masz w pakiecie, więc cała optymalizacja to redukcja tego, co ładuje się w przeglądarce: mniej aplikacji, lżejszy motyw, lżejsze obrazy i odłożone skrypty firm trzecich.
Zrób sam

Krok 1: audyt aplikacji — największy zysk

Aplikacje to pojedyncza najczęstsza przyczyna słabych Core Web Vitals w Shopify. Zasada: każda aplikacja, której nie używasz, to czysta strata — jej skrypty często zostają na stronie nawet po dezinstalacji.

1

Zrób listę aplikacji

Wypisz wszystkie zainstalowane aplikacje i zaznacz te, których realnie używasz.

↓
2

Odinstaluj nieużywane

Usuń aplikacje, których nie potrzebujesz — a po odinstalowaniu sprawdź, czy nie zostały ich skrypty w kodzie motywu.

↓
3

Sprawdź „app embeds"

W edytorze motywu przejrzyj osadzone aplikacje i wyłącz te, które nie są potrzebne na danych stronach.

↓
4

Zmierz wpływ podejrzanych

Wyłącz podejrzaną aplikację i porównaj LCP oraz wagę JS przed/po w PageSpeed Insights.

Szczególnie kosztowne są aplikacje do popupów, recenzji, upselli i liczników, które ładują własne biblioteki na każdej podstronie — nawet tam, gdzie ich widget się nie pojawia.

Zrób sam

Krok 2: lekki, nowoczesny motyw

Motyw decyduje o bazowej wadze frontu. Motywy Online Store 2.0 (jak własny motyw Shopify — Dawn) są projektowane pod wydajność i konsekwentnie dobrze wypadają w Core Web Vitals.

  • Rozważ migrację z legacy — mocno modyfikowany, stary motyw bywa wolniejszy niż lekki motyw OS 2.0
  • Warunkowe ładowanie w Liquid — skrypty i style ładuj tylko tam, gdzie są potrzebne, w parze z async/defer
  • Ogranicz ciężki Liquid — unikaj wielu kosztownych obliczeń i pętli w szablonie renderowanych naraz
Zrób sam

Krok 3: obrazy — największy dług wagi strony

Shopify sam serwuje obrazy przez swój CDN i potrafi je konwertować, ale reszta zależy od Ciebie:

  • Nie wgrywaj przewymiarowanych plików — obraz szerokości 4000 px na kafelku 400 px to zmarnowana waga; kompresuj przed uploadem
  • NIE lazy-loaduj obrazu LCP — główny obraz nad pierwszym ekranem ma się ładować od razu, nie z opóźnieniem
  • Lazy loading poniżej pierwszego ekranu — reszta obrazów dopiero przy scrollu
  • Sztywne wymiary — zarezerwowane width i height chronią przed CLS, gdy obrazy i widgety się doładowują
Zrób sam

Krok 4: skrypty firm trzecich

Piksele, chaty, heatmapy i analityka zachowań obciążają wątek główny i psują INP. Dwie zasady:

  • Defer dla niekrytycznego JS — wszystko, co nie jest potrzebne do pierwszego renderu, ładuj z defer
  • Delay do interakcji — skrypty marketingowe ładuj dopiero po pierwszej interakcji użytkownika, jeśli biznesowo się to spina

Większość sklepów odzyskuje gros prędkości już w pierwszym tygodniu — na audycie aplikacji, kompresji obrazów i odłożeniu skryptów firm trzecich.

Co daje najwięcej — kolejność działań

Jeśli masz zrobić tylko kilka rzeczy, zrób je w tej kolejności — od największego zwrotu przy najmniejszym wysiłku:

1

Audyt aplikacji

Największy zysk w Shopify — mniej skryptów aplikacji to niższe LCP i lepszy INP.

↓
2

Lekki motyw OS 2.0

Migracja z ciężkiego legacy na lekki motyw (np. Dawn) obniża bazową wagę frontu.

↓
3

Kompresja i wymiary obrazów

Nie wgrywaj przewymiarowanych plików; obraz LCP bez lazy-load, reszta lazy; sztywne wymiary na CLS.

↓
4

Defer/delay skryptów firm trzecich

Piksele, chat, heatmapy — ładuj po interakcji, żeby ratować INP.

Gdy chcesz więcej

Gdzie kończy się optymalizacja motywu

Audyt aplikacji, lekki motyw i porządek w obrazach potrafią mocno podnieść wynik. Ale w Shopify uderzasz w inny sufit niż sam serwer: front renderuje motyw Shopify przez Liquid, a każda funkcja konwersyjna (wyszukiwarka, rekomendacje, chat) to kolejna aplikacja dokładająca skrypty. Masz ograniczoną kontrolę nad tym, co i kiedy się ładuje.

Wtedy zostaje zmiana architektury — headless. Front działa jako osobna, zoptymalizowana aplikacja i komunikuje się z Shopify wyłącznie przez API. Zarządzanie produktami, zamówieniami i checkout zostaje po stronie Shopify — zmienia się tylko warstwa, która decyduje o wydajności i UX.

Motyw Shopify
  • Front renderowany przez Liquid w ekosystemie Shopify
  • Każda aplikacja dokłada skrypty na front
  • Ograniczona kontrola nad kolejnością ładowania
  • Funkcje konwersyjne = kolejne aplikacje
Headless storefront
  • Front na osobnej infrastrukturze — pełna kontrola
  • Panujesz nad każdym skryptem i zasobem
  • 90+ PageSpeed osiągalne bez narzutu aplikacji
  • Wyszukiwarka, chat i rekomendacje wbudowane, nie doklejane

Headless ma sens, gdy chcesz pełnej kontroli nad frontem i wydajnością, a ekosystem aplikacji zaczyna ciążyć. Jak to działa krok po kroku, opisaliśmy w osobnych materiałach:

Headless Shopify →Jak działa headlessCase study: z szablonu na headless

Źródła

  • CoreWebVitals.io — Core Web Vitals for Shopify (2026)
    corewebvitals.io/core-web-vitals/shopify-guide
  • SpeedVitals — Shopify Speed Optimization: The Complete Guide
    speedvitals.com/blog/shopify-speed-optimization/
  • Performance @ Shopify — Aggregated Core Web Vitals by Theme
    performance.shopify.com/pages/theme-performance-data-table
  • Scandiweb — Shopify Performance Optimization: 2026 Playbook
    scandiweb.com/blog/shopify-performance-optimization/
  • Metizsoft — Shopify Store Speed Optimization Guide 2026
    metizsoft.com/blog/shopify-store-speed-optimization-guide-2026-covering-what-matters

Automatyzacja obsługi sklepu

Gotowy na rewolucję w obsłudze klienta?

Dołącz do firm, które już usprawniły działanie swojego sklepu

Umów konsultację →
FunkcjonalnościCennikShoper AIWooCommerce AIPrestaShop AIRegulaminPolityka prywatności

🇵🇱 Tworzone w Polsce • Polskie rozwiązania AI

© 2026 Witly. Wszystkie prawa zastrzeżone.