Krok 1 - hosting, cache i czas odpowiedzi serwera
Zanim przeglądarka zacznie rysować stronę, musi dostać odpowiedź z serwera. Ten czas, TTFB, jest pierwszą częścią LCP. Jeśli serwer potrzebuje sekundy na wygenerowanie karty produktu, trudno zmieścić całe ładowanie w 2,5 sekundy. Dlatego pierwszym krokiem jest zwykle cache stron dla katalogu, trwały cache obiektów dla stron dynamicznych i hosting z aktualną wersją PHP oraz wystarczającymi zasobami.
Według web.dev czas do wyświetlenia największego elementu składa się z czterech części: czasu odpowiedzi serwera, opóźnienia przed rozpoczęciem pobierania zasobu, czasu jego pobierania i opóźnienia renderowania. Rozbicie pomaga ustalić, gdzie szukać poprawek. Przykład karty produktu przed optymalizacją i po niej:
[#chart:woo69b]
Jeśli największą część zajmuje czas serwera, pracuj nad cache i hostingiem. Jeśli opóźnienie przed pobraniem zdjęcia, zdjęcie jest odkrywane za późno, np. przez slider w JavaScripcie. Jeśli pobieranie trwa długo, obraz jest za ciężki. Jeśli dominuje opóźnienie renderowania, stronę blokują CSS, czcionki lub skrypty.
Krok 2 - obrazy produktów a LCP
Na karcie produktu elementem LCP jest zwykle główne zdjęcie, a w kategorii i na stronie głównej - baner lub pierwsze miniatury. Kilka zasad, które zwykle dają najszybszy efekt:
Właściwy rozmiar - WooCommerce generuje miniatury w kilku rozmiarach. Sprawdź w ustawieniach motywu i obrazków produktów, czy sklep nie wysyła zdjęć o szerokości kilku tysięcy pikseli tam, gdzie wyświetla kilkaset.
Nowoczesne formaty i kompresja - WebP lub AVIF oraz kompresja przy wgrywaniu, np. wtyczką do optymalizacji obrazów.
Bez leniwego ładowania głównego zdjęcia - WordPress domyślnie stosuje lazy loading dla obrazów, ale główne zdjęcie nad linią zgięcia powinno ładować się od razu i z wysokim priorytetem. Sprawdź, czy motyw lub wtyczka optymalizacyjna tego nie psuje.
Ostrożnie ze sliderami - galeria budowana w całości przez JavaScript opóźnia pojawienie się pierwszego zdjęcia.
Szybkość to tylko jedna strona karty produktu. O tym, jak dobrać zdjęcia i opis pod sprzedaż, piszemy w tekście o tym, jak przygotować kartę produktu w WooCommerce, która sprzedaje.
Krok 3 - skrypty, wtyczki i INP
INP mierzy, jak szybko strona reaguje wizualnie na kliknięcie, dotknięcie lub naciśnięcie klawisza. Według web.dev wynik do 200 milisekund jest dobry, a powyżej 500 milisekund - słaby. W sklepie INP psują najczęściej długie zadania JavaScript: filtry przeładowujące listę produktów, warianty z ciężką logiką, czaty, widżety opinii, pop-upy i rozbudowane zestawy tagów marketingowych.
Dokumentacja deweloperska WooCommerce zaleca twórcom rozszerzeń ładowanie skryptów i stylów tylko na stronach, które ich potrzebują, minifikację plików i leniwe ładowanie obrazów. W gotowym sklepie oznacza to przegląd wtyczek: które ładują pliki na każdej podstronie, choć działają tylko w jednym miejscu. Dobrym przykładem jest sam WooCommerce - od wersji 7.8 przestał domyślnie ładować skrypt odświeżania koszyka (cart fragments) na wszystkich stronach, bo wysyłał dodatkowe żądanie przy każdej odsłonie.
Tagi marketingowe, piksele i czaty
Sklep prowadzący kampanie ma zwykle kilka narzędzi naraz: tag Google, piksel Meta, narzędzie do map ciepła, czat, widżet opinii i system do e-mail marketingu. Każde z nich ładuje własny JavaScript, często na każdej podstronie. Przejrzyj listę raz na kwartał i usuń narzędzia, z których nikt nie korzysta. Te, które zostają, ładuj przez jeden menedżer tagów, z jasnymi regułami, gdzie mają działać - czat nie musi pojawiać się na checkoucie, a narzędzie do ankiet na każdej karcie produktu.
Filtry produktów i wyszukiwarka
Filtry w kategoriach to jedno z miejsc, gdzie klient klika najczęściej, więc mają duży wpływ na INP. Wtyczki filtrów działają różnie: część przeładowuje całą stronę, część pobiera wyniki w tle i przebudowuje listę produktów. Przy dużym katalogu sprawdź, ile trwa reakcja na kliknięcie filtra na słabszym telefonie, a nie tylko na komputerze. Jeśli lista zamiera na sekundę, przyczyną jest zwykle zbyt dużo pracy JavaScriptu albo wolne zapytanie do bazy.
[#tip] Każdą wtyczkę testuj włączoną i wyłączoną na kopii sklepu - tak samo radzi dokumentacja WooCommerce twórcom rozszerzeń. Różnica w wynikach pokaże, ile kosztuje dana funkcja i czy jest warta swojej wagi.
Krok 4 - stabilność układu i CLS
CLS liczy nieoczekiwane przesunięcia elementów podczas wczytywania strony. Dobry wynik to 0,1 lub mniej, słaby - powyżej 0,25. W sklepie przesunięcia powodują zwykle zdjęcia bez określonej szerokości i wysokości, banery i paski promocyjne doładowywane skryptem, okno zgody na cookies wstawiane nad treścią, czcionki zmieniające rozmiar tekstu po wczytaniu oraz bloki opinii lub produktów polecanych dopisywane pod ceną.
Rozwiązanie jest podobne w każdym przypadku: zarezerwuj miejsce na element, zanim się pojawi. Zdjęcia muszą mieć wymiary, banery stałą wysokość, a okno zgody powinno pojawiać się jako nakładka, a nie przesuwać treść. Przy przyciskach dodania do koszyka i cenie przesunięcia są szczególnie szkodliwe, bo klient może kliknąć w inne miejsce, niż zamierzał.
Osobną sprawą są czcionki. Motyw, który ładuje kilka krojów pisma w wielu grubościach, wydłuża ładowanie i może powodować przeskok tekstu, gdy czcionka docelowa zastąpi zastępczą. Ogranicz liczbę krojów i grubości do tych, które naprawdę są w użyciu, rozważ hostowanie czcionek na własnym serwerze zamiast pobierania ich z zewnętrznych usług i sprawdź, czy motyw pozwala wstępnie załadować najważniejszy krój.
Najczęstsze problemy z Core Web Vitals w sklepach WooCommerce i kierunki poprawek zebraliśmy w jednym miejscu:
[#chart:woo69c]
Czy sklep WooCommerce potrzebuje wyniku 100 w Lighthouse?
Nie. Wynik Lighthouse to ocena testu laboratoryjnego, a Google w raporcie Core Web Vitals patrzy na dane prawdziwych użytkowników. Sklep z wynikiem 70 w teście może mieć dobre Core Web Vitals w Search Console, a sklep z wynikiem 95 - słabe, jeśli klienci korzystają głównie ze starszych telefonów i wolnych sieci. Wynik laboratoryjny traktuj jako narzędzie do porównań, a nie cel sam w sobie. Dla orientacji: dokumentacja deweloperska WooCommerce wskazuje twórcom rozszerzeń, że prosty sklep powinien osiągać w Lighthouse wynik wydajności 90 lub wyższy. Rozbudowany sklep z wieloma integracjami nie musi trzymać tego poziomu na każdej stronie, ale powinien mieć dobre wartości LCP, INP i CLS na kartach produktów i kategoriach, bo to tam trafia większość ruchu z reklam i wyszukiwarki.
Koszyk i checkout - szybkość bez cache stron
Koszyk i zamówienie nie mogą być zapisane w cache stron, bo pokazują dane konkretnego klienta. Ich szybkość zależy więc od wydajności serwera, cache obiektów i liczby wtyczek, które dokładają skrypty do formularza. Przy optymalizacji uważaj na łączenie i opóźnianie skryptów, bo pole płatności lub przycisk zamówienia mogą przestać działać. Jak uprościć sam formularz, opisujemy w tekście o tym, jak skrócić checkout w WooCommerce.
Plan poprawy Core Web Vitals w WooCommerce
Optymalizacja działa najlepiej jako cykl, a nie jednorazowa akcja. Każda nowa wtyczka, kampania z pikselem albo baner może cofnąć wcześniejsze efekty. Przykładowy plan pracy:
Zmierz stan wyjściowy w Search Console i PageSpeed Insights dla głównych szablonów stron.
Wybierz najsłabszy wskaźnik na najważniejszym szablonie, zwykle karcie produktu.
Wprowadź jedną zmianę na stagingu i porównaj wynik w Lighthouse.
Sprawdź koszyk, checkout i zamówienie testowe po zmianie.
Wdróż zmianę na sklep i oznacz poprawkę w Search Console.
Po 28 dniach porównaj dane terenowe i zaplanuj kolejny krok.
Jeśli dopiero zakładasz sklep, łatwiej zaplanować wydajność od początku - wybrać lekki motyw, ograniczyć wtyczki i dobrać hosting. Pełną listę kroków startowych znajdziesz we wpisie o tym, jak założyć sklep WooCommerce od zera w 2026 roku.
Jak Vinson pomaga z szybkością sklepów WooCommerce
W Vinson budujemy i rozwijamy sklepy na WooCommerce oraz integrujemy je z Allegro i Base. Przy pracy nad szybkością:
mierzymy Core Web Vitals dla głównych szablonów stron sklepu,
porządkujemy wtyczki, skrypty marketingowe i obrazy produktów,
ustawiamy cache tak, żeby nie psuł koszyka i checkoutu,
każdą zmianę testujemy na stagingu z zamówieniem testowym.
Szczegóły znajdziesz na stronie sklepy na WooCommerce z Vinson.
Najczęściej zadawane pytania
Jakie wartości Core Web Vitals są dobre?
Według Google dobry wynik to LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1. Słabe wartości to LCP powyżej 4 sekund, INP powyżej 500 milisekund i CLS powyżej 0,25. Wyniki ocenia się na 75. percentylu odsłon, osobno dla telefonów i komputerów.
Jak sprawdzić szybkość sklepu WooCommerce?
Dane prawdziwych użytkowników znajdziesz w raporcie Core Web Vitals w Google Search Console i w PageSpeed Insights. Do testów przed zmianą i po niej użyj Lighthouse w Chrome. Mierz szablony stron, np. kartę produktu i kategorię, a nie tylko stronę główną.
Dlaczego sklep WooCommerce wolno działa na telefonie?
Najczęstsze przyczyny to zbyt duże zdjęcia, dużo skryptów z wtyczek i tagów marketingowych oraz wolna odpowiedź serwera bez cache. Telefony mają słabsze procesory, więc ciężki JavaScript bardziej pogarsza reakcję strony, czyli INP. Zacznij od pomiaru i przeglądu wtyczek ładujących się na każdej podstronie.
Czy więcej wtyczek zawsze spowalnia WooCommerce?
Nie każda wtyczka spowalnia sklep, ale każda może dokładać zapytania do bazy, skrypty i style. Liczy się to, co i gdzie ładuje. Najlepiej testować sklep z daną wtyczką włączoną i wyłączoną i porównać wyniki.
Ile trwa poprawa Core Web Vitals w Search Console?
Raport w Search Console opiera się na danych z ostatnich 28 dni, więc efekt poprawki widać tam z opóźnieniem. Po naprawie możesz rozpocząć śledzenie, a Google przez 28 dni sprawdzi, czy problem zniknął. Testy laboratoryjne pokażą zmianę od razu.
Szybki sklep WooCommerce to lepsze doświadczenie klienta, sprawniejsze kampanie i mniej porzuconych zakupów. Jeśli chcesz poprawić Core Web Vitals bez ryzyka dla koszyka i checkoutu, sprawdź sklep na WooCommerce z Vinson - zaczniemy od pomiaru głównych stron Twojego sklepu.
