WordPress bestaat grotendeels uit PHP-code. Bij een ongecachet verzoek leest de server scripts, voert plug-ins en thema uit, vraagt data op en bouwt HTML. De PHP-configuratie bepaalt daarom hoeveel tijd en capaciteit dit kost. Een moderne versie, actieve OPcache en een passend aantal workers vormen samen een snelle basis; één los getal lost geen overbelaste applicatie op.

Een ondersteunde PHP-versie is de eerste stap
Nieuwe PHP-versies brengen prestatie- en beveiligingsverbeteringen, maar een upgrade moet compatibel zijn met thema, plug-ins en maatwerk. Test eerst op staging, controleer de foutlog en doorloop formulieren, beheeracties, cronjobs en checkout. Blijf niet op een verouderde versie omdat één verlaten plug-in niet meekomt; vervang de zwakke schakel planmatig.
OPcache voorkomt steeds opnieuw compileren
PHP-code moet vóór uitvoering naar bytecode worden gecompileerd. OPcache bewaart die gecompileerde bytecode in gedeeld geheugen, zodat scripts niet bij ieder verzoek opnieuw geanalyseerd en gecompileerd worden. Dat verlaagt CPU-gebruik en responstijd. Het geheugen moet groot genoeg zijn voor de actieve codebasis; een volle cache met veel herstarts of evictions maakt de winst instabiel.
Wat is een PHP-worker?
Een worker behandelt één dynamisch PHP-verzoek tegelijk. Paginacache kan veel bezoekers afhandelen zonder PHP-worker, maar login, zoeken, winkelmand, checkout, API-calls en sommige AJAX-acties gebruiken er wel één. Zijn alle workers bezig, dan ontstaat een wachtrij. Meer workers helpen alleen zolang CPU, RAM en database het extra gelijktijdige werk aankunnen.
Geheugenlimiet is niet hetzelfde als beschikbaar geheugen
memory_limit is het maximum voor één PHP-proces, geen hoeveelheid geheugen die een website permanent krijgt. Een extreem hoge limiet kan bij meerdere workers juist leiden tot uitputting. CloudLinux-limieten voor CPU, geheugen, processen en I/O bewaken het account als geheel. Bekijk daarom de combinatie en zoek de oorzaak van terugkerende limietfouten.
PHP-FPM, LiteSpeed en de workload
De procesmanager of webserver bepaalt hoe workers worden gestart, hergebruikt en beëindigd. Instellingen moeten passen bij verkeerspatroon en servercapaciteit. Een nieuwssite met veel cachebare pagina’s vraagt iets anders dan WooCommerce met persoonlijke sessies. LiteSpeed-cache vermindert het aantal PHP-starts; Redis vermindert terugkerend databasewerk binnen dynamische requests.
Meten vóór verhogen
- Controleer trage verzoeken, 5xx-fouten en time-outs in logs.
- Meet hoeveel verzoeken werkelijk cache HIT zijn.
- Bekijk CPU, geheugen, entry processes, I/O en databasewachttijd tijdens pieken.
- Controleer OPcache-geheugen, hitratio en herstarts.
- Profileer plug-ins of queries die één request buitensporig duur maken.
Verhoog workers of limieten pas wanneer metingen aantonen dat de applicatie efficiënt is en de server nog ruimte heeft. Anders maakt u een file langer zonder de kassa sneller te maken. Voor dynamische winkels sluit dit direct aan op onze gids WooCommerce sneller maken; voor algemene keuzes leest u welk hostingtype past.





