Symptôme. Un développeur d’une agence partenaire nous a contactés, un peu désemparé : son environnement local, sur un thème WordPress qu’il venait de livrer, affichait un score Lighthouse de 98 sur la page produit type, avec un LCP annoncé à 1,1 seconde. Une fois le site déployé en production, la Search Console remontait la même page en zone rouge, avec un LCP réel dépassant 4 secondes pour une bonne partie des visiteurs mobiles. Le code n’avait pourtant pas changé entre les deux environnements.
Ce type d’écart revient assez souvent pour mériter une méthode de diagnostic systématique plutôt qu’une inspection au hasard. Voici comment le cas a été résolu, étape par étape.
Diagnostic : lister ce qui diffère entre les deux environnements
Avant de chercher un bug, il fallait établir la liste de tout ce qui n’était pas identique entre le poste local et le serveur de production. Sur ce projet, l’inventaire a révélé quatre différences majeures, aucune ne concernant le code applicatif :
- Le poste local exécutait WordPress avec Local (by Flywheel), sur un processeur récent et sans autre charge concurrente.
- La production tournait sur un hébergement mutualisé, avec plusieurs sites sur la même machine.
- Aucun CDN n’était configuré en production au moment du test, contrairement à une hypothèse initiale du client.
- La base d’images locale utilisait des fichiers optimisés manuellement par le développeur ; la production recevait les images telles qu’importées par le client, sans compression systématique.
Premier suspect : le temps de réponse serveur
Le test curl le plus basique a suffi à confirmer la première piste : curl -w "%{time_starttransfer}\n" -o /dev/null -s https://exemple.fr/produit/gant-hiver/ renvoyait 0,08 seconde en local contre 1,9 seconde en production. L’hébergement mutualisé, partagé avec d’autres sites, ne disposait ni d’OPcache correctement configuré, ni d’un cache de page. Chaque requête recalculait entièrement le rendu PHP, boucle WP_Query comprise, sans aucune mise en cache intermédiaire.
Deuxième suspect : le poids des images
Le second écart concernait les images. En local, le développeur travaillait avec des fichiers déjà passés dans un compresseur avant l’import. En production, le client important lui-même ses photos de produits directement depuis son appareil photo, sans compression, et le plugin d’optimisation d’image installé sur le site n’avait jamais été activé après son installation. Résultat : des images de plus de 2 Mo servies telles quelles pour l’élément LCP.
Comment vérifier ce point rapidement
La commande WP-CLI wp media list --fields=ID,post_title,guid --format=csv combinée à une vérification du poids des fichiers correspondants sur le disque a permis de confirmer que l’essentiel des images produit dépassait le mégaoctet, largement au-delà de ce que Lighthouse local avait jamais eu à traiter pendant les tests du développeur.
Troisième suspect : l’absence de CDN et de mise en cache des ressources statiques
Sans CDN, chaque visiteur, quelle que soit sa localisation, redemandait les ressources statiques directement au serveur d’origine, avec des temps de latence variables selon la distance géographique. Le test Lighthouse local, exécuté sur la même machine que le serveur, ne pouvait par construction jamais révéler ce facteur, puisque la latence réseau y était nulle.
Correctif appliqué
- Configuration d’OPcache et d’un cache de page complet côté hébergeur.
- Activation du plugin d’optimisation d’image déjà présent, avec reconversion en masse des médias existants via
wp media regenerate. - Mise en place d’un CDN devant les ressources statiques et les images.
Après ces trois correctifs, le LCP en production est descendu à 2,3 secondes, encore loin du 1,1 seconde local mais désormais dans la zone acceptable pour la majorité des visiteurs.
Prévention pour la prochaine fois
La règle qu’on applique maintenant systématiquement : ne jamais valider un score de performance mesuré ailleurs qu’en production, ou à défaut sur un clone qui reproduit fidèlement l’hébergement, la charge et les vrais médias du client.
Un environnement local reste utile pour le développement au quotidien, mais il ne remplace jamais une mesure prise dans les conditions réelles que rencontreront les visiteurs, avec la vraie charge serveur, les vrais fichiers et la vraie distance réseau.
