Un site WordPress rapide ne dépend pas uniquement du thème ou du nombre d’extensions installées. La configuration de l’hébergement, la gestion du cache, des images et des tâches planifiées peuvent également avoir un impact important sur les performances.
J’ai récemment optimisé Festival Bretagne, un site WordPress hébergé chez o2switch. Plutôt que d’empiler les extensions d’optimisation, j’ai privilégié quelques réglages simples côté serveur et WordPress.
Voici la configuration que j’ai retenue et les résultats obtenus.
1. Remplacer WP-Cron par une vraie tâche Cron
WordPress utilise un système appelé WP-Cron pour gérer les tâches planifiées : publications programmées, opérations de maintenance, tâches lancées par certaines extensions, etc.
Contrairement à une véritable tâche Cron serveur, WP-Cron ne fonctionne pas en permanence. WordPress vérifie périodiquement, à l’occasion des chargements du site, si des tâches doivent être déclenchées.
Sur un site actif, il peut être intéressant de ne plus faire dépendre ces déclenchements des visites et de confier cette tâche directement au serveur.
Désactiver le déclenchement automatique de WP-Cron
Dans le fichier :
wp-config.phpj’ai ajouté :
define('DISABLE_WP_CRON', true);Cette instruction empêche WordPress de déclencher lui-même WP-Cron lors du fonctionnement normal du site.
Attention : il ne faut pas s’arrêter là.
Les tâches WordPress doivent toujours être exécutées. Il faut donc mettre en place une vraie tâche Cron sur le serveur.
2. Créer une tâche Cron dans o2switch
Depuis cPanel → Avancé → Tâches Cron, j’ai créé une tâche chargée d’appeler régulièrement le fichier wp-cron.php.
Dans mon cas, j’ai choisi une exécution une fois par heure :
0 * * * *avec une commande de ce type :
wget -q -O - https://votre-domaine.fr/wp-cron.php?doing_wp_cron >/dev/null 2>&1Il faut évidemment remplacer votre-domaine.fr par votre propre nom de domaine.
Le principe devient alors très simple :
Visiteur → WordPress → affichage de la page
et indépendamment :
Serveur o2switch → Cron → wp-cron.php → tâches WordPress
Les visiteurs ne servent donc plus de déclencheurs aux tâches planifiées.
Quelle fréquence choisir ?
Une exécution toutes les heures convient à mon site, mais cette fréquence n’est pas universelle.
Un site e-commerce, un système envoyant des e-mails, des imports automatiques ou une extension utilisant des tâches fréquentes peuvent nécessiter une exécution toutes les 15 minutes, voire une autre fréquence adaptée.
Il faut donc vérifier les besoins de son propre WordPress avant de choisir l’intervalle.
Cette optimisation ne garantit pas à elle seule une accélération spectaculaire du site. Elle permet surtout de rendre l’exécution des tâches planifiées plus régulière et de réduire le travail associé au déclenchement de WP-Cron pendant le fonctionnement du site.
3. Utiliser AccelerateWP pour le cache et les optimisations
o2switch propose des outils directement adaptés à son infrastructure.
Sur mon installation, j’ai choisi AccelerateWP pour gérer les principales optimisations de WordPress.
Un point important : je préfère éviter d’empiler plusieurs systèmes réalisant la même fonction.
Ajouter plusieurs extensions de cache ou activer simultanément plusieurs mécanismes similaires n’améliore pas nécessairement les performances. Cela peut au contraire provoquer des conflits ou rendre le diagnostic plus compliqué.
Ma règle est donc simple :
un système de cache correctement configuré vaut mieux qu’une accumulation d’extensions d’optimisation.
À propos de WPTiger
L’environnement o2switch évolue régulièrement.
o2switch propose également WPTiger, qui permet notamment d’activer le cache serveur LiteSpeed, un cache objet Redis et d’optimiser les tâches Cron WordPress en les remplaçant par le système Cron de l’hébergement.
Selon votre offre et la configuration actuelle de votre hébergement, vérifiez donc les outils disponibles dans votre espace o2switch avant d’ajouter une nouvelle extension ou un autre système de cache.
La configuration présentée dans cet article correspond à celle que j’ai réellement utilisée et testée sur mon site.
4. Optimiser les images
Les images représentent souvent une part importante du poids d’une page.
Dans AccelerateWP, j’ai donc activé :
- l’optimisation des images ;
- leur conversion vers un format moderne lorsque cela est pertinent ;
- le Lazy Load pour différer le chargement des images qui ne sont pas immédiatement visibles.
Le Lazy Load est très efficace, mais il faut faire attention à ne pas l’appliquer aveuglément à toutes les images.
5. Ne pas charger paresseusement l’image principale
PageSpeed Insights accorde une importance particulière au Largest Contentful Paint (LCP).
Il s’agit, pour simplifier, du moment où l’élément principal visible de la page est affiché.
Sur mon site, l’image mise en avant constitue fréquemment cet élément important situé immédiatement dans la partie visible de la page.
Or WordPress applique généralement à cette image la classe :
wp-post-imageJ’ai donc exclu cette classe du Lazy Load dans AccelerateWP :
wp-post-imageAinsi, les images situées plus bas dans la page peuvent continuer à profiter du Lazy Load, tandis que l’image principale peut être chargée immédiatement.
Cette règle ne doit toutefois pas être considérée comme universelle.
Selon votre thème et la structure de vos pages, wp-post-image n’est pas nécessairement votre élément LCP. Il faut le vérifier avec PageSpeed Insights ou les outils de développement du navigateur.
6. Purger le cache après les modifications
Après avoir modifié les réglages, il est important de purger complètement le cache.
Sinon, les tests de performance peuvent encore mesurer une ancienne version des pages et donner des résultats difficiles à interpréter.
Après chaque modification significative, ma méthode est donc :
- enregistrer le réglage ;
- purger le cache ;
- ouvrir le site et vérifier visuellement son fonctionnement ;
- tester ensuite les performances.
Je préfère également ne modifier qu’un nombre limité de paramètres à la fois. Il devient ainsi beaucoup plus facile d’identifier l’origine d’un problème éventuel.
7. Mesurer plutôt que multiplier les optimisations
Une fois ces modifications appliquées, j’ai contrôlé Festival Bretagne avec plusieurs outils, notamment PageSpeed Insights et Uptrends.
Les résultats obtenus étaient largement suffisants pour mon usage.
PageSpeed signalait encore certaines possibilités d’amélioration, notamment concernant des fichiers CSS susceptibles de bloquer le rendu.
J’aurais donc pu continuer.
J’ai volontairement décidé de ne pas le faire.
Pourquoi ?
Parce qu’un score de performance n’est pas une fin en soi.
À partir du moment où :
- le site est rapide ;
- l’affichage est stable ;
- l’expérience mobile est satisfaisante ;
- les principales pages se chargent correctement ;
- les fonctionnalités WordPress restent intactes ;
chercher à gagner encore quelques points peut apporter moins de bénéfices que de risques.
Modifier agressivement le CSS, retarder certains scripts ou multiplier les optimisations automatiques peut finir par casser une fonctionnalité pour un gain imperceptible pour le visiteur.
8. Ce que je retiens de cette optimisation
Cette expérience m’a surtout confirmé qu’il n’est pas nécessaire d’installer une multitude d’extensions pour obtenir un WordPress performant.
Sur mon site, j’ai privilégié :
- un hébergement o2switch correctement configuré ;
- un vrai Cron serveur à la place du déclenchement de WP-Cron par les visites ;
- un système de cache clairement identifié ;
- l’optimisation des images ;
- un Lazy Load utilisé avec discernement ;
- l’exclusion de l’image principale lorsque son chargement immédiat est préférable ;
- une purge du cache après modification ;
- et surtout des mesures avant de décider de poursuivre les optimisations.
Le plus important est probablement le dernier point.
Conclusion : savoir aussi s’arrêter
Optimiser WordPress peut rapidement devenir une course au score parfait.
Pourtant, passer de 60 à 90 sur un indicateur peut transformer réellement l’expérience utilisateur, alors que passer de 95 à 100 peut parfois nécessiter beaucoup de travail et introduire de nouveaux risques.
Sur Festival Bretagne, les modifications côté serveur et WordPress ont produit des résultats meilleurs que ceux que j’espérais.
J’ai donc choisi de m’arrêter là.
Le site est rapide, stable et fonctionnel : c’est finalement le meilleur indicateur de performance.
Important
Les réglages décrits ici correspondent à mon installation et à mon retour d’expérience. Avant de modifier wp-config.php, les tâches Cron ou le système de cache d’un site en production, effectuez une sauvegarde et vérifiez que vos extensions n’ont pas de besoins particuliers.
L’environnement o2switch et WordPress évoluant régulièrement, certaines opérations décrites ici peuvent également être automatisées ou proposées directement par les outils o2switch.