Core Web Vitals w sklepie internetowym — jak przyspieszyć sklep [2026]

Core Web Vitals w sklepie internetowym to nie techniczny detal, a bezpośredni czynnik sprzedaży: strony, które spełniają progi Google (LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1), konwertują lepiej, bo klienci nie zdążą się znudzić ładowaniem. Wolny sklep traci podwójnie: Google obniża pozycje, a użytkownicy porzucają koszyki. W tym artykule: co dokładnie mierzyć, jak zmierzyć stan swojego sklepu, co optymalizować w pierwszej kolejności i jak wygląda to na PrestaShop i WooCommerce.

• Zacznijmy od liczb: każda dodatkowa sekunda ładowania na telefonie obniża konwersję o kilkanaście procent, a próg LCP 2,5 s to granica, po której Google klasyfikuje stronę jako „wymagającą poprawy". Dobra wiadomość: w większości sklepów 80% problemu siedzi w kilku miejscach — zbyt dużych zdjęciach, braku cache, zbyt dużej liczbie skryptów i wolnym hostingu.

Najważniejsze: Trzy metryki do pilnowania: LCP < 2,5 s (ładowanie głównej treści), INP < 200 ms (reakcja na klik), CLS < 0,1 (stabilność układu). Mierz na telefonie — desktop jest z definicji szybszy. Największe rezerwy w sklepach: zdjęcia produktowe, third-party scripts (analityka, piksele, czaty) i hosting.

Co mierzą Core Web Vitals?

• LCP (Largest Contentful Paint) — czas do wyświetlenia największego elementu strony: zwykle zdjęcia produktu albo nagłówka kategorii. Próg: poniżej 2,5 s (dobrze), 2,5–4 s (wymaga poprawy), powyżej 4 s (źle). W sklepie to najczęściej zdjęcie hero albo zdjęcie produktu na karcie.
• INP (Interaction to Next Paint) — reakcja strony na interakcję: kliknięcie filtra, dodanie do koszyka, otwarcie menu. Próg: poniżej 200 ms. W sklepach INP psują ciężkie skrypty third-party i zbyt dużo pracy w JavaScript przy filtrach.
• CLS (Cumulative Layout Shift) — przesuwanie się układu w trakcie ładowania: banery, które wjeżdżają nad treścią, fonty, które podmieniają się z opóźnieniem. Próg: poniżej 0,1. W sklepie CLS przeszkadza najbardziej — klient klika „Dodaj do koszyka", a przycisk ucieka.

Od 2024 roku INP zastąpiło FID w zestawie Core Web Vitals. Google mierzy te metryki z danych rzeczywistych użytkowników (CrUX), nie z testów laboratoryjnych — więc liczy się mediana realnych sesji, głównie mobilnych.

Jak zmierzyć wydajność swojego sklepu

• PageSpeed Insights — test laboratoryjny pojedynczej strony z podpowiedziami; dobry punkt startowy, ale pokazuje tylko „laboratorium".

• Search Console → Core Web Vitals — dane rzeczywiste z Twojego ruchu, pogrupowane po URL-ach. Tu zobaczysz, które kategorie i karty produktów wypadają źle u prawdziwych użytkowników.

• CrUX Dashboard / CrUX API — dane polowe dla domeny; dobre do monitoringu trendu.

• RUM (monitoring rzeczywisty) — narzędzia typu DebugBear, SpeedCurve albo własny skrypt zbierający metryki z przeglądarek użytkowników. Sensowne dla sklepów, które chcą reagować na regresje przed Google.

• Zasada praktyczna: zacznij od Search Console (dane polowe), a do diagnozy konkretnej strony użyj PageSpeed Insights i Chrome DevTools. Jeśli 60%+ ruchu mobilnego wypada „wymaga poprawy" — masz realny problem, nie kosmetykę.

Największe rezerwy w sklepach — od czego zacząć

Kolejność optymalizacji według zwrotu z pracy

1. Zdjęcia produktowe — najczęstszy zabójca LCP. Kompresja do WebP/AVIF, właściwe wymiary (nie wysyłaj 2000 px, jeśli wyświetlasz 600 px), lazy loading dla zdjęć poniżej ekranu, srcset dla różnych rozdzielczości. W galeriach: ładowanie kolejnych zdjęć dopiero po kliknięciu.
2. Cache i CDN — cache stron (full-page cache dla gości), cache obiektowy (Redis), CDN dla statyków i zdjęć. W sklepach z ruchem z całej Polski CDN skraca LCP o dziesiątki procent, bo pliki serwowane są z serwera blisko użytkownika.
3. Skrypty third-party — analityka, piksele reklamowe, czaty, narzędzia rekomendacji, mapy. Każdy dodaje kilobajty i zadania w JavaScript (INP). Audyt: przejrzyj listę skryptów i usuń duplikaty (dwa piksele Meta? trzy narzędzia analityczne?), opóźnij ładowanie niekrytycznych (chat po interakcji, piksele po zgodzie cookies — co i tak wymaga RODO).
4. Fonty i CSS — fonty lokalnie (nie z Google Fonts), font-display: swap lub optional, preload kluczowego fontu; krytyczny CSS inline, resztę asynchronicznie. To główne źródła CLS.
5. Hosting — sklep na współdzielonym hostingu za 50 zł nie osiągnie dobrych CWV przy kampanii. Parametry do sprawdzenia: TTFB poniżej 200 ms, PHP-FPM z OPcache, NVMe, wystarczająca pamięć dla bazy. Hosting dla sklepu to element projektu, nie oszczędność na fakturze.
6. JavaScript aplikacyjny — nadmiar wtyczek/modułów, niepotrzebne biblioteki, brak code-splittingu. W sklepach na WooCommerce/PrestaShop to zwykle dziesiątki wtyczek ładujących własne skrypty na każdej stronie.

Uwaga: Nie optymalizuj „na ślepo" — najpierw zmierz. Sklep z LCP 3,5 s może mieć problem w zdjęciach hero, a nie w hostingu; wymiana hostingu bez kompresji zdjęć nie naprawi wyniku. Testuj po każdej zmianie na tym samym zestawie URL-i (karta produktu, kategoria, strona główna, koszyk).

Core Web Vitals na PrestaShop

PrestaShop po instalacji nie jest szybki, ale daje pełną kontrolę nad optymalizacją

• włącz cache (Smarty, cache stron), włącz kompresję i HTTP/2 na serwerze,
• obrazy: konwertuj do WebP, popraw wymiary generowanych miniatur (domyślne ustawienia potrafią tworzyć 6 wariantów zdjęcia, z których używasz dwóch),
• moduły: audyt listy — każdy wyłączony moduł to mniej CSS/JS; usuwaj, nie tylko wyłączaj,
• baza: indeksy, czyszczenie tabel statystyk, optymalizacja zapytań kategorii,
• CDN dla statyków i mediów.

Krok po kroku z konkretnymi ustawieniami opisałem w artykule optymalizacja PrestaShop. Jeśli sklep ma nietypowe moduły pisane na zamówienie, warto je zrefaktoryzować — modernizacja legacy PHP obejmuje też warstwę wydajnościową.

Core Web Vitals na WooCommerce

WooCommerce dziedziczy wydajność WordPressa i dokłada własne obciążenia

• pełny cache stron dla gości (LiteSpeed Cache, WP Rocket), cache obiektowy (Redis) dla zalogowanych,
• optymalizacja obrazów (konwersja WebP, lazy loading, poprawne rozmiary miniatur — WordPress domyślnie generuje wiele wariantów),
• audyt wtyczek: każda dodaje skrypty na wszystkich stronach; ogranicz ładowanie skryptów do stron, na których są potrzebne,
• hosting z OPcache i PHP 8.2+ (PHP 8 znacząco przyspiesza WordPressa względem 7.x),
• ograniczenie zewnętrznych fontów i skryptów marketingowych.

Szczegóły dla WordPressa opisałem w artykule optymalizacja wydajności WordPress.

Efekt biznesowy — CWV to konwersja, nie punkty

W praktyce wdrożeń widzę stały wzorzec: sklep, który schodzi z LCP ~4 s do ~2 s na mobile, odzyskuje kilka punktów procentowych konwersji — bez zmiany oferty i cen. Dodatkowo Google w wynikach nagradza strony spełniające progi, a przy równych treściach szybka strona wygrywa pozycją.

Priorytety, jeśli masz ograniczony czas: (1) zdjęcia produktowe i hero, (2) cache i CDN, (3) audyt skryptów third-party, (4) stabilność układu (CLS) na karcie produktu i w koszyku. Cztery działania pokrywają większość poprawy.

Checklista wydajności sklepu

1. Baseline zmierzony: PSI + Search Console dla karty produktu, kategorii, głównej, koszyka.
2. Zdjęcia: WebP/AVIF, poprawne wymiary, lazy loading, srcset.
3. Cache stron dla gości + cache obiektowy (Redis).
4. CDN dla statyków i mediów.
5. Audyt skryptów third-party — usunięte duplikaty, opóźnione niekrytyczne.
6. Fonty lokalnie, font-display: swap, preload kluczowego.
7. TTFB poniżej 200 ms (sprawdzone z zewnątrz).
8. CLS: wymiary dla obrazów i reklam zarezerwowane w CSS.
9. Monitoring RUM lub comiesięczny test zestawu URL-i.
10. Każda nowa wtyczka/moduł testowana pod kątem wpływu na CWV przed wdrożeniem.

Najczęściej zadawane pytania

Jakie są progi Core Web Vitals w 2026 roku?

LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — mierzone jako 75. percentyl rzeczywistych sesji (głównie mobilnych). Wartości między progiem a „czerwoną strefą" (LCP 2,5–4 s, INP 200–500 ms, CLS 0,1–0,25) oznaczają „wymaga poprawy".

Czy Core Web Vitals wpływają na pozycje w Google?

Tak, ale jako czynnik drugorzędny — treść i intencja strony ważą więcej. CWV rozstrzygają przy porównywalnych treściach: strona szybsza wygrywa. Największy wpływ CWV mają na konwersję i doświadczenie użytkownika, a to one przekładają się na wyniki sprzedażowe.

Dlaczego mój sklep ma dobre wyniki w PageSpeed, a słabe w Search Console?

PageSpeed Insights mierzy pojedynczą stronę w laboratorium (z szybkim połączeniem i bez rozszerzeń). Search Console pokazuje medianę rzeczywistych użytkowników — na telefonach, z wolnym zasięgiem i z dodatkami przeglądarki. Rzeczywiste dane są ważniejsze: optymalizuj pod CrUX, nie pod wynik laboratoryjny.

Od czego zacząć optymalizację sklepu pod CWV?

Od zdjęć produktowych — to najczęstsza przyczyna złego LCP i najszybsza wygrana (konwersja do WebP, poprawne wymiary, lazy loading). Potem cache stron i CDN, następnie audyt skryptów third-party. Dopiero na końcu wymiana hostingu — bez wcześniejszych kroków sama nie naprawi wyniku.

Ile kosztuje optymalizacja wydajności sklepu?

Audyt wydajności z rekomendacjami: 2 000–4 000 zł. Wdrożenie optymalizacji (zdjęcia, cache, CDN, skrypty, refaktoryzacja modułów): 3 000–15 000 zł zależnie od stanu sklepu. Najlepszy moment to projekt wdrożenia — sklep budowany z CWV od początku nie wymaga późniejszych napraw.

Czy wtyczki cache wystarczą, żeby naprawić CWV?

Częściowo — poprawią TTFB i LCP dla gości, ale nie naprawią zbyt dużych zdjęć ani nadmiaru skryptów third-party. Cache to jeden z elementów układanki: bez optymalizacji mediów i audytu skryptów wyniki zatrzymają się w połowie drogi. Najlepiej działa kolejność: media → cache/CDN → skrypty → stabilność układu.

👉 Twój sklep ładuje się za wolno? Zobacz, jak optymalizuję wydajność w projektach e-commerce: projektowanie sklepów internetowych, sklepy PrestaShop i WordPress. Napisz na kontakt@informatix.com.pl — zmierzę CWV Twojego sklepu i wskażę, co daje największy zwrot.

📖 Zobacz również: Optymalizacja PrestaShop, Optymalizacja wydajności WordPress oraz Projektowanie sklepów internetowych — kompletny przewodnik.