Gdy klasyczny hosting współdzielony klęka pod naporem koszyków, a wysokie TTFB niszczy Twoją konwersję w Google Ads. Przestań przepłacać za mocniejszy sprzęt — zoptymalizuj obecne środowisko pod dynamiczną aplikację stanową.
Środowisko zastane
Nie narzucam jedynego słusznego dostawcy ani dystrybucji. Optymalizuję i przejmuję opiekę nad infrastrukturą tam, gdzie obecnie zarabia Twój sklep. Wyciskam maksimum stabilności bez wymuszonych, ryzykownych migracji.
Najpopularniejsze środowiska bazowe. Optymalizuję pakiety upstreamowe, konfiguruję stabilne repozytoria i dbam o przewidywalność cyklu LTS.
Systemy klasy enterprise. Znam specyfikę SELinux, firewalld i zarządzania politykami bezpieczeństwa pod kątem WooCommerce.
RunCloud, CyberPanel, Plesk, cPanel. Analizuję logi bezpośrednio w systemie, omijając ograniczenia graficznych interfejsów.
Diagnoza techniczna
Większość agencji interaktywnych traktuje WooCommerce jak statycznego bloga. To kardynalny błąd poznawczy, który kończy się drogimi fakturami za hosting. O ile klasyczny blog może zostać zbuforowany w 99% i zaserwowany bezpośrednio z pamięci RAM serwera WWW, o tyle WooCommerce jest wysoce dynamiczną aplikacją stanową.
Każde kliknięcie „Dodaj do koszyka", filtrowanie produktów po cechach, odświeżenie minikoszyka czy przejście do podstrony checkout generuje unikalną sesję użytkownika. Te żądania całkowicie omijają tradycyjny page-cache i uderzają bezpośrednio w procesy PHP-FPM oraz bazę danych MySQL/MariaDB.
Jeśli konfiguracja serwera nie uwzględnia optymalizacji puli połączeń bazy danych
(odpowiedni tuning parametru innodb_buffer_pool_size)
oraz brakuje wdrożonego mechanizmu
Redis Object Cache,
serwer zacznie losowo zwracać błędy 502 Bad Gateway
lub 504 Gateway Timeout
dokładnie w momencie, gdy na sklep wejdzie największy ruch z kampanii reklamowej.
Pożary
Strona główna ładuje się szybko, ale proces zakupowy „wisi"? To wina
przeciążonego PHP lub bazy danych obsługującej sesje klientów
(_wc_session_).
Rozwiązanie: Przeniesienie sesji do pamięci RAM (Redis) i optymalizacja procesów PHP-FPM.
Tabele wp_options
oraz wp_commentmeta
potrafią urosnąć do kilkunastu gigabajtów przez błędnie napisane wtyczki
lub miliony wygasłych transientów.
Rozwiązanie: Czyszczenie bazy, wdrożenie odpowiednich
indeksów SQL oraz optymalizacja parametru
innodb_buffer_pool_size.
Skrypty WooCommerce bez przerwy odpytują serwer o stan koszyka
(tzw. cart fragments —
wc-ajax=get_refreshed_fragments),
co przy kilkudziesięciu użytkownikach jednocześnie generuje setki procesów
PHP i 100% obciążenia procesora.
Rozwiązanie: Cache'owanie dynamicznych fragmentów na poziomie serwera WWW (OpenLiteSpeed) lub ich inteligentne ograniczanie w kodzie.
Wdrożyłeś Baselinkera lub Subiekta, a podczas importu stanów magazynowych klienci nie mogą sfinalizować zakupu? To klasyczny konflikt zapytań SQL na tabelach produktowych.
Rozwiązanie: Konfiguracja priorytetów zapytań SQL (Query Optimization) oraz izolacja ruchu API na osobny proces.
Procedura
Nie zgaduję. Nie stosuję „partyzantki". Każde wdrożenie przechodzi przez tę samą, sprawdzoną metodologię opartą na danych z logów, nie na domysłach.
Nie zgaduję. Analizuję logi błędów (error.log), logi wolnych zapytań SQL (slow-query.log) oraz monitoruję zużycie zasobów (CPU, RAM, I/O).
Pracuję na systemie Twojego dostawcy (Ubuntu, Debian, AlmaLinux). Jeśli Twój VPS ma zapas mocy, najpierw wyciskam 100% z konfiguracji oprogramowania, zanim zasugeruję zmianę maszyny.
Konfiguruję duet OpenLiteSpeed (lub Nginx) + Redis Object Cache. Sprawiam, że serwer przetwarza powtarzalne operacje w pamięci RAM, zamiast bez przerwy pytać dyski NVMe.
Twój sklep jest monitorowany w trybie 24/7. Wychwytuję anomalie (np. nagły skok błędów 5xx lub wyczerpanie pamięci RAM) zanim zauważą to Twoi klienci.
Stack 2026
Każdy komponent poniżej jest dostrojony konkretnie pod aplikację stanową WooCommerce, a nie pod ogólnego WordPressa-bloga.
| Komponent | Standard 2026 | Dlaczego pod WooCommerce |
|---|---|---|
| System (OS) | Ubuntu 24.04 LTS / Debian 12 | Długoterminowe wsparcie, stabilne pakiety bezpieczeństwa, przewidywalny cykl. |
| Serwer WWW | OpenLiteSpeed + LSCache | Natywna obsługa routingu WordPressa. Tysiące jednoczesnych połączeń bez wzrostu RAM. |
| Baza Danych | MariaDB 10.11 LTS | Agresywny tuning innodb_buffer_pool_size. Tabele wp_options i wp_woocommerce_order_items w RAM. |
| Pamięć Cache | Redis Object Cache | Absolutny fundament. Przechowuje transienty WordPressa w RAM, odciążając NVMe. |
| Wersja PHP | PHP 8.3 + OPcache | Szybsze operacje na tablicach w kodzie wtyczek Woo bez ryzyka błędów 500. |
Dowód w liczbach
Prawdziwe logi z terminala, zamiast obietnic marketingowych.
>_ Status: Wszystkie wdrożenia objęte klauzulą NDA. Skontaktuj się po referencje.
FAQ
Nie. Bardzo często problemem nie jest sam serwer, a jego domyślna, „pudełkowa" konfiguracja u dostawcy hostingu. Poprzez optymalizację konfiguracji PHP-FPM, włączenie OPcache oraz odpowiednie ustawienie buforów bazy MariaDB/MySQL potrafię drastycznie przyspieszyć checkout bez konieczności migracji i generowania przestojów.
W przypadku WooCommerce i WordPressa, OpenLiteSpeed (lub LiteSpeed Enterprise) w połączeniu z natywną wtyczką LSCache wykazuje najwyższą wydajność przy obsłudze dużego, jednoczesnego ruchu. OLS natywnie przetwarza reguły routingu WordPressa i bezpośrednio komunikuje się z Redis Object Cache, eliminując narzut na procesor. Nginx jest świetny, ale wymaga znacznie bardziej złożonej konfiguracji mikro-cache'u dla e-commerce.
Dostęp odbywa się wyłącznie przez bezpieczne klucze SSH (brak logowania na hasło dla konta root). Wszelkie poświadczenia przechowywane są w szyfrowanych menedżerach haseł (Bitwarden / 1Password), a przed rozpoczęciem prac podpisujemy umowę NDA. $ cd /security — pełen hardening serwerów →
$ ssh root@twoj-serwer — audyt zerowy
Zleć audyt infrastruktury