Google Cloud Platform jako hosting WordPress – dlaczego przenieśliśmy infrastrukturę na GCP
Przez lata kenny.pl działało na hostingu współdzielonym. Działało – ale nie imponowało. Niestabilny PageSpeed na mobile (wahania między 74 a 92), ponad 50 zdarzeń PHP pool exhaustion miesięcznie, cache hit rate na poziomie 11%. Przy każdym szczycie ruchu strona zwalniała – nie dlatego, że była źle zoptymalizowana, ale dlatego, że dzieliła zasoby z setkami innych stron na tym samym serwerze.
CEO & Project Manager
W pewnym momencie doszliśmy do ściany. Hosting współdzielony nie dawał nam tego, czego potrzebowaliśmy jako software house, którego strona powinna być wizytówką kompetencji technicznych. Przenieśliśmy infrastrukturę na Google Cloud Platform. Efekt: PageSpeed Desktop 100, Mobile 100 i zero problemów z wydajnością od dnia migracji.
Kiedy hosting współdzielony przestaje wystarczyć
Hosting współdzielony jest świetny na start. Niski koszt, zero konfiguracji, strona działa od pierwszego dnia. Problem pojawia się, gdy strona rośnie – więcej ruchu, więcej treści, więcej oczekiwań wobec wydajności.
Na hostingu współdzielonym Twoja strona dzieli procesor, pamięć RAM i zasoby serwera z dziesiątkami, a czasem setkami innych witryn. Gdy sąsiad na serwerze ma szczyt ruchu – Twoja strona zwalnia. Gdy serwer się zapcha – PHP pool exhaustion, czyli brak wolnych procesów do obsłużenia żądań. Użytkownik widzi białą stronę albo timeout.
Typowe sygnały, że hosting współdzielony to wąskie gardło:
- TTFB (czas odpowiedzi serwera) powyżej 500ms, zmienny w ciągu dnia
- Regularne PHP pool exhaustion – strona „zamraża się” przy większym ruchu
- Niski cache hit rate mimo skonfigurowanego cache’owania
- Brak możliwości aktualizacji PHP do najnowszej wersji (hosting jeszcze jej nie udostępnił)
- Brak dostępu do konfiguracji serwera – nie możesz zmienić limitów pamięci, cronjobów, parametrów bazy danych
- PageSpeed spada poniżej 80 na mobile mimo zoptymalizowanych obrazków, cache i minifikacji
To jak tuning silnika w aucie, które ma za małą skrzynię biegów – możesz optymalizować do woli, ale fundamentalne ograniczenie jest gdzie indziej.
Dlaczego GCP, a nie managed hosting
Pierwszą myślą przy migracji z hostingu współdzielonego jest zazwyczaj managed WordPress hosting – Kinsta, Cloudways. Zarządzany, wygodny, z supportem. Rozważaliśmy te opcje. Oto dlaczego wybraliśmy inaczej.
Managed hosting daje wygodę, ale ogranicza kontrolę. Nie możesz w pełni konfigurować serwera, jesteś zależny od decyzji dostawcy o wersji PHP, architekturze cache, a czasem nawet od jego decyzji o zmianie infrastruktury. Przykład z rynku: Kinsta przez lata działała na Google Cloud Platform, korzystając m.in. z Cloudflare Enterprise jako warstwy CDN i bezpieczeństwa. W 2026 roku przeprowadziła migrację na Oracle Cloud Infrastructure – co oznaczało utratę lokalizacji Warszawa dla klientów w Polsce. Decyzja dostawcy, na którą klient nie ma wpływu.
GCP Compute Engine daje to, co managed hosting obiecuje, ale z pełną kontrolą:
- Lokalizacja europe-central2 (Warszawa) – najniższa latencja dla polskich użytkowników. Serwer fizycznie w Polsce, nie w Niemczech czy Holandii
- Gwarantowane zasoby – dedykowany CPU i RAM, zero „sąsiadów” na serwerze
- Pełna kontrola nad konfiguracją – Ty decydujesz o stacku, wersjach, parametrach
- Sustained Use Discounts – im dłużej serwer działa, tym mniej płacisz (automatycznie, bez zobowiązań)
- Infrastruktura sieciowa Google – premium tier networking, ta sama sieć co Google Search i YouTube
Pełna kontrola nad stackiem – co to realnie oznacza
Na hostingu współdzielonym jesteś pasażerem. Na GCP jesteś kierowcą. W praktyce oznacza to:
Zawsze najnowsza wersja PHP w dniu premiery. Nie czekasz tygodniami, aż hosting ją udostępni. Nowa wersja PHP wchodzi – aktualizujesz tego samego dnia. Każda nowa wersja PHP przynosi wymierne przyspieszenie i poprawki bezpieczeństwa.
Konfiguracja szyta na miarę. Limity pamięci, parametry bazy danych, konfiguracja cache, ustawienia serwera www – wszystko dostosowane pod konkretny projekt, nie pod „średnią” z tysięcy stron na serwerze.
Monitoring i reagowanie we własnym zakresie. Wiemy dokładnie, co dzieje się na serwerze – zużycie CPU, pamięci, ruch, logi błędów. Reagujemy zanim użytkownik zauważy problem, nie po zgłoszeniu do supportu hostingu.
Testowanie nowych technologii bez ograniczeń. Chcemy przetestować nowe rozwiązanie cache, nowy moduł serwera, nową konfigurację bazy danych – po prostu to robimy. Żadnych ticketów, żadnych ograniczeń panelu hostingowego.
Ta kontrola wymaga wiedzy technicznej – i to jest jedyny minus. Ale dla software house’u, który tę wiedzę ma, GCP daje możliwości, których żaden managed hosting nie zapewni.
Wyniki – PageSpeed przed i po
Konkretne liczby z kenny.pl – przed i po migracji:
| Metryka | Hosting współdzielony | GCP + Cloudflare |
|---|---|---|
| PageSpeed Desktop | ~99 | 100 |
| PageSpeed Mobile | 74-92 (niestabilny) | 100 |
| PHP pool exhaustion | 50+ zdarzeń/miesiąc | 0 |
| HTML cache hit rate | ~11% | ~100% |
| CSS render-blocking | ~420ms | ~120ms |
| TTFB | Zmienny (300-800ms) | Stabilny, poniżej 50ms |
To nie jest różnica kosmetyczna. To różnica między stroną, która „raczej działa” a stroną, która działa rewelacyjnie – stabilnie, powtarzalnie, niezależnie od pory dnia i natężenia ruchu. A szybkość strony to nie tylko komfort użytkownika – to bezpośredni wpływ na widoczność w Google i AI Overviews.
Cloudflare jako warstwa enterprise
GCP to fundament – ale połowa sukcesu leży w warstwie, która stoi przed serwerem. W naszym przypadku to Cloudflare.
Cloudflare to nie tylko „darmowy CDN”. Na wyższych planach (Business, Enterprise) oferuje funkcje, które fundamentalnie zmieniają wydajność i bezpieczeństwo strony:
Cache HTML na edge. Zamiast odpytywać serwer origin przy każdym wejściu, Cloudflare serwuje kopię strony z najbliższego serwera edge. To właśnie dlatego cache hit rate skoczył z 11% do niemal 100% – serwer GCP odpowiada tylko wtedy, gdy cache wygaśnie.
WAF i rate limiting. Firewall aplikacyjny blokuje ataki, zanim dotrą do serwera. Rate limiting na wp-login.php eliminuje ataki brute force. Serwer nie marnuje zasobów na obsługę złośliwego ruchu.
Full Strict SSL. Szyfrowanie end-to-end między użytkownikiem a Cloudflare i między Cloudflare a serwerem origin. Zero kompromisów.
Argo Smart Routing i Tiered Caching. Inteligentne routowanie ruchu przez najmniej zatłoczone ścieżki w sieci Cloudflare, plus wielopoziomowe cache’owanie, które minimalizuje liczbę żądań do origin.
Warto wiedzieć, że Kinsta przez lata budowała swoją przewagę wydajnościową właśnie na Cloudflare Enterprise – oferując klientom early hints, automatyczną optymalizację obrazków i zaawansowane cache’owanie. To pokazuje, że Cloudflare na poziomie enterprise to standard w profesjonalnym hostingu WordPress. Różnica polega na tym, kto ma kontrolę nad konfiguracją – dostawca hostingu czy Ty.
GCP, AWS czy Azure – kiedy co wybrać
Google Cloud Platform to nie jedyna chmura na rynku. Amazon Web Services (AWS) i Microsoft Azure to równie poważni gracze. Krótki przegląd:
AWS (Amazon Web Services) – największy dostawca chmury na świecie. EC2 (odpowiednik GCP Compute Engine) i Lightsail (uproszczony VPS) to solidne opcje. Silny w ekosystemie Amazona – Lambda (serverless), S3 (storage), CloudFront (CDN). Lokalizacja dostępna od 2022 roku w Warszawie jako rozszerzenie regionu Frankfurt (eu-central-1) z ograniczoną liczbą usług.
Microsoft Azure – naturalny wybór dla firm pracujących w ekosystemie Microsoftu (.NET, SQL Server, Active Directory). Silny w środowiskach korporacyjnych. Lokalizacja: Poland Central (Warszawa) dostępna od 2023 roku.
Google Cloud Platform – infrastruktura Google, premium networking, Warszawa (europe-central2). Najprostszy model cenowy z automatycznymi Sustained Use Discounts. Silny w kontenerach (GKE), machine learning i integracji z usługami Google.
Dla WordPressa w Polsce nasz wybór padł na GCP z dwóch powodów: lokalizacja Warszawa z premium tier networking i najkorzystniejszy stosunek wydajności do ceny przy długotrwale działających instancjach (SUD). Ale gdybyśmy budowali aplikację .NET dla korporacji – wybralibyśmy Azure. A gdybyśmy potrzebowali serverless z ekosystemem Lambda/S3 – AWS.
Wybór chmury zależy od potrzeb projektu, nie od mody. Kluczowe pytania: gdzie musi stać serwer, jaki stack technologiczny używasz, jaki masz budżet i czy masz zespół do zarządzania infrastrukturą.
Dla kogo GCP ma sens, a dla kogo nie
GCP nie jest dla każdego – i nie udajemy, że jest.
Ma sens gdy:
- Strona przerasta hosting współdzielony (PHP pool, niestabilność, wolny TTFB)
- Zależy Ci na lokalizacji serwera w Polsce
- Potrzebujesz pełnej kontroli nad konfiguracją
- Masz zespół techniczny lub agencję, która zarządzi serwerem
- Prowadzisz stronę lub sklep, gdzie szybkość bezpośrednio wpływa na przychód
- Chcesz świadomie dobrać technologię do skali projektu
Nie ma sensu gdy:
- Masz prostą stronę wizytówkę z minimalnym ruchem – hosting współdzielony za 50 zł rocznie wystarczy
- Nie masz dostępu do osoby technicznej – GCP wymaga konfiguracji i bieżącego utrzymania
- Budżet nie pozwala na dedykowany serwer (~80-200 zł/miesiąc vs ~15-50 zł za shared)
Ile to kosztuje
Przejrzyste porównanie miesięcznych kosztów:
| Opcja | Koszt miesięczny | Co dostajesz |
|---|---|---|
| Hosting współdzielony | 15-50 zł | Współdzielone zasoby, brak kontroli, support |
| Managed WordPress (Kinsta) | 100-300 zł | Zarządzany, wygodny, ale ograniczona kontrola |
| GCP Compute Engine | 80-200 zł | Dedykowane zasoby, pełna kontrola, Warszawa |
GCP z Sustained Use Discounts automatycznie obniża cenę im dłużej instancja działa – bez zobowiązań, bez kontraktów. Przy ciągle działającym serwerze (a taki jest serwer strony www) rabat sięga 30%. Do tego Cloudflare w darmowym planie zapewnia CDN i podstawowe bezpieczeństwo – za dodatkowe zero złotych.
Najczęściej zadawane pytania
Google Cloud Platform (GCP) to platforma chmurowa Google oferująca serwery, storage, bazy danych, sieci i dziesiątki innych usług. Compute Engine – odpowiednik wirtualnego serwera – pozwala uruchomić własną maszynę z dowolnym systemem operacyjnym i konfiguracją, w tym WordPress.
Tak. GCP Compute Engine to w pełni konfigurowalny serwer, na którym można zainstalować WordPress z dowolnym stackiem. Daje pełną kontrolę nad wydajnością, bezpieczeństwem i konfiguracją – czego hosting współdzielony nie oferuje.
Orientacyjnie 80-200 zł miesięcznie za instancję Compute Engine odpowiednią dla typowej strony firmowej lub sklepu. Sustained Use Discounts automatycznie obniżają cenę o do 30% przy ciągłym działaniu. Cloudflare (CDN, SSL, cache) można dodać bezpłatnie.
Tak – GCP wymaga konfiguracji serwera, instalacji i utrzymania systemu operacyjnego, web servera, PHP i bazy danych. To nie jest panel hostingowy z jednym kliknięciem. Dlatego GCP sprawdza się najlepiej dla firm, które mają własny zespół techniczny lub współpracują z agencją.
Na hostingu współdzielonym dzielisz zasoby z innymi stronami i nie masz kontroli nad konfiguracją serwera. Na GCP masz dedykowane, gwarantowane zasoby (CPU, RAM) i pełną kontrolę nad każdym aspektem infrastruktury. Różnica jest jak między wynajmem biurka w coworkingu a własnym biurem.
Jeśli hosting współdzielony ogranicza wydajność Twojej strony i tracisz klientów przez wolne ładowanie – tak. Jeśli masz prostą stronę wizytówkę z minimalnym ruchem – hosting współdzielony prawdopodobnie wystarczy. Kluczowe pytanie brzmi: czy obecny hosting jest wąskim gardłem Twojego biznesu?
Podsumowanie
Hosting współdzielony to jak wynajem biurka w coworkingu – wygodnie na start, ale w pewnym momencie potrzebujesz własnego biura. GCP to to biuro – Twoje, pod Twoją kontrolą, z adresem w Warszawie.
Migracja kenny.pl na Google Cloud Platform dała nam PageSpeed 100 na desktop i 100 na mobile, zero PHP pool exhaustion, stabilny TTFB poniżej 50ms i pełną kontrolę nad infrastrukturą. Te same wyniki możemy osiągnąć dla każdej strony WordPress – bo to nie kwestia magii, tylko odpowiednio skonfigurowanego serwera.
Jeśli Twoja strona przerasta hosting współdzielony i chcesz przenieść się na GCP lub inną chmurę – skonfigurujemy infrastrukturę, zoptymalizujemy wydajność i zajmiemy się utrzymaniem. Napisz do nas.