Wolny sklep internetowy to poważny problem. Może obniżać sprzedaż, podnosić koszty reklam i szkodzić pozycji w SEO. Najtrudniejsze jest to, że strona wciąż pozornie „działa”, więc łatwo ignorować problem — dopóki statystyki nie zaczną drastycznie spadać.
Oto historia tego, jak poprawiliśmy szybkość działania obciążonego sklepu WooCommerce. Skróciliśmy czas pełnego załadowania o 71% — bez stawiania strony od nowa, bez zmiany designu i bez modyfikowania wyglądu sklepu.
Większość prac odbyła się za kulisami. Prawidłowo skonfigurowaliśmy Cloudflare, wdrożyliśmy pamięć podręczną obiektów Redis na serwerze, wyczyściliśmy bazę danych oraz zredukowaliśmy ilość danych CSS, JavaScript i obrazów ładowanych przez przeglądarkę.
Oto co zastaliśmy, co zmieniliśmy i dlaczego miało to kluczowe znaczenie.
Punkt wyjścia: lata wzrostu bez porządków
Klient prowadzi dojrzały sklep e-commerce w branży sprzętu ochronnego i BHP. Sklep rozwijał się od lat — posiadał tysiące produktów, dobry ruch organiczny i stabilną sprzedaż.
Z zewnątrz wszystko wyglądało w porządku.
Jednak pod powierzchnią strona z czasem mocno przybrała na wadze. To powszechny problem starszych sklepów WooCommerce. Wtyczki dodawano po kolei przez lata. Każda rozwiązywała jakiś konkretny problem, ale wiele z nich dokładało dodatkowe zapytania do bazy danych i nadmiarowy kod we frontendzie.
Obrazy często serwowano w zbyt dużych rozdzielczościach. Brakowało solidnej konfiguracji pamięci podręcznej (cache). Wiele stron było generowanych od zera przez PHP i MySQL przy każdym odwiedzającym. Baza danych zawierała też lata zaszłości: przedawnione sesje, stare metadane, rewizje wpisów oraz pozostałości po usuniętych wtyczkach.
Nie była to wina jednego dużego błędu. To naturalny efekt funkcjonowania obciążonego sklepu przez lata bez regularnych prac optymalizacyjnych.
Prowizoryczne rozwiązania nakładane na inne tymczasowe poprawki… kumulujące się aż do momentu utraty równowagi…
Objawy były jednoznaczne:
- strony ładowały się w pełni około 8–10 sekund,
- proces składania zamówienia (checkout) działał wolno, szczególnie na urządzeniach mobilnych,
- wskaźniki Core Web Vitals spadły do czerwonego zakresu („wymaga poprawy”),
- serwer wykonywał ogromną pracę przy niemal każdych odwiedzinach.
Dla sklepu opierającego się na ruchu organicznym było to realne zagrożenie dla biznesu.
Co pokazały liczby
Zanim przeszliśmy do zmian, dokładnie zmierzyliśmy parametry strony.
| Metryka | Przed | Po | Zmiana |
|---|---|---|---|
| Czas pełnego załadowania | 8.3 s | 2.4 s | −71% |
| Time to First Byte (TTFB) | 1,820 ms | 190 ms | −90% |
| Largest Contentful Paint (LCP) | 6.4 s | 1.9 s | −70% |
| Całkowity rozmiar strony | 5.6 MB | 1.7 MB | −70% |
| Zapytania HTTP | 174 | 68 | −61% |
| Wynik wydajności Lighthouse | 29 | 94 | +65 pkt |
Kluczowym wskaźnikiem okazał się Time to First Byte (TTFB).
TTFB określa, ile czasu zajmuje serwerowi rozpoczęcie przesyłania strony. W tym przypadku przeglądarka czekała niemal dwie sekundy, zanim w ogóle zaczęła właściwe pobieranie danych.
To jednoznacznie wskazało, że problem leżał nie tylko w przeglądarce. Sam serwer działał zbyt wolno.
Diagnoza: gdzie uciekał czas
Przeanalizowaliśmy stronę w trzech obszarach:
- warstwę sieciową, używając WebPageTest oraz analityki Cloudflare,
- frontend, korzystając z Lighthouse i GTmetrix,
- samą aplikację WordPress, badając zapytania do bazy danych oraz wydajność po stronie serwera.
Problemy były bardzo czytelne.
Po pierwsze, niemal każde zapytanie trafiało bezpośrednio do serwera źródłowego (origin server). Brakowało prawidłowego edge caching, przez co użytkownicy z różnych lokalizacji musieli dłużej czekać na zasoby i strony.
Po drugie, dynamiczne strony WooCommerce działały wolno. Koszyk, strona zamówienia, konto użytkownika oraz sesje zalogowanych klientów wielokrotnie wykonywały te same, zasobożerne zapytania do bazy.
Po trzecie, przeglądarka miała zbyt dużo pracy. Strona ładowała ciężkie obrazy, blokujące renderowanie pliki CSS i JavaScript oraz pliki wtyczek na stronach, na których w ogóle nie były potrzebne.
Zajęliśmy się więc wszystkimi trzema warstwami.
Część pierwsza: prawidłowa konfiguracja Cloudflare
Umieściliśmy Cloudflare przed stroną jako CDN i reverse proxy.
Oznacza to, że pliki statyczne — takie jak obrazy, CSS, JavaScript czy fonty — mogły być serwowane z sieci krawędziowej (edge network) Cloudflare, zamiast stale obciążać serwer główny.
Włączyliśmy również kompresję Brotli oraz protokół HTTP/3, co pozwoliło zmniejszyć rozmiar plików i przyspieszyć ich przesyłanie. Wdrożyliśmy także optymalizację obrazów, serwując nowoczesne formaty (takie jak WebP) tam, gdzie było to możliwe.
W przypadku WooCommerce kluczowe jest to, że nie można buforować (cache’ować) wszystkiego bezrefleksyjnie.
Niektóre strony są spersonalizowane pod konkretnego klienta. Koszyk, zamówienie i konto użytkownika muszą być zawsze aktualne — nie chcesz przecież, aby jeden klient zobaczył zawartość koszyka innego użytkownika.
Dlatego precyzyjnie skonfigurowaliśmy reguły buforowania. Strony katalogu i treści były cache’owane, natomiast koszyk, checkout, moje konto oraz sesje oparte na plikach cookie WooCommerce zostały wykluczone z pamięci podręcznej.
Wykorzystaliśmy również reguły firewalla Cloudflare do zablokowania szkodliwego ruchu generowanego przez boty i skrapery. Zmniejszyło to bezużyteczne obciążenie serwera i uwolniło zasoby dla rzeczywistych klientów.
Już ta pierwsza warstwa przyniosła ogromną różnicę. Obsługa wielu odwiedzających odbywała się teraz na poziomie Cloudflare, bez zmuszania serwera głównego do przetwarzania każdego zapytania.
Część druga: pamięć podręczna obiektów Redis
Cloudflare pomógł w przypadku stron statycznych i dających się buforować. Nie rozwiązało to jednak całego problemu.
WooCommerce nadal posiada dynamiczne podstrony, które muszą przetworzyć kod PHP i wykonać zapytania do bazy danych. W tym sklepie to właśnie te zapytania były główną przyczyną powolnego TTFB.
WordPress wielokrotnie pytał bazę MySQL o te same informacje: opcje, produkty, taksonomie, metadane, menu i inne powtarzające się dane.
W tym miejscu z pomocą przyszedł Redis.
Zainstalowaliśmy Redisa na serwerze i połączyliśmy WordPressa z trwałą pamięcią podręczną obiektów (persistent object cache). Redis przechowuje wyniki wielu zasobożernych zapytań do bazy bezpośrednio w pamięci RAM.
Dzięki temu, zamiast za każdym razem odwoływać się do MySQL po tę samą odpowiedź, WordPress pobiera ją błyskawicznie z pamięci operacyjnej.
To był największy pojedynczy sukces w optymalizacji.
TTFB spadł z około 1,8 sekundy do poniżej 200 milisekund na wielu dynamicznych stronach. Co ważniejsze — pozostał na niskim poziomie nawet przy skokach ruchu.
To obszar, którego sam Cloudflare nie jest w stanie naprawić. W przypadku WooCommerce buforowanie po stronie serwera jest często równie istotne co użycie CDN.
Przy okazji przeprowadziliśmy czyszczenie bazy danych. Usunęliśmy wygasłe dane tymczasowe (transients), stare rewizje, osamotnione metadane, pozostałości po nieużywanych wtyczkach oraz zbędne automatycznie ładowane opcje (autoloaded options).
Czystsza baza danych to mniej danych do przetworzenia dla WordPressa i MySQL.
Część trzecia: redukcja przeładowania we frontendzie
Ostatnim etapem była optymalizacja frontendu.
Nawet gdy serwer zaczął działać znacznie szybciej, przeglądarka wciąż miała do pobrania i przetworzenia zbyt wiele danych.
Uporządkowaliśmy to krok po kroku.
Zminifikowaliśmy pliki CSS i JavaScript. Połączyliśmy wybrane pliki tam, gdzie miało to sens. Działanie niekrytycznych skryptów JavaScript zostało odroczone (defer), aby nie blokowały renderowania widoku strony.
Usunęliśmy również skrypty i style z podstron, które ich nie wykorzystywały. Dla przykładu: pliki niektórych wtyczek ładowały się w obrębie całej witryny, mimo że były potrzebne zaledwie na kilku stronach.
Przeanalizowaliśmy listę wtyczek — usunęliśmy lub zastąpiliśmy te, które okazały się zbędne.
Istotną częścią problemu były także obrazy — stanowiły największy odsetek całkowitej wagi strony. Skonwertowaliśmy je do nowoczesnych formatów, dopasowaliśmy ich rozmiary do urządzeń końcowych oraz wdrożyliśmy leniwe ładowanie (lazy loading), by grafiki poniżej linii zgięcia (below the fold) nie ładowały się przedwcześnie.
Uporządkowaliśmy też fonty. Zredukowaliśmy ładowanie niepotrzebnych wariantów i zastosowaliśmy wstępne ładowanie (preload) kluczowych plików, aby uniknąć opóźnień i przesunięć układu (layout shifts).
Łącznie zmiany te zmniejszyły wagę strony o około 70% i zredukowały liczbę zapytań HTTP o ponad połowę.
Przeglądarka miała po prostu znacznie mniej pracy do wykonania.
Rezultat: 71% szybciej
Po wdrożeniu wszystkich poprawek czas pełnego załadowania strony spadł z 8,3 sekundy do 2,4 sekundy.
To poprawa o 71%.
Wskaźniki Core Web Vitals również przeszły do „zielonego” zakresu (dobry). To kluczowe, ponieważ szybkość nie jest tylko parametrem technicznym — wpływa bezpośrednio na SEO, doświadczenia użytkowników (UX), współczynnik konwersji i efektywność kampanii płatnych.
Wpływ na biznes był widoczny gołym okiem.
Użytkownicy spędzali w sklepie więcej czasu. Kluczowe landing page zanotowały niższy współczynnik odrzuceń, a klienci przeglądali więcej stron w trakcie jednej sesji. Proces składania zamówienia działał odczuwalnie płynniej, szczególnie na telefonach.
Dla sklepu generującego duży ruch organiczny tego typu optymalizacja to nie tylko sukces techniczny. To zmiana, która bezpośrednio wspiera pozycje w wyszukiwarce, konwersję i przychody.
Co powiedzielibyśmy innym właścicielom sklepów
Większość powolnych sklepów WooCommerce ma znacznie większy potencjał optymalizacyjny, niż mogłoby się wydawać.
Ten projekt nie wymagał rebrandingu ani przeprojektowywania interfejsu. Nie wymagał stawiania serwisu od nowa. Nie wymagał też przeprowadzki na zupełnie nową platformę.
Po zakończeniu prac sklep wyglądał dokładnie tak samo. Po prostu ładował się o wiele szybciej.
Największe zyski przyniosło naprawienie samych fundamentów:
- prawidłowa konfiguracja Cloudflare,
- pamięć podręczna obiektów Redis,
- wyczyszczenie bazy danych,
- porządki we wtyczkach,
- optymalizacja obrazów,
- optymalizacja i czyszczenie CSS oraz JavaScript.
Nawet jeśli masz wrażenie, że Twoja strona jest zbyt duża lub zbyt skomplikowana do optymalizacji, nie zakładaj, że jedyną opcją jest budowanie wszystkiego od zera. Wiele sklepów e-commerce posiada mnóstwo obszarów do szybkiej poprawy (tzw. low-hanging fruit), które mogą przynieść zauważalny skok wydajności, poprawę UX i w konsekwencji wyższe przychody.
Przebudowa od podstaw może wciąż być właściwą strategią długoterminową, ale rzadko jest najlepszym punktem wyjścia. Czasem największe zyski dają programiści, którzy potrafią zakasać rękawy, zanurkować w zastany kod i wycisnąć maks z tego, co już masz.
Choć każda strona jest inna, nasze doświadczenie pokazuje, że precyzyjna optymalizacja często daje ogromną poprawę — bez kosztów i chaosu związanych z tworzeniem serwisu na nowo.