Chaque fois qu'une page PHP est demandée, l'interpréteur doit lire les fichiers sources, les analyser et les compiler en instructions exécutables, appelées opcodes. Sur un site WordPress ou Symfony, cela représente des centaines de fichiers à chaque requête. OPcache supprime ce travail répétitif en gardant le code compilé en mémoire. C'est souvent le réglage serveur qui offre le meilleur gain de performance pour le moindre effort, à condition de bien le configurer.
Pourquoi OPcache change tout
Sans cache d'opcodes, le serveur recompile le même code des milliers de fois par jour. Avec OPcache, la compilation n'a lieu qu'une fois : les requêtes suivantes réutilisent directement le résultat stocké en mémoire partagée. Le temps de réponse du serveur (le TTFB) baisse nettement, tout comme la charge du processeur, ce qui permet de servir plus de visiteurs avec la même machine.
OPcache est intégré à PHP depuis la version 5.5. Sur la plupart des hébergements il est déjà activé, mais rarement avec des réglages adaptés au site qu'il sert. Un serveur lent coûte cher, comme je l'explique dans mon article sur le coût d'un site lent.
Vérifier qu'OPcache est actif
En ligne de commande, la commande suivante affiche les paramètres actuels :
php -i | grep -i opcache
Attention : PHP en ligne de commande et PHP-FPM utilisent souvent des fichiers de configuration différents. Pour connaître l'état réel du cache côté web, appelez opcache_get_status() depuis une page protégée, ou consultez la section OPcache de phpinfo(). Ne laissez jamais ce type de page accessible publiquement.
Les réglages recommandés en production
Voici la base que j'utilise sur les serveurs que j'administre, à placer dans un fichier dédié, par exemple /etc/php/8.4/fpm/conf.d/99-opcache.ini :
opcache.enable=1
; Mémoire réservée au code compilé (en Mo)
opcache.memory_consumption=256
; Mémoire pour les chaînes de caractères identiques (en Mo)
opcache.interned_strings_buffer=32
; Nombre maximal de fichiers en cache
opcache.max_accelerated_files=20000
; Ne plus vérifier si les fichiers ont changé
opcache.validate_timestamps=0
Dimensionner la mémoire
Les valeurs par défaut (128 Mo et 10 000 fichiers) suffisent pour un petit site, mais un WordPress avec une vingtaine d'extensions ou un projet Symfony avec ses dépendances les dépasse facilement. Quand le cache est plein, PHP cesse d'y ajouter des fichiers, et les performances se dégradent sans aucun message d'erreur visible.
Surveillez les indicateurs memory_usage et opcache_statistics retournés par opcache_get_status() : si la mémoire libre approche de zéro ou si le taux de réussite (hit rate) descend sous 99 %, augmentez les valeurs.
validate_timestamps : le réglage le plus important
Par défaut, OPcache vérifie régulièrement si chaque fichier a été modifié sur le disque (toutes les 2 secondes, selon opcache.revalidate_freq). En production, le code ne change qu'au moment des déploiements : ces vérifications sont donc du travail inutile.
Avec validate_timestamps=0, OPcache ne vérifie plus rien. En contrepartie, il faut vider le cache après chaque mise en ligne, sinon le serveur continue d'exécuter l'ancienne version du code.
Gérer les déploiements
La méthode la plus simple consiste à recharger PHP-FPM à la fin du déploiement :
sudo systemctl reload php8.4-fpm
Un reload est sans coupure : les processus en cours terminent leurs requêtes, puis les nouveaux démarrent avec un cache vide. C'est ce que fait mon script de déploiement, juste après la mise à jour du code et des dépendances. Si vous automatisez vos mises en ligne avec une chaîne CI/CD, ajoutez cette étape en dernier.
Sur un hébergement mutualisé sans accès au service, certains outils proposent d'appeler opcache_reset() via une URL protégée. Cela fonctionne, mais il faut s'assurer que l'appel passe bien par PHP-FPM et non par la ligne de commande, qui a son propre cache.
Le préchargement
Depuis PHP 7.4, la directive opcache.preload permet de charger un ensemble de fichiers en mémoire au démarrage de PHP-FPM. Symfony génère automatiquement un fichier de préchargement adapté à chaque projet. Le gain est réel sur les gros frameworks, plus modeste sur un site simple. Le préchargement impose aussi un redémarrage complet de PHP-FPM (pas un simple reload) à chaque modification du code préchargé : réservez-le aux projets où le processus de déploiement est bien maîtrisé.
Et le JIT ?
PHP 8.0 a introduit un compilateur JIT (Just In Time), qui s'appuie sur OPcache pour transformer certaines portions de code en instructions machine. Les tests publiés montrent des gains importants sur les calculs intensifs, mais faibles pour une application web classique, dont le temps est surtout passé à attendre la base de données et le réseau. Pour un site vitrine ou un blog, je le laisse désactivé : le gain ne justifie pas la mémoire consommée.
OPcache ne fait pas tout
OPcache accélère l'exécution du code PHP, mais il ne corrige ni des requêtes SQL lentes, ni des images trop lourdes. Il s'intègre dans une démarche globale : cache HTTP, cache applicatif avec Redis, optimisation MySQL et un front-end léger. Toutes les directives sont documentées sur php.net.
Vous voulez savoir si votre serveur est correctement réglé ? Je propose des audits de performance et d'hébergement pour les sites PHP, WordPress et Symfony.
