Performance sklepu — wydajność i Core Web Vitals

Wydajność sklepu wpływa na to, czy użytkownik zobaczy ofertę, zareaguje na interfejs i ukończy zakup. Core Web VitalsCzas, po którym ładuje się największy widoczny element strony — kluczowy wskaźnik szybkości i czynnik rankingowy. Pełna definicja w słowniku → są częścią sygnałów jakości strony, lecz nie istnieje uniwersalny przelicznik milisekund na konwersję ani gwarancja pozycji po uzyskaniu zielonego wyniku.

Dlaczego szybkość to SEO i konwersja?

Wolny lub niestabilny interfejs może utrudniać korzystanie ze sklepu. Wpływ na SEO i sprzedaż zależy od strony, urządzenia, sieci, intencji i całej ścieżki zakupowej, dlatego oceniaj:

• Współczynnik odrzuceń (bounce rate) – im dłużej ładuje się strona, tym więcej osób wychodzi.
• Głębokość sesji – szybkie strony zachęcają do przeglądania kolejnych kategorii.
• Ukończenie kroków — mierz dodanie do koszyka, przejście do kasy, błędy i finalizację zamiast zakładać przyczynę na podstawie jednego wyniku Lighthouse.

Core Web Vitals: LCP, CLS, INP – co musisz wiedzieć

LCP (Largest Contentful Paint) – czas ładowania głównego elementu

• Próg „dobry”: do 2,5 s dla 75. percentyla danych polowych.
• Problem: najczęściej wina ciężkich obrazów, wolnego serwera (TTFB) lub blokującego renderowanie CSS/JS.
• Przykład: baner główny o wadze 2 MB w formacie PNG – LCP leci na 6-8 s.

CLS (Cumulative Layout Shift) – stabilność układu

• Próg „dobry”: do 0,1 dla 75. percentyla danych polowych.
• Problem: dynamicznie wczytywane reklamy, obrazki bez atrybutów width/height, wstrzykiwane skrypty (np. czat, banery).
• Przykład: użytkownik klika w „Dodaj do koszyka”, a w tym momencie ładuje się baner promocyjny i przesuwa przycisk – klika w reklamę, złość, wyjście.

INP (Interaction to Next Paint) – responsywność interakcji

• Próg „dobry”: do 200 ms dla 75. percentyla danych polowych.
• Problem: ciężki JavaScript blokujący główny wątek, zbyt wiele skryptów analitycznych, nieoptymalne eventy.
• Przykład: kliknięcie w filtr kategorii – strona zamiera na 1,5 s, bo skrypt przelicza setki produktów w jednym wątku.

Najczęstsze problemy w sklepach e-commerce

1. Obrazy bez optymalizacji – zdjęcia produktów w oryginalnej rozdzielczości (4000x3000 px) w formacie JPEG, bez WebP/AVIF.
2. Nadmiar skryptów zewnętrznych – 10+ skryptów: Google Analytics, Facebook Pixel, Hotjar, czat, newsletter pop-up, reklamy – każdy blokuje renderowanie.
3. Brak lazy loadingu – wszystkie obrazki ładują się od razu, nawet te poniżej folda.
4. Ciężki motyw/premium builder – szablony z wbudowanymi sliderami, animacjami i niepotrzebnym CSS.
5. Wolny hosting – współdzielone serwery, brak CDN, brak cache Redis/Varnish.
6. Nieoptymalne czcionki – wczytywanie 4-5 wag czcionek Google Fonts bez font-display: swap.

Jak mierzyć i poprawiać – konkretne kroki

Pomiar

• Google PageSpeed Insights – daje konkretne wartości LCP, CLS, INP dla urządzeń mobilnych i desktop.
• CrUX (Chrome User Experience Report) – rzeczywiste dane od użytkowników, a nie tylko test laboratoryjny.
• Lighthouse w DevTools – audyt lokalny, przydatny do debugowania.
• GTmetrix / WebPageTest – szczegółowe wykresy wodospadu (waterfall) – widzisz, który zasób blokuje ładowanie.

Poprawa – realne działania

• Obrazy: konwertuj do WebP/AVIF, ustaw wymiary w HTML (width i height), wdróż lazy loading (loading="lazy").
• Serwer i CDN: najpierw zmierz TTFB, cache hit rate i waterfall. VPS, CDN lub Redis mają sens tylko wtedy, gdy odpowiadają na zdiagnozowane wąskie gardło.
• JavaScript: usuń nieużywany kod, dziel długie zadania i kontroluj skrypty zewnętrzne. defer i async stosuj zgodnie z zależnościami; analitykę ładuj dopiero według kontraktu consentu.
• Czcionki: używaj font-display: swap, ogranicz do 2-3 wag, hostuj lokalnie zamiast z Google.
• CLS: ustaw stałe wymiary dla wszystkich obrazków, iframe i reklam. Unikaj wstrzykiwania dynamicznych elementów nad treścią.
• INP: przenieś ciężkie obliczenia do Web Workerów, ogranicz liczbę listenerów, unikaj długich zadań w głównym wątku.

Jak udokumentować efekt optymalizacji

Zapisz przed zmianą dane polowe LCP, CLS i INP dla konkretnych typów stron oraz metryki ścieżki zakupowej. Następnie wdrażaj oddzielnie optymalizację obrazów, ograniczenie skryptów zewnętrznych, cache lub zmianę sposobu ładowania kodu. Dzięki temu wiadomo, która decyzja rzeczywiście zmieniła wynik.

Wynik laboratoryjny nie jest dowodem wzrostu przychodu ani pozycji. Performance to proces: monitoruj dane polowe i biznesowe na tych samych okresach porównawczych, z uwzględnieniem kampanii, sezonowości i zmian w ofercie.

To działa najlepiej nie w pojedynkę, lecz jako element przegląd techniczny sklepu — bo w e-commerce pojedyncza poprawka rzadko przesuwa wynik, a system poprawek owszem.