OPcache w WordPressie przechowuje w pamięci RAM skompilowany kod PHP, dzięki czemu serwer nie musi analizować i kompilować tych samych plików przy każdym żądaniu. Włączenie go zwykle zmniejsza obciążenie CPU i skraca czas odpowiedzi serwera, ale nie zastępuje page cache ani cache obiektowego.
Czym jest OPcache i dlaczego WordPress go potrzebuje?
Zend OPcache to rozszerzenie PHP odpowiedzialne za przechowywanie kodu bajtowego, czyli opcode wygenerowanego po analizie i kompilacji pliku PHP. Przy kolejnym żądaniu PHP może skorzystać z gotowego kodu zamiast ponownie wykonywać te same operacje.
WordPress szczególnie korzysta z tej warstwy, ponieważ rdzeń, motyw i wtyczki ładują dużą liczbę plików PHP. Bez OPcache serwer za każdym razem odczytuje je z dysku i przetwarza. Po aktywacji kod jest dostępny w pamięci współdzielonej, co zwykle ogranicza liczbę operacji procesora i poprawia TTFB. Na współczesnych hostingach OPcache jest często włączony domyślnie.
Jak sprawdzić, czy OPcache działa?
Najpewniejszą metodą jest sprawdzenie konfiguracji PHP używanej przez konkretną stronę. Panel hostingu może pokazywać inną wersję PHP niż ta obsługująca żądania WordPressa.
Wykonaj następujące kroki:
- Utwórz tymczasowy plik, na przykład
info.php, z zawartością<?php phpinfo();. - Umieść plik w katalogu strony i otwórz go w przeglądarce.
- Wyszukaj sekcję „Zend OPcache” lub „Opcode Caching” i sprawdź, czy parametr
opcache.enablema wartośćOn. - Po sprawdzeniu usuń plik, ponieważ
phpinfo()ujawnia szczegóły konfiguracji serwera.
Na hostingu współdzielonym status można też sprawdzić w panelu PHP, a w WordPressie – za pomocą narzędzia diagnostycznego pokazującego moduły i ustawienia PHP. Sama obecność rozszerzenia nie wystarcza. Istotne jest to, czy działa ono w tej wersji PHP i w tym trybie SAPI, który obsługuje witrynę.
Jak skonfigurować OPcache dla WordPressa?
Na cPanelu lub DirectAdmin przejdź do ustawień wersji PHP, rozszerzeń albo edycji parametrów PHP i włącz opcache. Nazwy sekcji zależą od konfiguracji hostingu. Po zapisaniu zmian może być potrzebne przeładowanie PHP-FPM, LSAPI albo usługi serwera.
Na VPS-ie lub serwerze dedykowanym ustawienia zwykle trafiają do właściwego pliku php.ini. Przykładowy fragment konfiguracji może wyglądać tak:
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
realpath_cache_size=4096K
realpath_cache_ttl=600Nie kopiuj tych wartości bez sprawdzenia limitów pamięci i sposobu zarządzania PHP na serwerze. Dla typowej instalacji WordPressa mogą stanowić punkt wyjścia:
| Parametr | Zalecana wartość | Znaczenie |
|---|---|---|
opcache.memory_consumption |
128 MB | Pamięć przeznaczona na skompilowany kod. Duże instalacje z wieloma wtyczkami mogą wymagać większej wartości. |
opcache.max_accelerated_files |
10000 | Maksymalna liczba plików przechowywanych w cache. Zbyt niski limit może powodować wypadanie skryptów z pamięci podręcznej. |
opcache.validate_timestamps |
1 na produkcji zarządzanej ręcznie lub 0 po wdrożeniu z resetem cache | Decyduje, czy PHP sprawdza zmiany w plikach. Przy wartości 0 po zmianie kodu trzeba wyczyścić albo zresetować OPcache. |
realpath_cache_size |
4096K lub więcej | Przechowuje wyniki rozwiązywania ścieżek plików i ogranicza powtarzanie operacji systemu plików. |
Na małym hostingu większa pamięć dla OPcache nie zawsze oznacza poprawę. Liczy się dostępna pamięć RAM, liczba witryn korzystających z serwera oraz liczba plików ładowanych przez aplikację. Po zmianie parametrów sprawdź w phpinfo(), czy zostały zastosowane, a następnie wyczyść cache aplikacji i wykonaj test TTFB.
Dlaczego strona może być wolna mimo działającego OPcache?
OPcache przechowuje skompilowany kod, ale nie rozwiązuje wszystkich operacji wykonywanych podczas ładowania WordPressa. Jednym z pomijanych często elementów jest Realpath Cache. PHP używa go do zapamiętywania wyników rozwiązywania ścieżek plików. Gdy kod wykonuje wiele instrukcji include lub require, system musi sprawdzać kolejne katalogi i pliki. Bez cache oznacza to powtarzane wywołania systemowe, między innymi stat().
Problem jest szczególnie widoczny przy dużej liczbie wtyczek, rozbudowanym motywie i hostingu współdzielonym. Jeżeli proces PHP jest często kończony i tworzony od nowa, zawartość Realpath Cache nie ma czasu się rozgrzać. Taki efekt może wystąpić przy agresywnym recyklingu workerów PHP-FPM lub LSAPI. Dodatkowy narzut izolacji środowiska, na przykład CloudLinux LVE, może zwiększyć koszt wielu operacji systemu plików.
Sprawdź wartość funkcją realpath_cache_size() w tym samym środowisku PHP, które obsługuje WordPressa. Wynik 0 oznacza, że cache ścieżek jest wyłączony albo niedostępny w danym procesie. Sama liczba nie pozwala jednak ocenić całej konfiguracji, dlatego porównaj ją z ustawieniami realpath_cache_ttl, sposobem recyklingu workerów i rzeczywistym TTFB.
Jeśli OPcache działa, ale WordPress nadal długo generuje odpowiedź, nie zakładaj od razu, że winna jest wtyczka. Pusty Realpath Cache może powodować wielokrotne sprawdzanie tych samych ścieżek przy każdym żądaniu.
Przed zmianami na serwerze sprawdź podstawowe elementy diagnostyczne:
- Status
opcache.enablei aktualnie używaną wersję PHP. - Wartość
opcache_get_status(), w tym zużycie pamięci i liczbę skryptów w cache. - Wartość
realpath_cache_size()oraz ustawienie czasu życia wpisów. - Typ SAPI, na przykład PHP-FPM lub LiteSpeed LSAPI, i sposób recyklingu workerów.
- TTFB dla zalogowanego i niezalogowanego użytkownika.
Jeżeli Realpath Cache pozostaje pusty, a nie masz dostępu do ustawień procesów PHP, zgłoś problem administratorowi hostingu. Gdy po prawidłowej konfiguracji obu mechanizmów TTFB nadal jest wysoki, kolejne podejrzane obszary to zapytania do bazy danych, wolne wtyczki, zewnętrzne API i przeciążenie serwera.
OPcache, Page Cache i Object Cache – czym się różnią?
Te mechanizmy działają na różnych poziomach i zwykle powinny się uzupełniać:
- OPcache przechowuje skompilowany kod PHP i ogranicza ponowną kompilację plików.
- Page Cache zapisuje gotowy wynik HTML, więc przy części żądań WordPress nie musi generować strony od początku.
- Object Cache, często oparty na Redisie lub Memcached, przechowuje wyniki zapytań i obliczeń wykonywanych przez aplikację.
- Cache przeglądarki przechowuje wybrane zasoby po stronie urządzenia użytkownika.
OPcache nie jest tym samym co Redis. Włączenie jednej warstwy nie zastępuje pozostałych, ale też nie oznacza konieczności instalowania każdej z nich. Dobór zależy od charakteru strony i wyników pomiarów. Samo włączenie OPcache rzadko powoduje problemy, a w razie nieprawidłowości można go wyłączyć w konfiguracji PHP i sprawdzić logi.
Najpierw potwierdź działanie OPcache, potem sprawdź Realpath Cache i dopiero na tej podstawie oceniaj TTFB. To bezpieczniejsza droga niż wymiana wtyczek bez pomiarów.
