Faut-il vraiment éviter les CDN pour vos appels API ?

Pourquoi cette distinction entre ressources statiques et dynamiques ?

Un CDN (Content Delivery Network) déploie vos fichiers sur des serveurs répartis géographiquement pour les rapprocher de l'utilisateur final. Résultat : une image, une feuille CSS ou un fichier JavaScript se charge plus vite depuis un nœud local que depuis votre datacenter principal.

Le problème surgit quand vous passez des appels API dynamiques par ce même CDN. Ces requêtes nécessitent souvent une validation en temps réel, un accès à la base de données, une authentification. Or un CDN introduit une couche intermédiaire qui, au lieu d'accélérer, ajoute de la latence : le nœud CDN doit interroger votre serveur d'origine, puis renvoyer la réponse. Vous cumulez alors deux allers-retours réseau au lieu d'un seul.

En quoi cela affecte-t-il le crawl et l'indexation ?

Googlebot consomme énormément de ressources statiques lors du rendu JavaScript moderne. Si vos bundles JS ou vos CSS mettent 500 ms à se charger, le bot perd du temps — et votre crawl budget s'érode. Un CDN performant améliore directement la vitesse de rendu et la découverte des contenus côté Google.

Mais si vos endpoints API passent par le même CDN et accumulent 200-300 ms de latence supplémentaire, vous dégradez l'expérience utilisateur sans que le bot en tire le moindre bénéfice : il ne crawle pas vos API internes, il crawle le HTML/JSON final rendu. Séparer domaines statique et dynamique clarifie l'architecture et évite des goulots d'étranglement invisibles dans les waterfalls.

Quelle est la bonne pratique recommandée ?

Splitt préconise d'utiliser un domaine dédié pour les appels API, typiquement api.example.com, qui pointe directement vers votre infrastructure backend sans passer par la couche CDN. Les fichiers statiques restent servis via cdn.example.com ou votre CDN principal (Cloudflare, Fastly, CloudFront, Bunny, etc.).

Cette séparation évite que la configuration CDN (cache headers, edge rules, TTL) n'interfère avec les headers de cache sensibles des API : vous ne voulez pas qu'un CDN mette en cache pendant 1 heure une réponse d'authentification ou un panier e-commerce. En isolant les flux, vous gardez un contrôle fin sur chaque type de trafic.

• CDN pour ressources statiques : JavaScript, CSS, images, vidéos, polices, SVG — tout ce qui ne change pas souvent et supporte un cache long.
• Domaine direct pour API : endpoints REST/GraphQL, webhooks, authentification, données utilisateur temps réel.
• Monitoring séparé : APM et RUM distincts pour diagnostiquer les ralentissements côté API sans polluer les métriques frontend.
• CORS et sécurité : le domaine API peut implémenter des headers CORS stricts sans impacter la politique de sécurité du CDN statique.
• Évolutivité : vous pouvez scaler indépendamment votre infrastructure API (autoscaling backend) et votre CDN (bande passante images/vidéos).

Cette déclaration reflète-t-elle vraiment les architectures modernes ?

Oui et non. Splitt énonce une bonne pratique de base, mais la réalité terrain est plus nuancée. Beaucoup de CDN modernes (Cloudflare Workers, Fastly Compute@Edge, AWS CloudFront Functions) permettent de déployer de la logique serverless directement sur les nœuds edge. Dans ce cas, l'API n'ajoute pas forcément de latence : elle s'exécute au plus près de l'utilisateur.

Soyons honnêtes : si vous utilisez un CDN basique avec juste du cache HTTP passif, alors oui, router vos appels API à travers ce CDN est contre-productif. Mais si vous exploitez des edge functions ou du cache conditionnel intelligent, vous pouvez servir certaines réponses API depuis le edge sans retour au backend — et là, le gain de latence est réel. [À vérifier] : Google ne précise pas si cette règle s'applique aussi aux architectures JAMstack avec edge APIs.

Dans quels cas cette séparation devient-elle critique ?

La séparation domaine statique / API prend tout son sens quand vous avez un volume important de requêtes API utilisateur : dashboards temps réel, SaaS, applications mobiles adossées à un backend web, e-commerce avec stock dynamique. Si chaque visite déclenche 10-20 appels API et que chacun subit 150 ms de latence CDN, l'impact cumulé dégrade vos Core Web Vitals (FID, INP).

En revanche, pour un site vitrine WordPress avec 2-3 appels AJAX occasionnels, l'impact reste marginal. Le risque ? Appliquer cette recommandation sans mesurer l'existant — et compliquer l'infrastructure pour un gain de 50 ms sur 3 requêtes par session. Priorisez selon votre profil de trafic réel, pas selon une doctrine abstraite.

Quelles erreurs voit-on fréquemment sur le terrain ?

L'erreur classique : router tout le trafic via un CDN configuré pour un cache agressif, y compris les endpoints qui renvoient du JSON personnalisé. Résultat : des utilisateurs voient des données obsolètes, le cache CDN sert des réponses périmées, et les devs passent des heures à déboguer des Cache-Control mal compris.

Autre piège fréquent : utiliser un sous-domaine CDN (cdn.example.com) pour servir à la fois les assets ET les API, en pensant qu'un header Vary suffira à différencier. Spoiler : ça ne suffit jamais. Les edge nodes appliquent leurs propres règles de purge, et vous finissez avec des incohérences entre régions. Séparer les domaines élimine cette classe de bugs d'un coup.

Comment auditer votre architecture actuelle ?

Commencez par un waterfall analysis en conditions réelles (Chrome DevTools, WebPageTest, SpeedCurve). Filtrez les requêtes par type : identifiez lesquelles passent par le CDN et lesquelles vont directement au backend. Si vous voyez des appels API avec un X-Cache: HIT ou un CF-Cache-Status: HIT, c'est un signal d'alarme — sauf si vous avez explicitement configuré un cache conditionnel sur ces endpoints.

Ensuite, mesurez la latence TTFB (Time To First Byte) de vos API depuis plusieurs géolocalisations (Pingdom, GTmetrix multi-région). Si le TTFB API dépasse 300 ms et que le CDN ajoute 100-150 ms, vous avez un quick win en séparant les domaines. Comparez avant/après migration pour valider le gain réel, pas théorique.

Quelle configuration mettre en place concrètement ?

Créez un sous-domaine dédié api.example.com pointant directement vers votre cluster backend (sans passer par le reverse proxy CDN). Configurez un certificat SSL/TLS distinct si nécessaire — beaucoup de CDN proposent des certificats wildcard, mais pour les API en production, un certificat dédié avec monitoring d'expiration est plus sûr.

Côté frontend, remplacez tous vos fetch('/api/...') par fetch('https://api.example.com/...'). Ajustez les CORS headers sur le backend pour autoriser https://www.example.com et vos autres origines légitimes. Testez en staging avec des outils comme curl -I pour vérifier que les headers Access-Control-Allow-Origin sont présents et corrects.

Quelles métriques surveiller après la migration ?

Suivez l'évolution de votre INP (Interaction to Next Paint) et du FID (First Input Delay) dans la Search Console et dans vos outils RUM (Real User Monitoring). Une réduction de latence API de 100-200 ms peut faire basculer vos pages de « Needs Improvement » à « Good » dans les Core Web Vitals — ce qui a un impact ranking direct sur mobile.

Parallèlement, monitorez le taux d'erreur 5xx côté API : si le CDN masquait des incidents serveur en servant du cache périmé, vous allez maintenant les voir apparaître en clair. C'est un mal pour un bien — mieux vaut corriger les bugs backend que les cacher sous un cache opportuniste. Mettez en place des alertes sur les seuils de latence API (p95, p99) pour détecter les régressions avant qu'elles n'impactent le trafic organique.

• Auditer les waterfalls pour identifier les appels API actuellement routés via CDN
• Créer un sous-domaine dédié api.example.com avec résolution DNS directe vers le backend
• Configurer les CORS headers côté serveur pour autoriser les origines frontend légitimes
• Migrer tous les endpoints API du code frontend vers le nouveau domaine
• Tester en staging avec plusieurs géolocalisations pour valider la réduction de latence
• Monitorer INP, FID et TTFB API dans la Search Console et vos outils RUM post-migration