Koszyk WooCommerce z 11,2 do 2,2 sekundy
Klient sprzedaje dwie książki przez własny sklep na WooCommerce. Zgłosił, że koszyk ładuje się 12,5 sekundy na telefonie i że konwersja tonie. W konsoli widział duplikaty skryptów i podejrzewał, że to one. Poprosił o diagnozę: co dokładnie zwalnia sklep i w jakiej kolejności to naprawiać.
Liczby
| strona | LCP przed | LCP po | po 4 tygodniach | wynik przed → po |
|---|---|---|---|---|
| koszyk | 11,2 s | 2,2 s | 2,8 s | 59 → 91 |
| zamówienie | 12,8 s | 3,4 s | 3,3 s | 54 → 81 |
| strona główna | 16,2 s | 9,3 s | 9,0 s | → 62 |
| landing Codziennika | 15,2 s | 9,8 s | 9,6 s | → 66 |
| landing Filozofii | 4,8 s | 5,1 s | 5,3 s | → 67 |
Pomiar „przed” z 25.07.2026, „po” z tego samego wieczoru po wdrożeniu, kontrolny z 20.08.2026. Za każdym razem PageSpeed Insights na mobile, na zimno, tym samym skryptem.
Co pokazał audyt
Liczba klienta się potwierdziła. W pomiarze z połowy lipca koszyk miał 11,0 s LCP, strona zamówienia 13,2 s, strona główna 16,2 s.
Hosting był niewinny. Serwer odpowiadał w 50 ms, a podstrona jednej z książek, na tym samym serwerze i tym samym WordPressie, ładowała się w 6,5 s. Różnicę robiły skrypty, nie maszyna.
Duplikacja, którą klient widział w konsoli, była prawdziwa, tylko siedziała warstwę niżej, niż patrzył. Koszyk ładował dwa pełne mechanizmy naraz: klasyczny WooCommerce i nowy, blokowy, oparty na Reakcie. Stąd 88 skryptów i dokument ważący 537 KB na jednej podstronie. Powielonych tagów script w źródle nie było, więc z konsoli tego nie było widać.
Do tego rzeczy, które na koszyku nie mają czego szukać: pełny SDK PayPala, siedem skryptów bramki płatności, skrypty strony produktu razem z wariantami i kalendarzem jQuery UI, Pixel i CAPI Facebooka na jakieś 250 KB. Strona zamówienia wysyłała 250 żądań sieciowych.
Co zrobiłem
Koszyk i zamówienie przeszły z bloków na klasyczne i dostały wygląd marki sklepu. Teraz serwer oddaje gotowy HTML, zamiast wysyłać szkielet, który przeglądarka dobudowuje JavaScriptem.
Doszła warstwa, która pilnuje, żeby każda strona ładowała tylko potrzebne jej skrypty. Koszyk zszedł ze 108 tagów script do 31, strona główna tak samo. To jest ta część, która działa dalej po zakończeniu zlecenia: nowa wtyczka nie ładuje się już wszędzie.
Opcja „zapakuj na prezent” działa bez osobnej wtyczki, własnym kodem, więc strona produktu też się odchudziła. Podwójny nagłówek i stopka, czyli blok HTML w Elementorze nałożony na elementy motywu, zniknęły z pięciu stron. Google Analytics wrócił jako jeden lekki fragment.
Czy to się utrzymało
Cztery tygodnie później zmierzyłem sklep ponownie, tym samym skryptem, po miesiącu bez mojej opieki: koszyk 2,8 s, zamówienie 3,3 s. Po sierpniowej rundzie aktualizacji wtyczek i bramki płatności koszyk wypadł jeszcze lepiej, 2,1 s i wynik 93.
Warunkiem odbioru było poniżej 4 sekund LCP na koszyku i stronie zamówienia. Trzymają go od lipca, z zapasem.
Czego nie obiecywałem
Strona główna i dwa landingi stoją na Elementorze i były spod gwarancji wyjęte. Zeszły z 16,2 do 9,3 s i z 15,2 do 9,8 s, bo ten sam ciężar skryptów ładował się na każdej podstronie, ale nie podawałem tam liczby, której potem bym nie utrzymał. Na page builderze takiej liczby się nie obiecuje.
PageSpeed na adresie zamówienia mierzy ścieżkę po przekierowaniu, bo robot wchodzi tam z pustym koszykiem, a pusty koszyk przerzuca gościa na koszyk. Kasę z produktem sprawdzam osobno, skryptem i wylogowaną przeglądarką.
Każda liczba wyżej ma datę pomiaru, bo cudzy sklep żyje. Klient dokłada treść i wtyczki, więc wynik bez daty przestaje być prawdą, zanim ktokolwiek go przeczyta.
Co powiedział klient
„Koszyk 2,2 sekundy zamiast 11,2 to skok, który realnie pewnie zmieni konwersję. […] Widać, że nie robiłeś tego na czas, tylko na efekt.”
Dominik, zespokojem.com
Twój koszyk też się wlecze?
Podeślij adres sklepu. Zmierzę koszyk i zamówienie tak samo jak wyżej, zanim porozmawiamy o cenie.
Zapytaj o przyspieszenie