Krótka odpowiedź: szybkość to nie metryka techniczna, tylko mnożnik dla całego lejka. Działa jednocześnie na konwersję, pozycje w wyszukiwarce i cenę płatnego kliknięcia. To jedyne ulepszenie, którego nie da się zrobić „tylko dla jednego kanału” — działa wszędzie naraz.
Co dokładnie mierzy Google
Od 2020 roku istnieją trzy metryki, które Google zbiera od prawdziwych użytkowników Twojej strony, a nie w laboratorium. Nazywają się Core Web Vitals, a progi wyglądają tak:
| Metryka | Co znaczy po ludzku | Próg „dobry” |
|---|---|---|
| LCP | Kiedy pojawia się główny blok strony — zdjęcie produktu, nagłówek | do 2,5 s |
| INP | Jak szybko strona reaguje na kliknięcia | do 200 ms |
| CLS | Jak bardzo treść skacze podczas ładowania | do 0,1 |
Szczegół, który regularnie umyka: liczy się 75. percentyl. Nie wystarczy, że „u mnie na laptopie otwiera się szybko” — trzy czwarte prawdziwych wizyt, łącznie ze starymi Androidami na transmisji komórkowej, musi zmieścić się w progu.
W sklepach na WordPressie najczęściej wykłada się INP: strona zdąży się narysować, ale przez kolejną sekundę nie reaguje na kliknięcia, bo w tle wciąż pracują skrypty wtyczek, czatu, pikseli i koszyka. Użytkownik nie czyta tego jako „wolna strona”, tylko jako „strona się zepsuła” — i wraca.
Ile to kosztuje w pieniądzach
Najuczciwsza publiczna ilustracja to studium przypadku Vodafone na web.dev: test A/B na dwóch wizualnie identycznych wersjach strony pokazał, że poprawa LCP o 31% dała 8% wzrostu sprzedaży. Bez redesignu, bez nowej promocji — sama szybkość.
Przelicz to na własne liczby tak samo jak w pierwszym temacie: jeśli sklep robi 40 000 € miesięcznie, 8% to 3200 € co miesiąc. Praca nad szybkością jest jednorazowa.
Jest jeszcze drugi efekt, którego rzadko się liczy: szybkość zmienia koszt reklamy. Wolna strona docelowa pogarsza wynik jakości w systemach reklamowych i podnosi cenę kliknięcia. Płacisz podwójnie — mniej osób dociera, a każde dotarcie kosztowało więcej.
Dlaczego zwalnia akurat WooCommerce
WooCommerce sam w sobie nie jest wolny. Wolnym robi go typowa konstrukcja wokół niego. Z moich audytów kolejność winowajców jest prawie zawsze taka:
1. Motyw z kreatorem. Wielozadaniowy motyw z wizualnym builderem ciągnie za sobą dziesiątki plików CSS i JS na każdą stronę — w tym te potrzebne wyłącznie na stronie głównej. To najczęstsza i najbardziej niedoceniana przyczyna.
2. Wtyczki ładujące się wszędzie. Wtyczka slidera, formularza, opinii i kalkulatora dostawy rejestrują swoje skrypty w całym sklepie, a nie tylko tam, gdzie są używane.
3. Brak cache'u stron. Każde wejście w kategorię to pełny cykl PHP plus zapytania do bazy. Na hostingu współdzielonym za 5 €/mies. to 1,5–3 sekundy do pierwszego bajtu.
4. Fragmenty koszyka. WooCommerce domyślnie wywołuje wc-ajax=get_refreshed_fragments na każdej stronie, żeby odświeżyć licznik koszyka. Na skądinąd zbuforowanej stronie to jedyne niebuforowalne żądanie, które blokuje resztę.
5. Zdjęcia w oryginalnym rozmiarze. Fotograf oddał JPEG-i 4000 px po 3 MB i wgrano je bez zmian. Przeglądarka pobiera 3 MB, żeby pokazać obrazek szerokości 600 px.
6. Skrypty zewnętrzne. Czat, piksele, mapy, widżety opinii. Każdy wygląda niewinnie, razem zjadają INP.
Co naprawiać w kolejności zwrotu
Kolejność ma znaczenie — najtańsze i najskuteczniejsze najpierw:
- Zdjęcia — konwersja do WebP/AVIF, serwowanie właściwego rozmiaru, leniwe ładowanie wszystkiego poniżej pierwszego ekranu, ale nie głównego zdjęcia produktu (to psuje LCP)
- Cache stron + object cache — statyczne buforowanie kategorii i kart produktów, Redis lub Memcached dla zapytań do bazy
- Wyłączenie fragmentów koszyka tam, gdzie nie są potrzebne, albo zastąpienie ich lekkim odświeżaniem licznika
- Przegląd wtyczek — usunąć nieużywane, ograniczyć ładowanie skryptów do stron, które ich naprawdę potrzebują
- Odroczenie skryptów zewnętrznych — czat i piksele ładować po interakcji, a nie w
<head> - Fonty — własny hosting,
font-display: swap, tylko używane odmiany - Hosting — jeśli po tym wszystkim TTFB nadal przekracza 600 ms, problem jest w sprzęcie, nie w kodzie
Pierwsze trzy punkty dają zwykle 70% efektu i zajmują kilka dni. Szczegóły techniczne każdego z nich są w sąsiednim przewodniku: Core Web Vitals, obrazy, fonty i skrypty oraz buforowanie.
Wstawka dla programisty
- Włącz HPOS. High-Performance Order Storage przenosi zamówienia z
wp_posts/wp_postmetado dedykowanych tabel. Na sklepie z dziesiątkami tysięcy zamówień zmienia to zarówno panel, jak i każde zapytanie o zamówienia. - Mierz dane polowe, nie laboratoryjne. Tryb laboratoryjny PageSpeed Insights jest wygodny do debugowania, ale ocena idzie z danych polowych CrUX. Raport Core Web Vitals w Search Console mówi prawdę.
- Szukaj długich zadań, nie „wagi strony”. INP zabijają konkretne handlery: przerysowanie koszyka, skrypt slidera, synchroniczny kod analityki. Profiluj zakładkę Performance zamiast liczyć kilobajty.
- Sprawdź opcje autoload.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'— jeśli to megabajty, każde żądanie ciągnie ten balast. Zwykle są to pozostałości po usuniętych wtyczkach. - Weryfikuj na profilu mobilnym z dławieniem sieci i CPU. Na Twoim MacBooku zawsze jest szybko.
Kiedy optymalizacja motywu przestaje pomagać
Jest granica, za którą nie ma już czego poprawiać: motyw i wtyczki narzucają minimum pracy, którego nie da się usunąć bez psucia sklepu. Objawy, że ją osiągnąłeś:
- Mobilne LCP utknęło na 3–4 sekundach, mimo że zdjęcia i cache są już zrobione
- Każda nowa wtyczka wyraźnie pogarsza metryki
- Musisz wybierać między „szybko” a „ma potrzebne funkcje”
W tym punkcie zostają dwie drogi. Pierwsza to obciąć funkcjonalność: zrezygnować z buildera, przepisać szablony, usunąć część wtyczek. Druga to rozdzielić witrynę i backend: zostawić WooCommerce do produktów, zamówień i panelu, a frontend zbudować osobno na szybkim stosie. Jak to działa i kiedy się opłaca, opisuje strona WooCommerce i headless — łącznie z uczciwym opisem sytuacji, gdy się nie opłaca. Gotowe rozwiązanie tego typu to NextWoo, witryna w Next.js na istniejącym WooCommerce.
Praktyczny test
- Otworzyłem raport Core Web Vitals w Google Search Console i obejrzałem adresy mobilne
- Znam LCP, INP i CLS z danych polowych, a nie tylko z testu laboratoryjnego
- Sprawdziłem wagę głównego zdjęcia produktu — poniżej 150–200 KB
- Sprawdziłem TTFB na stronie kategorii — poniżej 600 ms
- Wyłączyłem lub ograniczyłem fragmenty koszyka
- Przejrzałem listę wtyczek: każda jest albo potrzebna, albo usunięta
- Policzyłem, ile 8% wzrostu sprzedaży jest warte w moich pieniądzach
Co dalej
Szybki sklep to warunek, a nie powód zakupu. Dalej odwiedzający trafia na kartę produktu i decyduje, czy ufa Ci na tyle, by oddać pieniądze: karta produktu, która sprzedaje.
Jeśli chcesz to komuś przekazać: przyspieszenie strony — audyt, lista prac według priorytetu i stała cena za wdrożenie.