W 2026 roku hosting WordPressa to decyzja architektoniczna, a nie tylko abonament. Wybierasz, gdzie działa PHP, gdzie stoi MySQL, co jest cachowane na brzegu sieci i którzy podprocesorzy przetwarzają dane osobowe twoich użytkowników z Polski i UE.
Ten przewodnik porównuje managed hosting, chmurę IaaS/PaaS i warstwy edge. Potem omawia PHP workers, object cache, granice WooCommerce na edge, lokalizację danych w świetle RODO i to, jak CI/CD utrzymuje powtarzalne środowiska. Celem jest podstawa decyzji, którą przekażesz zespołowi utrzymania, a nie lista dostawców.
Przy przejściu od wyboru do pomiarów przydadzą się mój poradnik o przyspieszaniu strony WordPress i rozdziały o serwerze w WordPress Advanced Administration Handbook.
Czym różni się hosting managed, chmura i edge dla WordPressa
Te trzy modele rozwiązują różne problemy. Źle połączone sprawiają, że płacisz za złożoność, nie dostając niższego TTFB tam, gdzie to ważne.
Managed hosting WordPress
Platformy managed są właścicielem stosu: PHP-FPM, Nginx albo LiteSpeed, MySQL, codzienne kopie zapasowe, staging i często WP-CLI. Nie łatasz systemu operacyjnego, ale dziedziczysz ich limity równoległych workers, interwałów crona i obsługiwanych object cache.
Typowe zastosowanie: strony marketingowe, blogi, mniejsze sklepy WooCommerce z przewidywalnym ruchem i zespoły bez własnego DevOps. Słabość: gdy zamówienie albo panel uderzy w limit workers, zostają tylko przyciski „zmień plan” albo „przenieś się”.
Hosting w chmurze (IaaS i PaaS)
Na AWS, Google Cloud, Azure lub europejskich alternatywach sam budujesz (albo przez Terraform) maszyny wirtualne, zarządzaną bazę, load balancer i sieć. Kubernetes jest typowy dla dużych flot, ale dobrze dobrana grupa autoskalowania z PHP-FPM i Redisem wystarcza wielu średnim sklepom.
Zaleta: sterujesz burstem CPU, IOPS bazy i regionem. Wada: łatanie, certyfikaty, agregacja logów i failover są po twojej stronie. Chmura bez runbooków to po prostu droższe przestoje.
Hosting edge z CDN i Workers
Edge oznacza tu CDN, cache HTML na brzegu i obliczenia blisko użytkownika (na przykład Cloudflare Workers, szerzej w moim tekście o Workers przed WordPressem i WooCommerce). Edge rzadko oznacza „WordPressa bez originu”. To warstwa przed originem: trafienia cache dla stron anonimowych, filtrowanie botów, przetwarzanie obrazów, testy A/B bez wywołania PHP.
Chybienia cache, zalogowani użytkownicy i żądania POST do zamówienia nadal trafiają do originu. Zaplanuj to, inaczej edge stanie się iluzją szybkości.
Jakie wersje PHP i bazy danych zaleca WordPress
Zanim porównasz dostawców, sprawdź wymagania bazowe. Na stronie wymagań WordPress.org zaleca PHP 8.3 lub nowsze, MySQL 8.0 lub nowsze albo MariaDB 10.11 lub nowsze oraz obsługę HTTPS. To zalecenia dla hostingu, a nie gwarancja, że każda twoja wtyczka obsługuje tę samą wersję.
W praktyce wynikają z tego trzy pytania do nowego dostawcy: jaka wersja PHP działa dziś na produkcji, jak szybko pojawi się następna i czy można wybrać wersję dla każdego środowiska, żeby przetestować nową na stagingu przed przeniesieniem produkcji. Plan managed, który trzyma cię na starszej gałęzi PHP, daje ci projekt aktualizacji w harmonogramie dostawcy zamiast twojego.
Ilu PHP workers potrzebuje WordPress
PHP worker to jeden proces (w niektórych stosach wątek), który obsługuje jedno żądanie naraz. Liczba workers razy średni czas przetwarzania wyznacza pułap żądań na sekundę, zanim kolejka urośnie, a TTFB wzrośnie.
Przykład rachunkowy: sklep z 20 workers i średnim czasem PHP 400 ms obsłuży z grubsza 50 żądań na sekundę, zanim zacznie się kolejka. Jeśli każde wejście na kartę produktu bez page cache trwa 800 ms, bo wtyczki odpytują zewnętrzne API, przepustowość spada o połowę. Rozwiązaniem rzadko są „kolejne wtyczki”, częściej mniej synchronicznych wywołań, lepszy page cache i więcej workers tylko tam, gdzie pomiar pokazuje potrzebę.
Praktyczne kroki:
- Zmierz czas oczekiwania w PHP-FPM (
slowlog, APM), zanim podwoisz workers. - Oddziel panel i cron od frontendu osobnymi pulami, jeśli platforma na to pozwala.
- Nie pozwól, żeby wp-cron uruchamiał się przy każdym żądaniu frontendu; użyj crona systemowego.
- Trzymaj sesje i pliki tymczasowe z dala od wolnego dysku lokalnego, gdy obciążenie dzieli kilka węzłów.
Dokumentacja serwerowa WordPress.org podkreśla, że hosting to więcej niż „PHP plus MySQL”: uprawnienia plików, HTTPS i izolacja procesów wpływają na bezpieczeństwo i stabilność.
Jak ustawić pm.max_children w PHP-FPM
Na własnym serwerze albo w chmurze liczba workers to ustawienie, które należy do ciebie. Podręcznik PHP dla FPM opisuje trzy tryby pm: static daje stałą liczbę procesów potomnych, dynamic dostosowuje ją między pm.start_servers, pm.min_spare_servers i pm.max_spare_servers, a ondemand uruchamia procesy dopiero, gdy przychodzą żądania. Wspólny dla wszystkich jest pm.max_children, który według podręcznika „ustala limit liczby jednocześnie obsługiwanych żądań” (tłumaczenie własne).
W praktyce pułap wyznacza pamięć: każdy proces PHP zajmuje RAM, a jeśli pm.max_children razy typowy rozmiar procesu przekracza wolną pamięć serwera, zamieniasz kolejkę na swapowanie. Żeby zobaczyć, gdzie ucieka czas, ustaw request_slowlog_timeout na kilka sekund. FPM zapisze wtedy backtrace PHP do pliku slowlog dla każdego dłuższego żądania i zobaczysz, która wtyczka albo które zewnętrzne wywołanie trzyma workera.
Kiedy używać Redisa lub Memcached w WordPressie
Object cache przechowuje wyniki wywołań wp_cache_* i trwałe obiekty między żądaniami. Bez trwałego backendu cache żyje w pamięci tylko przez jedno żądanie. Dokumentacja WP_Object_Cache mówi wprost: „Domyślnie object cache nie jest trwały” (tłumaczenie własne), a dane nie przetrwają między odsłonami, dopóki nie zainstalujesz trwałego backendu jako drop-in w wp-content. Z Redisem albo Memcached opcje, gorące punkty postmeta i transienty są współdzielone między workers.
Kiedy object cache pomaga najbardziej:
- WooCommerce z wieloma produktami i wariantami
- Strony z ciężkimi zapytaniami
WP_Query, które nie trafiają do page cache - Multisite albo wiele aktywnych wtyczek, które wielokrotnie czytają opcje
Kiedy pomaga niewiele:
- Czysto statyczne landingi, już w całości cachowane na CDN
- Źle skonfigurowane wtyczki, które omijają object cache albo zapisują ogromne obiekty
- Baza danych, która już jest wąskim gardłem przy intensywnych zapisach w zamówieniu
Ustawiaj TTL świadomie. Czyść agresywne klucze przy wdrożeniu. Monitoruj współczynnik trafień: „Redis jest włączony” bez procentu trafień to teatr. Trzymaj Redisa w tym samym regionie co PHP; skok object cache na inny kontynent kosztuje więcej, niż oszczędza.
Co Cloudflare domyślnie cachuje przed WordPressem
Wiele osób zakłada, że CDN przed WordPressem automatycznie cachuje całe strony. Własna dokumentacja Cloudflare o domyślnym cachowaniu mówi co innego: „CDN Cloudflare domyślnie nie cachuje HTML ani JSON” (tłumaczenie własne). Bez własnych reguł pliki są cachowane według rozszerzenia, na przykład obrazy, CSS, JS, fonty i PDF, a HTML generowany przez PHP za każdym razem idzie do originu.
Ta sama strona wymienia, co blokuje cachowanie nawet po jego włączeniu: nagłówek Set-Cookie z originu, Cache-Control: private, no-store, no-cache albo max-age=0 oraz każda metoda żądania inna niż GET. Do cachowania HTML Cloudflare zaleca Cache Rule, która cachuje wszystko, albo Workers dla własnej logiki.
Dla WordPressa oznacza to, że wtyczka ustawiająca ciasteczko na każdej stronie po cichu odbiera cache edge sens. Sprawdź nagłówki odpowiedzi anonimowej karty produktu, zanim uznasz, że „CDN nie pomaga”.
Które strony WooCommerce można cachować na edge
WooCommerce łączy cachowalne strony katalogu z bardzo dynamicznymi ścieżkami: koszyk, zamówienie, Moje konto, endpointy REST bramek płatności, webhooki z Przelewy24, PayU czy Stripe. Cache edge, który serwuje anonimowy HTML dla /produkt/, jest dobry. Cache edge, który serwuje ten sam HTML użytkownikowi z towarami w koszyku, niszczy konwersję.
Reguły edge, które sprawdzają się w praktyce:
- Cachuj GET dla katalogu, wpisów i cachowalnych landingów
- Omijaj cache przy ciasteczkach takich jak
woocommerce_items_in_cart,wp_woocommerce_session_*i ciasteczkach logowania - Nigdy nie cachuj POST, żądań koszyka przez admin-ajax ani callbacków płatności
- Trzymaj origin blisko integracji płatności i ERP; edge nie „przeniesie” magicznie logiki PCI ani sesji
Własny poradnik WooCommerce o konfiguracji wtyczek cache potwierdza tę granicę: koszyk, Moje konto i zamówienie muszą zostać poza cache, bo pokazują informacje konkretnego klienta. Lista ciasteczek w poradniku to woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed i store_notice[notice id]. Jeśli warstwa cache oferuje cachowanie bazy danych, poradnik sugeruje też wyłączenie _wc_session_. Traktuj tę listę jako punkt wyjścia reguły omijania na edge, zamiast zgadywać.
Typowy scenariusz: kampania Black Friday z dużym ruchem na katalogu. CDN i cache edge przejmują landingi i karty produktów. Zamówienie zostaje na originie w regionie UE z wystarczającą liczbą PHP workers i Redisem. Jeśli spróbujesz „całego sklepu na Workers”, nadal brakuje ci autorytatywnej bazy dla stanów magazynowych, zamówień i VAT.
Mierz TTFB zarówno dla trafień, jak i chybień cache. Poradnik web.dev o TTFB oddziela odpowiedź serwera od opóźnienia sieci; edge zwykle poprawia to drugie dla treści statycznych, a w niecachowanym zamówieniu nadal dominują ślady PHP i bazy.
RODO i lokalizacja danych przy wyborze hostingu WordPress
Wybór hostingu to także wybór podmiotu przetwarzającego: gdzie leżą snapshoty MySQL, logi, kopie zapasowe, dostęp supportu i podprocesorzy?
Lista kontrolna przed podpisaniem umowy:
- Główny region bazy i plików (na przykład UE/EOG). „Globalny anycast” CDN to nie to samo co lokalizacja danych osobowych.
- Umowa powierzenia przetwarzania z jasną listą podprocesorów.
- Podstawa transferu, jeśli dane opuszczają EOG (standardowe klauzule umowne, środki uzupełniające). „Używamy amerykańskiego CDN” bez dokumentacji to ryzyko, a nie funkcja.
- Logi i APM: czy zawierają e-maile, adresy IP, numery zamówień i jak długo są przechowywane?
- Dostęp supportu: kto może wejść przez SSH lub SFTP i czy jest to logowane?
Dla dostawców z USA istnieje jeszcze jedna podstawa transferu: 10 lipca 2023 roku Komisja Europejska przyjęła decyzję stwierdzającą odpowiedni stopień ochrony dla EU-US Data Privacy Framework. Według strony Komisji o transferach danych do USA obejmuje ona tylko firmy uczestniczące w tych ramach. Sprawdź więc, czy właśnie twój dostawca hostingu albo CDN jest na liście uczestników, zamiast zakładać, że „USA są objęte”.
Obliczenia edge na danych osobowych (testy A/B, personalizacja) trzeba traktować jak przetwarzanie. Klucze cache z identyfikatorem użytkownika w setkach punktów obecności zwiększają powierzchnię ataku. Trzymaj treści osobiste na originie albo w krótkotrwałych, ściśle kluczowanych warstwach.
Jak zastąpić wp-cron cronem systemowym
WP-Cron nie działa według zegara. Jest sprawdzany, gdy ktoś ładuje stronę, więc zaplanowane zadania opóźniają się na cichych witrynach i konkurują z odwiedzającymi na ruchliwych. Dokumentacja deweloperska WordPressa pokazuje rozwiązanie w dwóch krokach. Najpierw wyłącz wyzwalanie ruchem w wp-config.php:
define( 'DISABLE_WP_CRON', true );Potem systemowy harmonogram wywołuje wp-cron.php żądaniem HTTP. Dokumentacja podaje */15 * * * * jako przykład uruchamiania co 15 minut i pokazuje wywołanie wget na wp-cron.php. Interwał dobierz do faktycznych zadań: sklep z odnawianiem subskrypcji potrzebuje krótszego niż blog z zaplanowanymi wpisami. Na hostingu managed zapytaj, jak dostawca uruchamia crona, zanim cokolwiek zmienisz, bo niektórzy robią to już za ciebie.
Jak skonfigurować CI/CD dla hostingu WordPress
Bez CI/CD staging zamienia się w „ręczne FTP w czwartek w nocy”. W 2026 roku kod, motywy, własne wtyczki i definicje infrastruktury powinny przechodzić przez pipeline.
Minimum, które działa:
- Git jako źródło prawdy dla własnego kodu (motyw, mu-plugins, infrastruktura jako kod).
- Build i testy w CI: PHPStan lub Psalm, gdzie są dostępne, PHPUnit dla własnych wtyczek, linting motywu.
- Wdrożenie na staging z tą samą wersją PHP i rozszerzeniami co produkcja.
- Testy dymne: strona główna, karta produktu, dodanie do koszyka, logowanie.
- Produkcja z atomowym releasem (nowy katalog release plus symlink) albo obraz kontenera z healthcheckiem.
- Migracje bazy przez WP-CLI albo kontrolowane skrypty migracyjne, nigdy „edycja na produkcji”.
Sekrety (klucze API, hasła do bazy) należą do vaulta albo magazynu sekretów platformy, a nie do Gita. Czyszczenie object cache i CDN powinno uruchamiać się po wdrożeniu, a nie zależeć od tego, czy „pamiętamy o wyczyszczeniu Redisa”.
Na hostingu managed: korzystaj z ich deployu z Gita albo hooków rsync, ale zachowaj tę samą bramkę testów. W chmurze: Terraform albo Ansible plus wypiekane obrazy ograniczają serwery-płatki śniegu. Na edge: wdrażaj konfigurację Workers i CDN z tego samego repozytorium co kod WordPressa, z przeglądem reguł cache, które mogą zepsuć zamówienie.
Jak wybrać architekturę hostingu WordPress w praktyce
Zacznij od obciążenia, nie od haseł marketingowych.
- Dużo treści, ruch czytelników rozproszony geograficznie: origin managed albo w chmurze plus agresywny cache edge.
- WooCommerce z lokalnymi płatnościami i ERP: origin w regionie UE, Redis, wystarczająco PHP workers, edge tylko dla katalogu.
- Ostre wymogi zgodności: chmura albo managed z udokumentowanym przechowywaniem w UE/EOG i krótką listą podprocesorów.
- Mały zespół, przewidywalny ruch: najpierw managed; przejdź do chmury, gdy limit workers i I/O bazy staną się zmierzonym ograniczeniem.
Hybryda to norma: managed albo chmura dla WordPressa, Redis w tym samym regionie, CDN i Workers z przodu. Czysty „serverless WordPress wszędzie” to nadal przypadek szczególny, a nie standard dla prawdziwych sklepów.
Jakie wskaźniki wydajności zmierzyć przed zmianą hostingu WordPress
Zmiana hostingu bez punktu odniesienia to zgadywanie. Zapisuj przez co najmniej tydzień:
- TTFB i LCP na kluczowych szablonach (strona główna, kategoria, produkt, kroki zamówienia)
- Kolejkę PHP-FPM i wolne żądania
- Slow query log MySQL
- Współczynnik trafień cache (page i object)
- Odsetek błędów webhooków płatności
web.dev radzi zrozumieć, co TTFB naprawdę mierzy, zanim zaczniesz gonić magiczną liczbę. TTFB to tam suma przekierowań, zapytania DNS, nawiązania połączenia i TLS oraz czasu do nadejścia pierwszego bajtu. Jako zgrubną wskazówkę web.dev uznaje 0,8 sekundy lub mniej za dobry wynik, a ponad 1,8 sekundy za słaby. Międzynarodowa strona marketingowa może mieć niski TTFB przy trafieniu cache i wciąż wolne zamówienie. Optymalizuj warstwę, która faktycznie jest wąskim gardłem.
Częste błędy hostingowe na stronach WordPress
- Cache edge bez omijania dla ciasteczek sesji WooCommerce
- Za mało PHP workers, nadrabiane kilkoma wtyczkami cache walczącymi o ten sam HTML
- Redis w innym regionie niż PHP
- Kopie zapasowe tylko na tym samym dysku co produkcja
- Brak stagingu odwzorowującego wersję PHP i rozszerzenia
- Dane osobowe w logach CDN bez polityki retencji
- Wdrożenia bez czyszczenia page cache, przez co stare fragmenty HTML żyją godzinami
Każdy z tych błędów taniej naprawić pomiarem i konfiguracją niż hasłem „znowu zmieniamy dostawcę”.
Pomoc w wyborze hostingu WordPress
Mapuję istniejący stos, mierzę workers i cache, i proponuję managed, chmurę albo hybrydę bez przesadnego zachwalania edge tam, gdzie zamówienie musi pozostać spójne. Praca zwykle obejmuje wybór architektury, strojenie Redisa i page cache, reguły CDN dla WooCommerce oraz CI/CD do stagingu i produkcji.
Jeśli potrzebujesz konkretnego przeglądu infrastruktury, napisz przez stronę kontaktową.
Jak wybrać między managed, chmurą i edge w 2026 roku
Managed daje pomoc w utrzymaniu i sufit. Chmura daje kontrolę i odpowiedzialność. Edge daje niskie opóźnienia dla treści cachowalnych, a nie zamiennik PHP i MySQL na dynamicznych ścieżkach WooCommerce. PHP workers i object cache decydują o przepustowości originu. RODO i lokalizacja danych decydują o regionie i podprocesorach. CI/CD utrzymuje zmiany powtarzalne.
Wybierz architekturę według zmierzonego obciążenia i wymogów zgodności, potem dostrój cache i workers. To trwa dłużej niż pogoń za najnowszą etykietą hostingową.
