TL;DR
WordPress przy każdym wejściu uruchamia PHP i wykonuje 20–80 zapytań SQL - przy 200 osobach naraz serwer się dusi, bo musi obsłużyć 200 niezależnych żądań w czasie rzeczywistym.
Astro nie ma backendu produkcyjnego - strona to statyczne pliki HTML na CDN, więc 200 czy 20 000 jednoczesnych użytkowników nie robi różnicy w wydajności.
Wtyczki cache w WordPressie nie pomagają w kampaniach z parametrami UTM, sklepach z koszykiem ani po świeżej publikacji treści - każda taka sytuacja omija cache i obciąża PHP od zera.
Koszt obsługi 1 mln wizyt miesięcznie: WordPress 3 000-8 000 zł, Astro + CDN 20-80 zł - przepaść 50× wynika z innej architektury, nie z innego dostawcy.
Jedna padnięta kampania Google Ads o budżecie 5 000 zł to typowo 15 000-25 000 zł niezrealizowanych przychodów - często więcej niż roczny koszt utrzymania strony na Astro.
WordPress przy każdym wejściu uruchamia PHP i odpytuje bazę danych - przy 200 osobach naraz serwer się dusi, bo musi obsłużyć 200 osobnych żądań w czasie rzeczywistym; Astro serwuje gotowe pliki HTML z CDN, więc 200 czy 20 000 osób nie robi mu różnicy.
To brzmi banalnie, ale ma konkretne konsekwencje finansowe - szczególnie wtedy, gdy budujesz ruch płatnymi kampaniami albo strona dostaje nagłą falę odwiedzających po publikacji w mediach.
Co właściwie się dzieje, gdy strona "pada"
Z perspektywy użytkownika "strona padła" wygląda na jeden problem. Z perspektywy technicznej to kilka różnych awarii:
Timeout połączenia - przeglądarka czeka 30 sekund i pokazuje "ERR_CONNECTION_TIMED_OUT". Serwer nie odpowiada w ogóle, bo wszystkie procesy PHP są zajęte poprzednimi żądaniami.
Błąd 502 Bad Gateway - Nginx/Apache widzi, że PHP nie zwraca odpowiedzi w czasie, więc zwraca ten błąd. Typowe przy kampaniach reklamowych, gdy ruch nagle skacze.
Błąd 504 Gateway Timeout - wariant 502, gdy backend odpowiada, ale za wolno. Strona ładuje się 40 sekund, a użytkownik dawno zamknął kartę.
Bardzo wolne ładowanie - strona "działa", ale ładuje się 8-15 sekund zamiast normalnych 2. Konwersja spada o 60-80%, bo użytkownik z reklamy nie czeka tak długo.
Baza danych odmawia połączeń - komunikat "Error establishing a database connection". Klasyczny WordPress objaw, gdy MySQL przekracza limit `max_connections` na hostingu.
Wspólny mianownik wszystkich tych awarii: każda strona dla każdego użytkownika jest budowana na żądanie. Jeśli żądań przychodzi za dużo naraz, serwer się nie wyrabia.
Dlaczego WordPress sypie się pod ruchem
PHP i baza danych na każdy klik
Gdy ktoś wchodzi na stronę WordPress, dzieje się to:
Apache/Nginx odbiera żądanie HTTP
Uruchamia PHP-FPM, który ładuje WordPressa do pamięci
WordPress łączy się z MySQL i wykonuje 20–80 zapytań SQL (treść strony, menu, opcje, wtyczki)
PHP składa HTML z danych i zwraca przeglądarce
Cały proces zajmuje 200-800 ms na dobrym hostingu, 1–3 sekundy na słabym. Serwer ma ograniczoną liczbę procesów PHP, które może uruchomić jednocześnie - typowo 10-50 na shared hostingu, 100-300 na managed WordPress. Jeśli żądań przychodzi więcej naraz, kolejne czekają w kolejce. Po kilkudziesięciu sekundach czekania serwer zwraca błąd.
WordPress to restauracja, w której każde danie kucharz składa od zera po zamówieniu. Przy 30 gościach to działa. Przy 300 - kuchnia nie wyrabia.
Wtyczki potęgują obciążenie
Każda wtyczka dokłada zapytania SQL, własne procesy PHP i czasem zewnętrzne wywołania API (cookie consent ładuje się ze swojego serwera, analytics pyta o ID użytkownika, formularz kontaktowy waliduje reCAPTCHA). Strona z 15 wtyczkami przy każdym wejściu wykonuje 80-200 zapytań SQL. Przy 100 osobach jednocześnie to 8 000-20 000 zapytań do bazy danych w ciągu kilku sekund.
Większość shared hostingów ma `max_connections = 100-200`. Przekroczenie tego limitu = błąd 500 dla każdego kolejnego użytkownika.
Wtyczki cache pomagają, ale mają granice
WP Rocket, W3 Total Cache i podobne wtyczki generują statyczne pliki HTML dla najczęściej odwiedzanych stron. To poprawia sytuację - pierwszy użytkownik wywołuje PHP, kolejne dziesięć tysięcy dostaje już gotowy plik. W teorii.
W praktyce cache nie pomaga w kilku częstych scenariuszach:
użytkownicy zalogowani (sklep, panel klienta) - cache jest pomijany
strony z parametrami UTM (kampanie Google/Meta Ads dodają `?utm_source=...`) - każda kombinacja UTM = osobny cache miss
koszyk i checkout - z definicji dynamiczne
strony po przesłaniu formularza
nowa zawartość, której jeszcze nikt nie wywołał
Plus cache trzeba czyścić przy każdej zmianie treści, a po wyczyszczeniu pierwszych 200–500 użytkowników znów obciąża PHP zanim cache się odbuduje.
Dlaczego Astro się nie pada
Statyczne pliki = nie ma czego przeciążyć
Astro nie ma backendu produkcyjnego. Strona to folder plików HTML, CSS i JS wygenerowanych raz, podczas builda. Ten folder trafia na CDN - Cloudflare Pages, Vercel, Netlify, AWS CloudFront. Każde żądanie użytkownika obsługuje najbliższy geograficznie węzeł CDN, który po prostu wysyła plik z dysku.
Nie ma PHP, które musi się uruchomić. Nie ma bazy danych do odpytania. Nie ma puli procesów, która może się wyczerpać. Strona statyczna to bufet, gdzie jedzenie już czeka - czy przyjdzie 30 gości, czy 30 000, każdy dostaje to samo, od razu.
CDN skaluje się automatycznie
Cloudflare ma 320+ węzłów w 120+ krajach. Każdy z nich potrafi obsłużyć dziesiątki tysięcy żądań na sekundę. Gdy twoja strona dostaje 10 000 wejść w minutę z polskiej kampanii reklamowej, ruch rozkłada się między węzłami CDN - żaden z nich nawet nie zauważa wzrostu.
To samo dotyczy ruchu globalnego. Jeśli artykuł trafia na Hacker News i nagle masz 50 000 odwiedzin z USA w ciągu godziny, ruch obsługują węzły CDN w USA - twój serwer w Warszawie nie widzi żadnego dodatkowego obciążenia, bo go w ogóle nie ma.
Koszt nie rośnie liniowo z ruchem
WordPress przy dużym ruchu wymaga większego serwera: VPS za 30 zł → managed WP za 400–800 zł → dedykowany serwer za 1500–3000 zł. Każdy kolejny próg ruchu to skok cenowy.
Cloudflare Pages w darmowym planie daje 100 000 żądań dziennie. Vercel Hobby - 100 GB transferu miesięcznie. Plany płatne zaczynają się od 20 USD miesięcznie i obsługują miliony żądań. Strona statyczna obsługująca milion wizyt miesięcznie kosztuje 0–80 zł w hostingu - tyle samo, co przy 1 000 wizyt.
Konkretne scenariusze, w których to ma znaczenie
Pierwszy dzień kampanii Google Ads
Wydajesz 5 000 zł budżetu, CTR 5%, planowane 250 konwersji. Pierwszego dnia 70% ruchu wpada w 3 godziny szczytu wieczornego - 1 800 użytkowników jednocześnie. WordPress na shared hostingu zwraca błędy 502 dla około 30% z nich. Tracisz 540 użytkowników × średnia konwersja 2% = 11 leadów × średni LTV 2 000 zł = 22 000 zł niezrealizowanych przychodów w jednym dniu.
Astro na CDN obsłużyłoby te same 1 800 użytkowników nawet nie drgnąwszy.
Wzmianka w mediach lub u influencera
Twoja firma trafia do artykułu w Wyborczej, na Crazy Nauce albo do filmu z 200 tysiącami subskrybentów. W ciągu 2 godzin po publikacji wpada 5 000 odwiedzin. WordPress klasy "managed" obsługuje to z trudem (LCP rośnie do 6-8 s, konwersja spada o 70%). Shared hosting po prostu pada.
Astro: 5 000 odwiedzin to dla CDN szum w danych.
Black Friday i okresy sezonowe
E-commerce na WordPress/WooCommerce w Black Friday to klasyczny scenariusz katastrofy. Ruch rośnie 5-15× względem normalnego, MySQL zaczyna się dławić, koszyki nie ładują się, użytkownicy zamykają kartę. Realna strata: 30–60% normalnej sprzedaży, którą można było zrobić w tym okresie.
Strony produktowe statyczne (Astro + Shopify lub dedykowane API) obsługują ten ruch bez problemów. Tylko proces checkout musi być dynamiczny, a ten działa na innym, wyspecjalizowanym backendzie.
Wysyłka newslettera do bazy 50 tys. odbiorców
Newsletter trafia do 50 000 osób o 10:00. W pierwszych 15 minutach klika 5–8% odbiorców = 2 500-4 000 wejść w 15 minut, w tym 800-1 200 jednoczesnych połączeń w peakach. WordPress shared: timeout dla połowy. Managed: powolne ładowanie, część rezygnuje. CDN/Astro: brak problemu.
Porównanie kosztu i skali
Scenariusz | WordPress shared | WordPress managed | Astro + CDN |
|---|---|---|---|
1 000 odwiedzin/dzień | OK | OK | OK |
10 000 odwiedzin/dzień | Powolne | OK | OK |
50 000 odwiedzin/dzień | Padnie | Działa wolno | OK |
100 000 odwiedzin/dzień | Padnie | Wymaga skalowania | OK |
Skok ruchu 10× w godzinę | Padnie | 502/504 | OK |
Koszt miesięczny przy 1k wizyt | 30 zł | 200 zł | 0 zł |
Koszt miesięczny przy 100k wizyt | 30–200 zł | 800–2000 zł | 0–80 zł |
Koszt miesięczny przy 1M wizyt | Niemożliwe | 3000–8000 zł | 20–80 zł |
Co zrobić, jeśli twoja strona padała w ostatnich kampaniach
Krótka diagnoza, zanim podejmiesz decyzję o migracji:
Sprawdź logi serwera — czy w czasie kampanii pojawiały się błędy 502, 504 lub komunikaty `database connection error`. Twoja agencja hostingowa lub administrator powinni umieć to pokazać.
Sprawdź konwersję w Google Analytics dla godzin szczytowych kampanii vs godzin niskiego ruchu - jeśli konwersja w peakach spada o 30%+, masz problem z wydajnością pod obciążeniem.
Skorzystaj z narzędzia load testingowego — k6, Loader.io, Apache JMeter. Symulują 100, 500, 1000 użytkowników jednocześnie i pokazują, kiedy serwer się dławi.
Krótkoterminowe ratunki dla WordPressa:
migracja na managed WP hosting (Kinsta, WP Engine, Cloudways) - 400-800 zł miesięcznie
konfiguracja Cloudflare przed WordPressem (CDN warstwa cache) - częściowo pomaga
redukcja wtyczek do absolutnego minimum
agresywny cache (WP Rocket + object cache + page cache)
Długoterminowo, jeśli ruch będzie rósł i kampanie się powtarzają, migracja na architekturę statyczną eliminuje cały ten problem strukturalnie. Różnica nie jest kosmetyczna - to inny model obsługi ruchu.
Czy warto migrować właśnie dlatego
Migracja na Astro nie ma sensu dla każdej strony. Ale dla firm, które:
inwestują w płatne kampanie reklamowe (5 000+ zł miesięcznie),
mają sezonowe peaki ruchu (Black Friday, okresy promocyjne, święta),
bywają wymieniane w mediach lub przez influencerów,
wysyłają newsletter do bazy 10 000+ odbiorców,
— ROI z migracji liczy się w pojedynczych miesiącach. Jedna kampania, w której strona nie padła, zwykle pokrywa znaczną część kosztu wdrożenia.
Szczegóły dotyczące tego, jak wygląda taka migracja w praktyce i ile trwa, znajdziesz na stronie usług tworzenia stron internetowych.
Najczęściej zadawane pytania
WordPress przy każdym wejściu uruchamia PHP i odpytuje bazę MySQL, co zajmuje 200–800 ms na żądanie. Serwer ma ograniczoną liczbę jednoczesnych procesów PHP (10–50 na shared, 100–300 na managed) i połączeń do bazy. Po przekroczeniu tych limitów kolejne żądania czekają w kolejce, a po kilkudziesięciu sekundach serwer zwraca błąd 502 lub 504.
Częściowo. Cloudflare cache'uje strony statyczne, które już raz zostały odwiedzone, i może obsłużyć ich kopie bez dotykania serwera WordPress. Ale nie pomaga przy stronach z parametrami UTM (kampanie reklamowe), zalogowanych użytkownikach, koszyku, checkout ani świeżej treści. Te żądania nadal trafiają do serwera WordPress i jego obciążają.
Realnie 30–100 jednoczesnych użytkowników, czyli orientacyjnie 5 000–15 000 odwiedzin dziennie przy równomiernym rozkładzie. Problem zaczyna się przy peakach — 1 000 osób w ciągu 5 minut z kampanii Google Ads wystarczy, żeby shared hosting zaczął zwracać błędy, nawet jeśli dzienny wolumen jest niewielki.
Tak, na darmowym lub niskobudżetowym planie. Cloudflare Pages oferuje nielimitowany transfer, Vercel Hobby pozwala na 100 GB, plan Pro Vercela za 20 USD miesięcznie obsługuje wielokrotnie więcej. Statyczna strona na CDN nie ma żadnego ograniczenia wynikającego z "mocy serwera" — skalowanie jest wbudowane w architekturę CDN.
Managed WordPress klasy Kinsta lub WP Engine na poziomie obsługującym takie obciążenie to 800–2000 zł miesięcznie, plus 300–600 zł za opiekę techniczną (audyty, monitoring, aktualizacje). Razem 1100–2600 zł miesięcznie, czyli 13 000–31 000 zł rocznie. Astro + CDN dla tej samej skali ruchu to 0–960 zł rocznie.
Dla strony firmowej (15–40 podstron, blog, formularz kontaktowy) wdrożenie zajmuje typowo 4–8 tygodni, w zależności od ilości treści do przeniesienia i złożoności komponentów. W Codium projekty zaczynają się od 20 000 zł i obejmują projekt, budowę frontendu, integrację z Headless CMS (Storyblok), import treści z WordPressa i przekierowania URL.
