Un site WordPress rapide repose sur plusieurs éléments : l’hébergement, le thème, les extensions et la façon dont les ressources sont chargées. Chez o2switch, AccelerateWP peut participer à cette optimisation. D’autres réglages permettent de compléter le travail : limiter l’exposition des erreurs techniques, activer un cache d’objet Redis et confier le déclenchement des tâches planifiées au serveur.
Après plusieurs phases d’optimisation, nous avons obtenu un score de 100/100 en performances sur ordinateur dans Google PageSpeed Insights. Ce résultat correspond à un test donné : il ne garantit ni le même score sur mobile, ni un résultat identique sur toutes les pages. Voici les réglages à comprendre et à adapter à votre installation.
Avant de commencer : sauvegarder et avancer par étapes
Effectuez une sauvegarde des fichiers et de la base de données. Conservez également une copie de wp-config.php avant toute modification. Ce fichier se trouve généralement à la racine de WordPress et contient des informations sensibles : ne publiez jamais son contenu intégral.
Appliquez une modification à la fois, puis contrôlez le site et son administration. Si une constante existe déjà dans wp-config.php, modifiez sa valeur au lieu d’ajouter une seconde définition. Les réglages présentés ici doivent être placés avant la ligne /* That's all, stop editing! Happy publishing. */ et avant le chargement de wp-settings.php.
1. Sécurité en production : éviter l’exposition des erreurs et des journaux
Le débogage est utile pendant le développement. Sur un site public, l’affichage d’erreurs ou un journal accessible depuis le Web peuvent toutefois révéler des chemins de fichiers, des noms d’extensions et d’autres informations techniques.
Le fichier wp-content/debug.log n’est pas systématiquement accessible : cela dépend des protections du serveur. Il faut néanmoins éviter de laisser un journal sensible dans un emplacement public sans protection.
/** Réglages de débogage pour un site en production. */
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );Attention : désactiver la journalisation ne supprime pas un ancien fichier debug.log. Vérifiez s’il existe et s’il est accessible publiquement. Conservez, si nécessaire, une copie dans un emplacement privé avant de retirer le fichier exposé ou d’en bloquer l’accès.
Pour diagnostiquer un incident en production, utilisez de préférence des journaux protégés, hors de la racine publique, ou les outils de l’hébergeur. Ces trois constantes ne remplacent pas les mises à jour, les sauvegardes et la protection des comptes administrateurs.
2. Accélérer les traitements WordPress avec Redis Object Cache
Un cache de pages et un cache d’objet remplissent des fonctions différentes. Le premier conserve une version HTML d’une page. Le second garde en mémoire des objets et des résultats de traitements que WordPress pourra réutiliser, ce qui peut réduire les accès à la base de données.
Redis peut ainsi être utile pour l’administration, les visiteurs connectés et les pages dynamiques. Son intérêt dépend du site : il ne rend pas le temps de réponse instantané et ne remplace pas l’optimisation des images, du thème ou des scripts.
Étape A : préparer Redis dans cPanel
Dans cPanel, ouvrez l’outil Redis et créez une instance si aucune n’est déjà disponible. Choisissez le mode Socket lorsque votre configuration le permet. Relevez le chemin exact du socket et le mot de passe affichés par l’outil. Dans « Sélectionner une version de PHP », vérifiez également l’activation de l’extension PHP redis pour la version utilisée par le site.
La documentation officielle o2switch sur Redis détaille la création de l’instance, les paramètres de connexion et les précautions lorsque plusieurs applications partagent le serveur.
Étape B : connecter WordPress sans superposer deux caches d’objet
La méthode suivante utilise l’extension Redis Object Cache. Avant de l’activer, vérifiez qu’aucun autre outil ne gère déjà le cache d’objet persistant. Si AccelerateWP ou une autre extension assure cette fonction, choisissez une seule solution. Un cache de pages peut compléter Redis ; deux gestionnaires du fichier wp-content/object-cache.php risquent en revanche de se gêner.
Ajoutez cette configuration dans wp-config.php, en remplaçant chaque valeur d’exemple par les informations de votre hébergement :
/** Connexion à Redis : valeurs à adapter. */
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/CHEMIN/EXACT/DU/SOCKET/redis.sock' );
define( 'WP_REDIS_PASSWORD', 'VOTRE_MOT_DE_PASSE_REDIS' );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mon-site-fr-production:' );Installez ensuite Redis Object Cache depuis le répertoire des extensions WordPress. Dans ses réglages, activez le cache d’objet et vérifiez que la connexion est établie et que le fichier de cache est valide. Contrôlez enfin quelques pages et l’administration.
Alerte : plusieurs sites sur le même hébergement et WordPress multisite
Ne recopiez pas la même configuration Redis sur plusieurs installations sans adapter leur isolation. Si deux WordPress indépendants utilisent la même instance et la même base Redis, ils doivent disposer de préfixes de clés différents. Vous pouvez également leur attribuer des bases Redis distinctes parmi celles disponibles sur votre instance.
Par exemple, utilisez site-a-production: pour un site et site-b-production: pour l’autre. Une copie de test doit aussi avoir sa propre configuration. Sans cette précaution, des données de cache peuvent se mélanger et provoquer des comportements incohérents. Une purge globale d’une base partagée peut également affecter les autres applications qui l’utilisent.
Un réseau WordPress multisite est un cas différent de plusieurs WordPress indépendants. Son cache doit respecter les données propres à chaque sous-site et les données communes au réseau. N’appliquez pas mécaniquement une configuration distincte par sous-site : faites vérifier la configuration du réseau, ainsi que la planification de ses tâches.
3. Confier le déclenchement des tâches WordPress au serveur
WordPress utilise WP-Cron pour gérer les publications programmées, certaines vérifications de mises à jour et les tâches de nombreuses extensions. Son déclenchement habituel dépend des visites. Sur un site peu fréquenté, une tâche peut donc démarrer en retard.
Une tâche planifiée dans cPanel permet d’appeler régulièrement wp-cron.php, indépendamment du trafic. Les traitements restent exécutés par WordPress sur votre hébergement : ils ne disparaissent pas, mais leur déclenchement devient plus régulier.
Étape A : créer et vérifier la tâche dans cPanel
Ouvrez « Tâches Cron » dans cPanel. Pour une exécution toutes les quinze minutes, saisissez */15 dans le champ Minute et * dans chacun des quatre autres champs. Dans le champ Commande, entrez uniquement :
wget -q -O - "https://mon-site.fr/wp-cron.php" >/dev/null 2>&1Remplacez https://mon-site.fr par l’adresse réelle de votre installation. Si WordPress se trouve dans un sous-dossier, adaptez le chemin. Le mot bash ne doit pas être collé à wget. L’adresse doit cibler wp-cron.php, et non simplement la page d’accueil.
L’option -q rend wget silencieux ; -O - envoie le contenu reçu vers la sortie standard ; >/dev/null 2>&1 masque les sorties et les erreurs. Pour le diagnostic initial, retirez temporairement -q et la redirection finale afin de voir les éventuelles erreurs. Une réponse vide de wp-cron.php est normale, mais ne suffit pas à prouver que toutes les tâches ont réussi.
Quinze minutes constituent un exemple pour un site éditorial. Si certaines extensions exigent des traitements plus fréquents, adaptez l’intervalle à leurs besoins et à la durée des traitements.
Étape B : désactiver le déclenchement lié aux visites
Après avoir créé et vérifié la tâche serveur, ajoutez cette constante dans wp-config.php :
define( 'DISABLE_WP_CRON', true );Ne désactivez pas ce déclenchement sans solution de remplacement fonctionnelle. Vérifiez ensuite une publication programmée et les tâches importantes de vos extensions. Si un outil de l’hébergeur a déjà configuré le cron, contrôlez l’existant avant de créer un doublon.
Pour approfondir, consultez la documentation officielle WordPress sur le raccordement de WP-Cron au planificateur système.
4. Vérifier les résultats sans courir après le score
Après les changements, contrôlez les pages importantes sur ordinateur et sur mobile : navigation, formulaires, recherche et éventuelles fonctions de réservation ou de paiement. Vérifiez également les visiteurs connectés et les mises à jour de contenu après purge du cache concerné.
Comparez plusieurs tests PageSpeed Insights sur les mêmes URL, séparément pour mobile et ordinateur. Un score de 100/100 est satisfaisant, mais l’objectif reste un site rapide, stable et utilisable. Les scripts tiers, les images et la complexité des pages peuvent continuer à limiter les performances malgré une bonne configuration serveur. Et une attention particulière doit être apportée aux sites multi-langues que nous n’abordons pas ici.
Ces réglages garantissent-ils un score de 100/100 sur PageSpeed ?
Non. Le résultat dépend de la page testée, des images, des scripts, du thème et des conditions de mesure. Un score obtenu sur ordinateur ne préjuge pas du score mobile. Comparez plusieurs mesures et vérifiez toujours le fonctionnement du site.
Peut-on utiliser AccelerateWP et Redis Object Cache ensemble ?
Un cache de pages et un cache d’objet Redis peuvent se compléter. Il faut en revanche qu’une seule solution gère le cache d’objet persistant. Vérifiez les fonctions déjà actives dans AccelerateWP et les autres extensions avant d’ajouter Redis Object Cache.
Que faut-il prévoir si plusieurs sites utilisent Redis ?
Chaque installation indépendante doit utiliser un préfixe de clés unique ou une base Redis distincte. Séparez également production et préproduction. Pour un réseau WordPress multisite, faites vérifier la configuration à l’échelle du réseau.
Pourquoi appeler wp-cron.php plutôt que la page d’accueil ?
Le fichier wp-cron.php déclenche le traitement des tâches arrivées à échéance. Une visite de la page d’accueil ne le remplace pas, notamment lorsque le déclenchement automatique est désactivé ou que la page est servie depuis un cache.
Une exécution toutes les quinze minutes suffit-elle ?
Cela peut convenir à un site éditorial, en acceptant un décalage pouvant approcher quinze minutes. Une boutique ou une extension qui traite des files d’attente peut demander une fréquence supérieure. Adaptez la planification aux besoins réels du site.
Désactiver WP_DEBUG_LOG efface-t-il un ancien debug.log ?
Non. Le fichier déjà présent reste en place. Vérifiez son accessibilité et protégez-le ou retirez-le après en avoir conservé une copie privée si elle est nécessaire au diagnostic.