Un client nous contacte en mars dernier. Son site WordPress, une boutique en ligne dans le secteur de la décoration, met entre 8 et 11 secondes à charger. Son taux de conversion s’effondre. Google l’a rétrogradé dans les résultats de recherche. Il a essayé d’installer un plugin de cache, sans résultat visible. Il ne comprend pas pourquoi.
En une journée de travail, nous avons ramené ce temps de chargement à 2,3 secondes. Score PageSpeed Mobile passé de 28 à 74. Voici exactement ce que nous avons fait, étape par étape.
Contexte et problématique
Présentation du site et des enjeux de performance
Le site en question tourne sous WordPress avec WooCommerce, un thème premium acheté sur ThemeForest, et une vingtaine de plugins actifs. Il héberge environ 200 produits avec leurs photos, plusieurs sliders en page d’accueil, et un système de chat en direct. Rien d’inhabituel pour un site e-commerce de cette taille.
Le problème, c’est que tout cela s’était accumulé sans jamais être optimisé. Le thème avait été installé avec ses démos de démonstration, incluant des dizaines de ressources inutilisées. Les images avaient été uploadées telles quelles depuis un appareil photo, parfois en 4 à 6 mégaoctets par photo. Aucune mise en cache n’était correctement configurée. Et l’hébergement mutualisé d’entrée de gamme ne suivait plus.
Impact de la lenteur sur l’expérience utilisateur et le référencement
Google intègre les Core Web Vitals dans son algorithme depuis 2021. Un site lent est pénalisé dans les résultats de recherche, pas seulement ignoré. Pour ce client, la conséquence était directe : des pages produits qui ne remontaient plus sur les requêtes où elles se positionnaient six mois plus tôt.
Côté utilisateurs, les chiffres sont sans appel. Au-delà de 3 secondes de chargement, plus de la moitié des visiteurs mobiles quittent une page sans attendre. Ce client perdait une partie significative de ses visiteurs avant même qu’ils aient vu un seul produit.
Analyse approfondie de la situation
Audit initial et identification des goulots d’étranglement
Avant de toucher quoi que ce soit, nous avons effectué un audit complet avec GTmetrix et PageSpeed Insights. Les résultats ont confirmé ce que nous suspections, mais avec des chiffres précis qui allaient nous guider dans nos priorités.
Les trois problèmes majeurs identifiés.
Les images non optimisées représentaient 68 % du poids total de la page d’accueil. Certaines photos de produits pesaient entre 3 et 5 Mo chacune, sans aucune compression ni redimensionnement.
Le render-blocking : plusieurs fichiers CSS et JavaScript se chargeaient de façon synchrone dans le head de la page, bloquant l’affichage du contenu visible jusqu’à leur chargement complet. L’utilisateur attendait plusieurs secondes devant un écran blanc avant de voir quoi que ce soit.
L’absence de cache efficace : le plugin de cache avait bien été installé, mais sa configuration par défaut était insuffisante pour ce type de site. La mise en cache des pages, des objets et du navigateur n’était pas activée correctement.
Outils de mesure et indicateurs clés
Nous avons mesuré quatre indicateurs tout au long de l’intervention : le LCP (Largest Contentful Paint, temps d’affichage du contenu principal), le TBT (Total Blocking Time, temps pendant lequel la page est bloquée), le CLS (Cumulative Layout Shift, stabilité visuelle de la page) et le score PageSpeed global sur mobile et desktop. Ces quatre métriques constituent les Core Web Vitals que Google utilise pour évaluer l’expérience utilisateur.
Actions techniques mises en œuvre
Optimisation des images et mise en cache
Premier chantier, le plus impactant : les images. Nous avons traité l’ensemble du catalogue produits avec Imagify, qui compresse et convertit automatiquement les images au format WebP. La compression agressive (avec contrôle visuel pour s’assurer que la qualité reste acceptable) a réduit le poids moyen des images de 78 %. Une photo qui pesait 4,2 Mo en JPEG est passée à 340 Ko en WebP. Sans perte visible de qualité à l’écran.
Nous avons aussi activé le lazy loading natif sur toutes les images hors du champ visible au chargement initial. Les images situées plus bas dans la page ne se chargent que lorsque l’utilisateur scroll jusqu’à elles. Simple, efficace, et ne nécessite aucun plugin supplémentaire depuis WordPress 5.5.
Pour le cache, nous avons remplacé la configuration par défaut par une configuration sur mesure avec WP Rocket, qui gère la mise en cache des pages, la préchargement du cache, la mise en cache des objets via Redis, et la compression GZIP côté serveur.
Minification des fichiers CSS et JS et révision du thème
Deuxième chantier : le render-blocking. Nous avons utilisé WP Rocket pour minifier et combiner les fichiers CSS et JavaScript, et surtout pour différer le chargement des scripts non critiques. Les fichiers JavaScript qui n’étaient pas nécessaires à l’affichage initial de la page ont été chargés en mode asynchrone, après que le contenu visible soit déjà rendu.
Nous avons aussi désactivé les sliders de la page d’accueil, remplacés par une image statique optimisée. Les sliders JavaScript sont connus pour leur impact négatif sur les performances : ils chargent de nombreux scripts et images en même temps, souvent pour un résultat marketing discutable. Le client a accepté ce compromis après avoir vu les chiffres.
Enfin, nous avons désactivé une douzaine de plugins inutilisés ou redondants, dont plusieurs chargeurs de scripts lourds sur chaque page du site alors qu’ils n’étaient utilisés que sur une seule page.
Ajustements sur l’hébergement et configuration serveur
Le dernier levier, et pas des moindres : l’hébergement. L’offre mutualisée d’entrée de gamme atteignait ses limites avec un site e-commerce de cette taille. Nous avons recommandé une migration vers une offre hébergement WordPress managé chez o2switch, avec une instance PHP dédiée et une version PHP à jour (8.2 contre 7.4 sur l’hébergement précédent). La migration a pris deux heures. Le gain de temps de réponse serveur (TTFB) a été immédiat : de 1,8 seconde à 0,4 seconde.
Résultats et enseignements
Amélioration mesurée des temps de chargement
Voici les chiffres avant et après intervention, mesurés avec GTmetrix depuis un serveur européen.
- Temps de chargement total : de 9,8s à 2,3s
- Poids total de la page d’accueil : de 8,4 Mo à 1,2 Mo
- Score PageSpeed Mobile : de 28 à 74
- Score PageSpeed Desktop : de 51 à 91
- LCP : de 7,2s à 1,9s
- TTFB : de 1,8s à 0,4s
Bénéfices pour le SEO et l’expérience utilisateur
Six semaines après l’intervention, le client observe une remontée progressive de ses pages produits dans Google. Le taux de rebond mobile a baissé de 23 points. Et le taux de conversion sur mobile a progressé de façon significative, même si des facteurs multiples entrent en jeu dans ces chiffres et qu’on ne peut pas attribuer tout le gain à la seule optimisation de performance.
Ce qui est certain : un visiteur qui ne voit pas votre site ne peut pas acheter. Réduire le temps de chargement, c’est d’abord s’assurer que vos visiteurs restent assez longtemps pour découvrir ce que vous avez à leur proposer.
Conseils pour reproduire ce succès sur votre site
Les leviers que nous avons activés sur ce site sont applicables à la quasi-totalité des sites WordPress. Par ordre de priorité et d’impact.
- Optimisez vos images en WebP avec un outil comme Imagify ou ShortPixel. C’est souvent le gain le plus immédiat.
- Installez et configurez correctement un plugin de cache. WP Rocket est payant mais efficace. LiteSpeed Cache est gratuit et excellent sur les hébergements compatibles.
- Mettez à jour votre version de PHP. Passer de PHP 7.4 à PHP 8.2 améliore les performances de WordPress de 30 à 50 % selon les configurations.
- Vérifiez votre hébergement. Un site WordPress professionnel a besoin d’un hébergement adapté, pas de l’offre d’appel à 2 € par mois.
Si vous voulez savoir précisément où se situent les goulots d’étranglement de votre site, notre audit de performance WordPress vous livre un diagnostic complet avec un plan d’action priorisé, pour que vous sachiez exactement par où commencer.
