Combien de classes du cœur WordPress peut-on précharger sans casser une mise à jour automatique ? La réponse tient en une contrainte simple à respecter : seules les classes qui ne changent jamais entre deux exécutions du serveur PHP-FPM se prêtent au préchargement. Le préchargement OPcache, disponible depuis PHP 7.4, charge en mémoire partagée, une seule fois au démarrage du worker PHP-FPM, un ensemble de classes et de fonctions qui restent ensuite disponibles pour toutes les requêtes suivantes sans jamais être relues sur le disque.
Le gain se joue sur deux plans : moins d’accès disque au premier appel de chaque classe, et surtout un cache OPcache qui n’a plus besoin de vérifier la fraîcheur du fichier source à chaque requête pour ces classes précises. Sur un hébergement mutualisé qui redémarre rarement ses workers PHP-FPM, cette économie reste modeste mais réelle, et elle grandit avec le nombre de requêtes traitées entre deux redémarrages.
Étape 1 : vérifier la compatibilité de l’hébergement
Le préchargement nécessite un accès à php.ini ou à un fichier de configuration PHP-FPM propre au site, ce qui exclut d’office une partie des hébergements mutualisés bas de gamme où seule une directive .htaccess reste modifiable. Il faut aussi que le serveur PHP-FPM soit redémarré à chaque déploiement de code, sans quoi le préchargement continuerait de servir une version obsolète des classes après une mise à jour du cœur ou d’une extension.
Étape 2 : écrire le script de préchargement
<?php
// preload.php — chargé une seule fois au démarrage du worker
$racine = __DIR__ . '/wp-includes/';
$classes = [
'class-wp-hook.php',
'class-wp-query.php',
'class-wp-post.php',
'class-wp-rewrite.php',
'class-wp-scripts.php',
];
foreach ($classes as $fichier) {
$chemin = $racine . $fichier;
if (is_readable($chemin)) {
opcache_compile_file($chemin);
}
}
Étape 3 : activer le préchargement dans la configuration
La directive opcache.preload pointe vers ce script, et doit être définie au niveau du pool PHP-FPM plutôt qu’en .htaccess, puisque le préchargement s’exécute avant même que WordPress ne commence à traiter une requête. Un second réglage, opcache.preload_user, précise l’utilisateur système sous lequel le script s’exécute, généralement celui du pool PHP-FPM concerné.
Ce qu’il vaut mieux ne pas précharger
- Les classes de plugins tiers, mises à jour à un rythme que le développeur du site ne maîtrise pas toujours.
- Les classes qui dépendent de constantes définies dynamiquement dans
wp-config.php, susceptibles de changer selon l’environnement. - Tout fichier encore actif dans les tests, où un redémarrage fréquent du pool viendrait annuler le bénéfice recherché.
Étape 4 : vérifier que le préchargement fonctionne
La fonction opcache_get_status() renvoie, sous la clé preload_statistics, le nombre de scripts et de fonctions effectivement préchargés au démarrage. C’est la seule façon fiable de confirmer que la configuration a été prise en compte, plutôt que de se fier à une simple absence d’erreur dans les journaux.
Intégrer le préchargement dans un pipeline de déploiement
Sur un serveur infogéré où les déploiements passent par un script automatisé, la bonne pratique consiste à faire suivre chaque déploiement d’un redémarrage explicite du pool PHP-FPM concerné, plutôt que de compter sur un redémarrage périodique décidé indépendamment par le système. Un script de déploiement typique enchaîne le déploiement des fichiers, une purge du cache OPcache existant, puis le redémarrage du service :
#!/bin/bash
set -e
rsync -a --delete build/ /var/www/site/
systemctl restart php8.3-fpm-site
Sans ce redémarrage, le script de préchargement ne serait relu qu’à la prochaine coupure fortuite du service, ce qui signifie que les classes fraîchement modifiées continueraient d’être servies dans leur ancienne version préchargée pendant une durée indéterminée, un bug particulièrement difficile à diagnostiquer puisque le code sur le disque semble pourtant correct.
En résumé
Le préchargement OPcache reste un réglage de niche pour WordPress : utile sur un serveur dédié ou infogéré où l’on maîtrise le cycle de redémarrage des workers, risqué sur un mutualisé partagé où les mises à jour de plugins échappent souvent au contrôle direct du développeur. La règle à retenir est simple : ne précharger que ce qui ne change jamais sans un redémarrage explicite du service PHP-FPM.
