Un développeur migre une boutique PrestaShop vers un VPS « plus rapide ». Les pages restent molles. Le profilage montre 40 % du temps processeur en compilation PHP. OPcache était désactivé dans un php.ini copié depuis un vieux mutualisé. Deux lignes corrigées, TTFB divisé par deux — sans toucher au processeur.
OPcache stocke le bytecode compilé des fichiers PHP en mémoire partagée. Sans lui, chaque requête relit et recompile les sources. Sur WordPress — des centaines de fichiers inclus — l'impact est massif. C'est souvent le premier levier à vérifier, avant PHP-FPM, avant HTTP/3, avant un changement d'hébergeur.
Vérifier l'état réel — ne pas supposer
php -i | grep -E 'opcache.enable|opcache.memory'
Ou une page phpinfo() temporaire en préproduction. Points clés :
| Directive | Rôle | Signal d'alerte |
|---|---|---|
opcache.enable=1 | Active le cache | 0 en production |
opcache.memory_consumption | Mémoire dédiée (Mo) | Trop bas → évictions fréquentes |
opcache.max_accelerated_files | Nombre de fichiers max | WordPress + Composer > 10 000 → augmenter |
opcache.validate_timestamps | Recompile si fichier modifié | Désactivé sans procédure deploy = bugs fantômes |
opcache.revalidate_freq | Délai de vérification | Trop haut en dev, acceptable en prod stable |
Sur PHP 8 et plus, le JIT peut aider sur calcul intensif ; gain marginal sur CMS classique — ne le priorisez pas avant un OPcache sain.
Réglages pragmatiques par contexte
WordPress / CMS mutualisé — confirmez enable=1 et max_accelerated_files ≥ 10000 ; laissez souvent les valeurs par défaut de l'hébergeur. VPS avec déploiements Git — validate_timestamps=0 en production si votre pipeline recharge PHP-FPM ou appelle opcache_reset() en CLI après deploy. Conteneurs éphémères — OPcache repart à zéro à chaque redémarrage ; un script de préchauffage peut aider. Multisite ou gros monorepo — surveillez opcache_get_status() : taux de succès < 95 % → mémoire ou max_files insuffisant.
Liens avec FPM et TTFB
Chaque worker PHP-FPM bénéficie de la mémoire OPcache partagée. Un OPcache sous-dimensionné force des recompilations et gonfle la RAM par worker indirectement. Séquence logique : OPcache correct, puis cache objet Redis ou cache page, puis réglage PHP-FPM, puis diagnostic TTFB. Ignorer OPcache puis doubler les workers, c'est payer deux fois la même erreur.
Le sommet : le cache bytecode n'apparaît pas dans PageSpeed
Le marketing vend des cœurs processeur ; OPcache est invisible sur la fiche commerciale — mais déterminant sur la facture et la latence réelle. Comparez hébergeurs via l'annuaire seulement après vérification.
Décider et avancer sans angle mort
Confirmez en production que opcache.enable est actif et relevez le taux de succès du cache avant toute autre optimisation. Ajustez memory_consumption et max_accelerated_files selon la taille réelle du projet — WordPress avec nombreuses extensions dépasse vite dix mille fichiers. Documentez la procédure de vidage au déploiement : reload PHP-FPM ou reset CLI, jamais endpoint public. Mesurez le TTFB avant et après ; seulement ensuite optimisez FPM ou changez d'hébergeur.
Questions fréquentes
OPcache est-il activé par défaut ?
Sur PHP 7 et plus en production, souvent oui — mais pas toujours sur mutualisé ancien ou images conteneur minimales. Vérifiez avec phpinfo() ou php -i | grep opcache.
validate_timestamps activé ou désactivé en production ?
Désactivé plus redeploy qui vide OPcache = performances maximales. Activé plus déploiements fréquents = plus simple sans oublier de vider le cache. Choisissez selon votre pipeline, pas une règle universelle.
OPcache remplace-t-il Redis ou un cache page ?
Non. OPcache met en cache le bytecode PHP compilé. Redis cache les données applicatives ; un cache page évite d'exécuter PHP. Les trois se complètent.
Comment vider OPcache après un déploiement ?
Rechargez PHP-FPM, appelez opcache_reset() en ligne de commande dédiée, ou intégrez le reset dans l'outil de déploiement — jamais en exposant reset() publiquement sur le web.
Avant d'acheter un serveur plus rapide, une question : OPcache est-il activé et quel est son taux de succès ? Si vous ne l'avez jamais regardé, vous n'avez pas encore optimisé PHP.