# CDN OVHcloud et SEO : ce que la latence serveur change vraiment sur le LCP

> Un LCP correct à Paris et catastrophique à Marseille : retour sur la mise en place d'un CDN devant un hébergement WordPress français, mesures avant/après à l'appui.

- Auteur : WordPress Développement
- Publié le : 2024-01-13
- Mis à jour le : 2024-01-13
- Catégorie : SEO & GEO
- URL : https://www.wpmoderne.fr/seo/cdn-ovhcloud-seo-latence-lcp/

## L’essentiel

- Le TTFB pèse directement sur le LCP, pas seulement le poids des images
- Un CDN ne corrige pas un mauvais code, il réduit la distance
- Les mesures doivent couvrir plusieurs régions, pas un seul poste de test

620 millisecondes de LCP en moins sur la médiane mobile, mesurées sur quatre semaines avant et après la mise en place d'un CDN devant un hébergement WordPress situé à Roubaix. C'est l'écart constaté sur un site consulté par une audience répartie sur toute la France et une partie de l'Europe, avec des pics de latence particulièrement marqués pour les visiteurs situés loin du datacenter d'origine.

Le cas est intéressant parce qu'il illustre un phénomène souvent sous-estimé : un site peut afficher un excellent score Lighthouse depuis un poste de test parisien, tout en offrant une expérience nettement dégradée pour une partie réelle de son audience. La donnée de terrain, remontée par CrUX, racontait une histoire différente du rapport de laboratoire.

## Le diagnostic initial : un LCP qui varie selon la géographie

Le rapport d'expérience utilisateur Chrome montrait un LCP correct en p75 pour les visiteurs proches du nord de la France, et un LCP nettement dégradé, parfois au-delà de 4 secondes, pour les visiteurs situés dans le sud ou à l'étranger francophone. Aucune différence de poids de page entre ces deux groupes : la même image mise en avant, le même thème, la même configuration de cache. La seule variable qui changeait était la distance physique au serveur d'origine, et donc le temps de premier octet.

Un test avec l'outil `curl` en mesurant le `time_starttransfer` depuis plusieurs points géographiques a confirmé l'hypothèse : le TTFB dépassait 400 ms pour les requêtes les plus éloignées, contre 90 ms pour les requêtes locales. Sur un LCP déjà tendu, cet écart de TTFB se répercute presque intégralement sur le temps d'affichage de l'élément principal, puisque le navigateur ne peut commencer à télécharger l'image qu'après avoir reçu la première réponse du serveur.

## Ce que le cache de page ne résout pas seul

> L'essentiel à retenir : Le TTFB pèse directement sur le LCP, pas seulement le poids des images ; Un CDN ne corrige pas un mauvais code, il réduit la distance ; Les mesures doivent couvrir plusieurs régions, pas un seul poste de test

Le site utilisait déjà un cache de page complet, ce qui limitait le temps de génération PHP à quelques millisecondes. Le problème ne venait donc pas de WordPress lui-même, mais de la distance réseau entre le visiteur et le point de sortie du serveur. Un cache de page réduit le temps de traitement, pas le temps de transport, et ces deux notions sont trop souvent confondues dans les diagnostics de performance.

La solution retenue a consisté à placer un CDN en frontal, avec mise en cache des pages HTML complètes au niveau des points de présence les plus proches de chaque visiteur, en plus des assets statiques déjà distribués. La configuration a demandé une attention particulière sur la purge de cache lors des publications, pour éviter de servir une version obsolète pendant plusieurs minutes après une mise à jour de contenu.

### Points de vigilance sur la configuration

- Exclure les pages avec contenu personnalisé (panier, compte utilisateur) du cache CDN
- Vérifier que les en-têtes `Vary` sont correctement transmis pour ne pas mélanger versions desktop et mobile
- Automatiser la purge du CDN via un webhook déclenché sur `save_post`, plutôt que de dépendre d'une purge manuelle
- Conserver un accès direct de secours à l'origine pour le diagnostic en cas de comportement anormal du CDN

## Les mesures avant/après

Sur la période comparée, les mesures CrUX en p75 mobile sont passées d'un LCP proche de 3,8 secondes à environ 3,2 secondes en moyenne nationale, avec un écart-type nettement resserré entre régions. Les visiteurs les plus éloignés du datacenter d'origine ont bénéficié du gain le plus net, ce qui confirme que l'essentiel de l'amélioration provenait bien de la réduction de la distance réseau et non d'un changement de code.

> Un CDN ne rend pas un site rapide, il rend une bonne performance disponible partout où elle était déjà atteignable localement.

Il faut noter une limite honnête : sur les postes de test situés à proximité immédiate du datacenter d'origine, le gain a été quasiment nul, voire légèrement négatif du fait du saut réseau supplémentaire introduit par le point de présence du CDN. Le bénéfice est donc directement proportionnel à la dispersion géographique réelle de l'audience, une donnée à vérifier avant d'investir dans cette solution plutôt que de la présenter comme universellement bénéfique.

## Notre verdict

Le choix de l'hébergeur d'origine n'a pas été remis en cause dans ce projet : l'infrastructure sous-jacente fonctionnait correctement, le problème était purement géographique. Pour un site dont l'audience reste concentrée près du serveur d'origine, un CDN apportera peu. Pour un site à audience nationale ou internationale, la mise en place d'un CDN devant un hébergement WordPress reste l'un des leviers les plus fiables pour uniformiser le LCP mesuré en conditions réelles, à condition de traiter la purge de cache comme une brique aussi critique que la mise en cache elle-même.