PHP memory limit w WordPress – jak zwiększyć i jakie wartości ustawić (2026)

PHP memory limit to twardy sufit pamięci RAM, jaką pojedynczy proces PHP może zużyć podczas wykonywania skryptu. Wartość ustawiana jest w `php.ini` dyrektywą `memory_limit` i dotyczy każdego żądania osobno – jeśli limit to 256M, a stronę ładuje równocześnie 20 osób, teoretycznie potrzeba 20 × 256M = 5120M RAM na serwerze.

WordPress sam w sobie jest dość oszczędny – czysty rdzeń z domyślnym motywem zjada około 30-50 MB na żądanie. Problem zaczyna się, gdy dodasz 25 wtyczek, Elementora, WooCommerce i wtyczkę security z real-time scanning. Wtedy ten sam request potrafi zjeść 200-400 MB.

WordPress ma też własne, wewnętrzne stałe: `WP_MEMORY_LIMIT` (dla frontendu) oraz `WP_MAX_MEMORY_LIMIT` (dla panelu admina i crona). Jeśli PHP pozwala na 512M, a w `wp-config.php` masz `WP_MEMORY_LIMIT` ustawione na 64M, to WordPress sam się zdławi – niezależnie od hojności serwera.

Komunikat `Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)` oznacza, że skrypt PHP próbował zaalokować więcej RAM niż pozwala `memory_limit`. PHP przerywa wykonanie, a przeglądarka pokazuje albo surowy błąd, albo biały ekran śmierci.

Dane w bazie są bezpieczne. Błąd zatrzymuje TYLKO aktualne żądanie – nie uszkadza bazy danych, nie kasuje plików, nie niszczy zamówień w WooCommerce. Jeśli błąd pojawił się podczas zapisywania posta, najwyżej stracisz ostatnie niezapisane zmiany.

Co dokładnie się wydarzyło? W 9 na 10 przypadków odpowiedź brzmi: jakaś wtyczka próbuje jednorazowo załadować zbyt wiele danych do pamięci (np. import 10 tys. produktów w WooCommerce, backup całej bazy, optymalizacja obrazków w tle). Więcej o powiązanych awariach znajdziesz w naszym poradniku biały ekran śmierci WordPress – diagnoza i naprawa.

Zanim zaczniesz kombinować z kodem, sprawdź co masz aktualnie ustawione. Są trzy niezawodne sposoby.

Sposób 1: Site Health (wbudowany) Przejdź do `Narzędzia → Stan witryny → Informacje → Serwer`. Znajdziesz tam pola: - `PHP memory limit` – limit dla frontendu - `PHP max input vars` - `Wersja PHP`

Sposób 2: Plik info.php (najszybszy) Stwórz plik `info.php` w katalogu głównym WordPressa z zawartością ``. Otwórz go w przeglądarce – w sekcji `memory_limit` zobaczysz zarówno Local Value (co ustawia WordPress), jak i Master Value (co pozwala hosting). Po sprawdzeniu usuń plik – ujawnia on zbyt wiele informacji o serwerze.

Sposób 3: Query Monitor (dla diagnozy) Wtyczka Query Monitor pokazuje w pasku admina `Peak memory usage` dla każdego requestu. To jedyny sposób, żeby zobaczyć, ile RAM faktycznie zużywa konkretna podstrona. Filtruj po kolumnie Component, żeby wytropić winną wtyczkę.

Metody różnią się zasięgiem i wymogami hostingowymi. Próbuj od góry – pierwsza działa w 80% przypadków.

Metoda 1: wp-config.php (zalecana) Połącz się przez FTP albo File Manager w panelu hostingu. Otwórz `wp-config.php` w katalogu głównym WordPressa. Przed linią `/* That's all, stop editing! Happy publishing. */` dodaj:

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Pierwsza dyrektywa ustawia limit dla frontendu, druga dla wp-admin. Zapisz plik i odśwież stronę.

Metoda 2: .htaccess (tylko Apache) Jeśli hosting używa Apache (większość shared hostingów w Polsce), dodaj na początku `.htaccess`:

php_value memory_limit 512M

Na LiteSpeed i Nginx ta metoda NIE zadziała – serwer ją zignoruje lub zwróci błąd 500.

Metoda 3: php.ini / .user.ini W katalogu głównym WordPressa stwórz (lub edytuj) plik `.user.ini`:

memory_limit = 512M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

Zmiany wchodzą w życie po 5 minutach (PHP cache'uje `.user.ini`).

Metoda 4: Panel hostingowy W większości polskich hostingów znajdziesz sekcję typu `Ustawienia PHP` albo `PHP Selector`. W CyberFolks jest to `PHP` → `Ustawienia PHP` → suwak `memory_limit`. W cPanel: `MultiPHP INI Editor`. Ta metoda jest najbezpieczniejsza – nie ruszasz plików WordPressa.

Nie ma jednej magicznej liczby. Oto co sprawdza się u naszych klientów w 2026 roku:

Uwaga: ustawienie 2G na shared hostingu to zazwyczaj iluzja. Serwer i tak ma twardy limit (np. 30 sekund execution time i 1GB RAM dla całego konta), więc zawyżony `memory_limit` tylko maskuje problem do następnego crashu. Więcej w naszym poradniku o optymalizacji WooCommerce.

Te dwie stałe mylą nawet doświadczonych devów, a różnica jest istotna.

• `WP_MEMORY_LIMIT` – obowiązuje na frontendzie (strony, posty, wyniki wyszukiwania). Domyślnie 40M dla WordPressa i 64M dla WordPress Multisite.
• `WP_MAX_MEMORY_LIMIT` – obowiązuje w `/wp-admin/` oraz podczas zadań cron. Domyślnie 256M.
• `memory_limit` (PHP ini) – master cap. Jeśli PHP pozwala na 128M, a `WP_MAX_MEMORY_LIMIT` ma 512M, to i tak dostaniesz 128M. WordPress nie może przekroczyć PHP.

Praktyczny wniosek: jeśli błąd wyskakuje TYLKO w adminie (np. podczas aktualizacji wtyczek, importu produktów), zwiększ `WP_MAX_MEMORY_LIMIT`. Jeśli błąd jest na frontendzie – rusz `WP_MEMORY_LIMIT`. W obu przypadkach upewnij się, że PHP `memory_limit` jest ≥ ustawionej wartości w WordPressie.

Na podstawie pomiarów Query Monitor z 50+ sklepów, którymi się opiekujemy:

1. Elementor Pro – 40-80 MB na page load (Flexbox container trochę pomaga, ale wciąż ciężki)
2. WooCommerce – 60-120 MB dla sklepów 1000+ produktów, szczególnie koszyk i checkout
3. WPML – 30-50 MB (string translation jest kosztowny)
4. Jetpack Full – 40-70 MB, zwłaszcza z włączonymi Related Posts i statystykami
5. Wordfence – 30-60 MB, real-time firewall trzyma dużo w pamięci
6. LearnDash / TutorLMS – 50-100 MB przy wyświetlaniu kursów z progress trackingiem
7. UpdraftPlus / BackupBuddy – podczas backupu +200 MB do +500 MB (jednorazowo)
8. Yoast SEO Premium – 15-25 MB, redirect manager i cornerstone content analysis
9. Popup Maker / OptinMonster – 20-30 MB na każdym page view
10. iThemes Security / Sucuri – 30-60 MB przy aktywnym skanowaniu

Złota zasada: jeśli Twoja strona używa 5 wtyczek z tej listy jednocześnie, nawet 512M może nie wystarczyć. Czasem lepiej zamienić płatną wtyczkę na Redis Object Cache i zredukować zapytania do bazy, niż podbijać RAM.

Zanim klikniesz zwiększ do 1G, odpowiedz sobie na trzy pytania.

Krok 1: Jaki masz obecny limit?
- Poniżej 128M → podnieś do 256M i idź dalej. To poziom absurdalnie niski, hosting powinien dawać więcej.
- 128-256M i błąd przy podstawowych operacjach (pisanie posta, dashboard) → ZWIĘKSZ do 512M.
- 256M i błąd tylko przy specyficznych akcjach (import, backup, kupowanie w WC) → DIAGNOZUJ, nie podnoś.

Krok 2: Czy znasz źródło problemu?
Zainstaluj Query Monitor. Otwórz podstronę, która pada. Sprawdź Peak Memory + kolumnę Component w zakładce Queries. Jeśli jedna wtyczka zjada >40% RAM – to ona jest winna, nie hosting.

Krok 3: Czy zwiększenie pomogło na długo?
- Jeśli po podniesieniu limit znów się zapełnia w ciągu 2-3 tygodni – masz memory leak albo za dużo wtyczek. Limit to objaw, nie przyczyna.
- Jeśli limit 512M+ nie wystarcza regularnie – czas pomyśleć o migracji na VPS albo managed WordPress hosting. Zobacz nasz poradnik WordPress wolno się ładuje – diagnoza i naprawa.

Największy sekret branży: domyślne limity memory bardzo się różnią. Oto co znajdziesz bez grzebania w ustawieniach (stan na 2026):

Jeśli siedzisz na hostingu z 64-128M i nie możesz podnieść – nie walcz, migruj. Sam najczęściej polecam CyberFolks – pakiet Turbo startuje od 15 zł/mies i ma 512M z automatu, więc `Allowed memory size exhausted` po prostu nie pojawia się przy normalnym użytkowaniu. Mam tam prywatnie ponad 20 stron, w tym kilka sklepów WooCommerce, i ten błąd widziałem tylko raz – przy imporcie 30 tys. produktów jednym plikiem CSV (co i tak wymagałoby 1G+ wszędzie).

Jak wybrać hosting pod WordPress, opisałem szczegółowo w hosting WordPress – jak wybrać.

Są trzy sygnały, że shared hosting przestał Ci wystarczać:

1. Regularnie potrzebujesz >512M na pojedynczy request – shared hosting nie jest stworzony do takiej skali. Każdy request blokuje RAM dla innych użytkowników serwera, a hostingodawca prędzej czy później zacznie throttle'ować konto.
2. Importy i backupy timeout'ują nawet po 10 minutach – to znak, że CPU i I/O shared hostingu nie nadążają, nie sam RAM.
3. Masz sklep z 5000+ produktami i 100+ zamówień dziennie – tu VPS lub managed WordPress to nie fanaberia, tylko higiena.

Alternatywy do rozważenia:
- Managed WordPress (Cloudways, Kinsta, WP Engine) – drogie (100-500 zł/mies), ale zero konfiguracji
- Własny VPS (Hetzner, OVH) z CloudPanel lub RunCloud – 50-150 zł/mies, wymaga podstawowej wiedzy
- CyberFolks Business – punkt pośredni, można dostać własny kontener z 2-4 GB RAM

Migracja nie jest trudna, ale łatwo popełnić błąd (SEO, email deliverability, SSL). Jeśli potrzebujesz pomocy, skontaktuj się z nami – robimy migracje WordPress regularnie, łącznie z przepięciem WooCommerce bez utraty zamówień. Możemy też zająć się pełną opieką nad Twoim sklepem w ramach naszego serwisu WordPress.