On a déployé une fiche produit sur un edge node parisien. Résultat : 30 millisecondes de TTFB en local. Sauf que nos clients de Montréal voyaient 800 millisecondes, et Googlebot, depuis Mountain View, ne voyait parfois rien du tout. Le problème n’était pas le code, ni le serveur d’origine. C’était la couche de cache edge, qui servait un contenu différent selon la région et le statut du cold start. Trois jours de debug plus tard, on a compris que l’edge computing n’est pas un accélérateur magique de Core Web Vitals. C’est un outil puissant qui, mal configuré, casse l’indexation plus vite qu’un noindex oublié.
Le mirage des 30 ms de TTFB
La promesse de l’edge, c’est un TTFB sous les 50 ms. Mais ce chiffre est mesuré depuis le nœud edge. Ton visiteur situé loin du point de présence peut voir un TTFB trois à cinq fois supérieur, juste à cause de la latence réseau. Googlebot, qui choisit un nœud selon sa propre logique de crawl, subit la même variance. Si ta stratégie de cache s’appuie uniquement sur le nœud local, tu optimises pour un sous-ensemble d’utilisateurs et tu laisses les autres (et le bot) avec une expérience dégradée. La métrique qui compte pour le SEO, c’est le TTFB perçu par Googlebot, pas celui de ton bureau.
Cache distribué et indexation : le cloaking involontaire
Quand on répartit le cache sur plusieurs régions, on introduit une logique de cohérence qu’on a souvent tendance à sous-estimer. Imaginez une fiche produit avec un prix affiché qui varie selon la devise du pays. Si le cache stocke une version avec le prix en dollars pour la zone Amérique du Nord et une version en euros pour l’Europe, Googlebot peut crawler la version dollars puis, quelques heures plus tard, la version euros. Il voit alors deux contenus différents pour la même URL. Ce n’est pas du cloaking intentionnel, mais les algorithmes de détection peuvent l’interpréter comme tel.
Le problème s’aggrave avec les pages indexées conditionnellement via des paramètres de géolocalisation. Un site qui sert un catalogue de produits différent selon le pays, avec un TTFB optimisé par un cache edge, doit impérativement utiliser des balises canoniques et des hreflang cohérentes avec la version servie. Sinon, vous diluez votre crawl budget sur des variantes que Google considère comme doublons ou, pire, comme tentatives de manipulation.
Dans notre cas, nous avions omis de forcer le cache à ignorer l’en-tête Accept-Language pour la version servie à Googlebot. Résultat : le bot voyait une version en anglais là où nous attendions du français, ce qui a fait chuter l’indexation des pages en français de 40 % en une semaine (vérifié dans la Search Console). La correction a consisté à configurer le middleware edge pour détecter le user-agent Googlebot et lui servir une version neutre, identique dans toutes les régions, avec une redirection canonique vers l’URL sans paramètre de langue. Le TTFB a légèrement augmenté, mais l’indexation est revenue à la normale.
Retenez une règle : si votre cache edge différencie le contenu par localisation, testez systématiquement ce que voit Googlebot depuis un point de terminaison hors de votre zone géographique. Utilisez un service de monitoring qui interroge plusieurs régions avec un header User-Agent: Googlebot. L’edge doit être un accélérateur de performance, pas un générateur de contenu dupliqué. Pour approfondir le lien entre TTFB et autres signaux de classement, nous avons détaillé les mécaniques dans notre analyse des signaux Core Web Vitals.
Hydratation partielle et edge functions : l’INP que vous ne voyez pas venir
Les fonctions edge permettent de générer du HTML dynamiquement au plus près de l’utilisateur. Avec des frameworks comme Next.js, on peut exécuter du code côté serveur sur un edge node et envoyer un flux HTML au navigateur. L’hydratation partielle promet de réduire le JavaScript envoyé au client. Le hic, c’est que l’état initial reconstruit côté client doit correspondre exactement à ce que le serveur a rendu. Si une fonction edge modifie la structure du DOM selon des conditions asynchrones (par exemple, une promo locale chargée via une API), et que le bundle client ne reproduit pas ces conditions à l’identique, l’hydratation échoue silencieusement. Le résultat : des événements click qui ne répondent pas pendant plusieurs centaines de millisecondes, un INP qui explose.
Nous avons mesuré l’impact sur une landing page dotée d’un compte à rebours promotionnel calculé côté edge. L’INP au premier clic passait de 80 ms en laboratoire à plus de 400 ms chez les utilisateurs réels, parce que l’état du compteur différait entre le HTML initial et le JavaScript client. La solution n’est pas de supprimer la fonction edge, mais de garantir une source de vérité unique. Pour cela, nous utilisons un store global géré avec Zustand, qui sérialise l’état complet et le transmet au client avant hydratation. L’approche est détaillée dans notre retour sur la gestion d’état avec Zustand. L’essentiel : ne laissez jamais l’edge écrire du HTML sans que le client sache exactement comment le réconcilier.
Cold start des fonctions edge : un impact sur l’INP que même Lighthouse ne capture pas
Une fonction edge inactive depuis quelques minutes doit redémarrer. Ce cold start peut ajouter 200 à 500 ms au temps de réponse. Lighthouse, qui mesure le premier chargement à froid, le voit. Mais si votre utilisateur navigue sur le site et clique sur un bouton qui déclenche une autre fonction edge après une période d’inactivité, ce délai s’applique au moment du clic. Il tombe pile dans la fenêtre de mesure de l’INP, alors que vos audits Lighthouse sur le laboratoire sont déjà passés.
Nous avons identifié ce comportement en croisant les données CrUX avec les logs de latence des fonctions edge. Sur un site e-commerce, l’interaction « Ajouter au panier » qui appelait une fonction edge pour vérifier le stock en temps réel subissait un cold start dans environ 15 % des cas, avec des pointes à 600 ms. Résultat : un INP mobile à 350 ms, alors que le site était classé « bon » sur Lighthouse. La correction a été de transformer cette fonction en appel à un worker toujours chaud, dédié à une région, et de conserver la logique edge uniquement pour le rendu des pages, pas pour les interactions.
Avant de généraliser l’edge à tout votre site, instrumentez vos fonctions edge avec des journaux de cold start et croisez-les avec les métriques CrUX. Si vous ne mesurez que le TTFB, vous passez à côté du vrai problème.
Ce que nous avons mis sur l’edge et ce que nous avons gardé centralisé
Après ces mésaventures, nous avons établi une règle simple. Sur l’edge : le rendu des fiches produits et des pages de catégorie, parce que le contenu change peu et que le cache peut être purgé de manière atomique. Pas de contenu conditionnel par région, sauf pour les langues, avec cache neutre pour Googlebot. En centralisé : le tunnel de commande et la gestion du panier, pour éviter tout risque de divergence d’état entre les nœuds. Le checkout reste sur un serveur unique, avec un CDN classique pour les assets.
Pour les développeurs qui codent ces logiques, la capacité à tester localement le comportement des fonctions edge est cruciale. Nous utilisons un proxy qui simule la latence et le cold start, et nous avons comparé deux environnements : l’un basé sur Cursor avec des extensions de simulation réseau, l’autre avec un outil d’analyse de code intégré. Les deux approches ont leurs forces, comme nous le détaillons dans le comparatif Claude Code vs Cursor IDE. L’important est de ne pas se fier au seul test unitaire, mais de simuler les conditions réelles d’un edge node distant avant de déployer.
Le piège serait de vouloir tout migrer sur l’edge pour cocher une case « performance ». Chaque fonction déplacée doit justifier son gain de TTFB face au risque de désynchronisation. Nous avons constaté que sur certaines pages, l’edge ne réduisait pas le LCP, car le principal goulet d’étranglement était une image non optimisée, pas le temps de réponse du serveur. Optimiser l’edge sans traiter le lazy-loading des images, c’est réduire le TTFB tout en laissant le LCP à la traîne.
Questions fréquentes
Est-ce que l’edge computing est indispensable pour passer les Core Web Vitals ?
Non. Un bon TTFB peut être obtenu avec un CDN classique et du cache HTTP bien configuré. L’edge devient pertinent quand vous avez besoin de logique serveur proche de l’utilisateur (rendu dynamique, personnalisation légère). Mais ne migrez pas vers l’edge uniquement pour le score Lighthouse ; concentrez-vous d’abord sur les optimisations de rendu et de chargement des ressources.
Comment vérifier ce que voit Googlebot sur un site déployé en edge ?
Utilisez un outil de test d’URL de la Search Console, en le couplant à un service de monitoring externe qui interroge plusieurs régions avec un header User-Agent: Googlebot. Vous pourrez ainsi comparer le HTML servi depuis l’Amérique du Nord, l’Europe et l’Asie, et détecter les divergences. Certains fournisseurs cloud proposent des endpoints dédiés pour cette vérification.
Faut-il servir les mêmes contenus aux utilisateurs et à Googlebot sur l’edge ?
Oui, dans la mesure où le contenu factuel (produit, prix, disponibilité) doit être identique. La seule exception acceptable concerne les éléments strictement liés à la personnalisation non indexable (panier, favoris), à condition qu’ils ne modifient pas le contenu principal de la page. La règle d’or : si un élément influence l’intention de la page, il doit être le même pour le bot.
