Faut-il vraiment limiter le nombre de domaines pour charger vos fichiers JavaScript ?

Declaration officielle

Si les fichiers JavaScript sont chargés depuis différents noms de domaine, il peut y avoir une surcharge de lookup DNS par domaine. Un nombre excessif peut ralentir la première visite d'un utilisateur sur votre site.

🎥 Vidéo source

Extrait d'une vidéo Google Search Central

💬 EN 📅 17/05/2022 ✂ 12 déclarations

Voir sur YouTube →

✂ Autres déclarations de cette vidéo 11 ▾

□ Le JavaScript est-il vraiment un frein aux performances SEO de votre site ?
□ Pourquoi trop de fichiers JavaScript nuisent-ils à vos performances SEO ?
□ PageSpeed Insights révèle-t-il vraiment les problèmes JavaScript critiques pour votre SEO ?
□ Faut-il vraiment regrouper ses fichiers JavaScript pour améliorer son SEO ?
□ HTTP/2 rend-il obsolète la concaténation de fichiers JavaScript pour le SEO ?
□ Comment éliminer le JavaScript inefficace qui plombe vos Core Web Vitals ?
□ Les passive listeners peuvent-ils vraiment booster vos Core Web Vitals ?
□ Pourquoi le JavaScript non utilisé plombe-t-il vos Core Web Vitals même s'il n'est jamais exécuté ?
□ Le tree shaking JavaScript est-il vraiment efficace pour améliorer les performances SEO ?
□ Faut-il vraiment compresser tous vos fichiers JavaScript pour améliorer votre SEO ?
□ Pourquoi Google insiste-t-il sur les en-têtes de cache pour JavaScript ?

Ce qu'il faut comprendre

Pourquoi les lookups DNS ralentissent-ils spécifiquement la première visite ?

Lors d'une première visite, le navigateur n'a aucun cache DNS. Il doit donc résoudre chaque nom de domaine avant de télécharger quoi que ce soit. Ce processus ajoute entre 20 et 120 ms par domaine selon la qualité de la connexion et la localisation géographique.

Sur une visite de retour, le cache DNS du système d'exploitation ou du navigateur court-circuite cette étape. Le problème disparaît — temporairement. Mais la première impression compte : c'est elle qui détermine si l'utilisateur reste ou rebondit.

Qu'est-ce qu'un lookup DNS exactement et pourquoi c'est incompressible ?

Un lookup DNS traduit un nom de domaine (ex: cdn.example.com) en adresse IP. Cette opération nécessite une requête réseau vers un serveur DNS — souvent plusieurs si le résolveur doit remonter la chaîne hiérarchique.

Contrairement à d'autres optimisations (compression, minification), vous ne pouvez pas accélérer un lookup DNS côté serveur. Vous ne contrôlez que deux leviers : réduire le nombre de domaines ou pré-résoudre avec dns-prefetch/preconnect.

Combien de domaines deviennent « excessifs » selon Google ?

Google ne donne pas de chiffre précis — et c'est délibéré. Le seuil acceptable dépend de votre contexte : type de site, audience cible, connexion mobile vs desktop.

En pratique, au-delà de 5-6 domaines tiers pour le JS critique, vous entrez en zone rouge. Si vous chargez Analytics, Tag Manager, un player vidéo, une pub programmatique, des polices et un CDN distinct pour vos scripts… vous êtes déjà trop fragmenté.

Chaque domaine = latence incompressible de 20-120 ms à la première visite
Le cache DNS résout le problème pour les visites ultérieures, mais pas pour les nouveaux visiteurs
Google pointe le doigt sur la dispersion des sources, pas uniquement le volume de JS
Aucun seuil chiffré officiel — mais au-delà de 5-6 domaines tiers, l'impact devient mesurable
Les techniques de préconnexion (dns-prefetch, preconnect) atténuent le problème sans le résoudre complètement

Avis d'un expert SEO

Cette recommandation est-elle alignée avec les pratiques terrain observées ?

Oui, totalement. On observe régulièrement des sites avec 10+ domaines tiers rien que pour le JS : CDN principal, CDN de backup, outils analytics, chatbots, pixels publicitaires, widgets sociaux… Chacun pris isolément semble inoffensif. C'est l'accumulation qui tue.

Les audits PageSpeed Insights pointent d'ailleurs souvent « Reduce initial server response time » et « Avoid multiple page redirects » — mais rarement la fragmentation DNS de manière explicite. Pourtant, elle contribue directement au Time to First Byte (TTFB) perçu côté client.

Quelles nuances faut-il apporter à cette déclaration ?

Google ne précise pas si cette recommandation s'applique uniformément au JS critique vs. non-critique. Or, un script chargé en async ou defer après le First Contentful Paint (FCP) a beaucoup moins d'impact qu'un blocking script dans le <head>.

Autre point : les Resource Hints (dns-prefetch, preconnect) peuvent compenser partiellement le problème. Mais ils ne font que décaler la latence — si vous abusez des hints, vous saturez la file de connexions simultanées du navigateur. [À vérifier] : est-ce que Google considère qu'un domaine avec preconnect compte autant qu'un domaine sans optimisation ? Aucune donnée publiée là-dessus.

Dans quels cas cette règle ne s'applique-t-elle pas vraiment ?

Si votre audience revient massivement (ex: SaaS, plateforme membre), le cache DNS fait son boulot et le problème s'estompe. Vous pouvez vous permettre plus de domaines tiers si 80% de vos sessions sont des visites de retour.

Autre exception : certains CDN très distribués (Cloudflare, Fastly) avec une latence DNS < 10 ms. Là, ajouter un domaine coûte moins cher qu'un redirect HTTP/2 mal configuré. Mais c'est rare — et ça reste un pari sur l'infrastructure tierce.

Attention : Google ne dit pas « éliminez tous les domaines tiers ». Il dit « limitez le nombre ». Si vous centralisez tout sur un CDN unique mais que ce CDN est lent ou mal configuré, vous perdez au change. L'arbitrage n'est pas binaire.

Impact pratique et recommandations

Que faut-il faire concrètement pour réduire les lookups DNS ?

Premier réflexe : auditer vos domaines tiers. Ouvrez la DevTools (onglet Network), rechargez la page en mode navigation privée (pour simuler une première visite), et notez tous les domaines sollicités avant le First Contentful Paint.

Ensuite, posez-vous la question : ce script est-il vraiment critique ? Beaucoup de widgets sociaux, chats en ligne ou pixels analytics peuvent être chargés en async ou carrément en lazy après interaction utilisateur. Déplacer 3-4 domaines en différé suffit souvent à récupérer 100-200 ms au chargement initial.

Si vous ne pouvez pas éliminer un domaine tiers, préconnectez-vous intelligemment avec <link rel="preconnect" href="https://cdn.example.com">. Mais attention : pas plus de 3-4 preconnect simultanés, sinon vous saturez le budget de connexions HTTP/2 du navigateur.

Quelles erreurs éviter absolument ?

Ne regroupez pas aveuglément tous vos scripts sur un seul domaine si cela casse le sharding HTTP/1.1 — mais soyons honnêtes, en 2025, HTTP/2 est partout. Le sharding n'a plus aucun intérêt.

Autre piège : héberger vos scripts critiques sur un CDN tiers ultra-rapide… mais avec un certificat SSL mal configuré ou une chaîne de redirections. Vous gagnez 20 ms de DNS, vous perdez 150 ms de handshake TLS. Priorisez la cohérence du chemin critique.

Comment vérifier que mon site est conforme aux recommandations Google ?

Utilisez WebPageTest avec le paramètre « First View Only » pour simuler une visite sans cache DNS. Regardez la waterfall : chaque barre verte (DNS lookup) avant le FCP est un candidat à l'optimisation.

Google Search Console ne remontera jamais ce problème directement — c'est un angle mort. Mais PageSpeed Insights peut signaler « Reduce initial server response time » si vos lookups DNS plombent le TTFB apparent.

Auditer tous les domaines tiers sollicités avant le FCP (DevTools, onglet Network)
Déplacer les scripts non-critiques en async, defer ou lazy load post-interaction
Limiter les preconnect à 3-4 domaines maximum pour ne pas saturer le budget de connexions
Privilégier un CDN unique bien configuré plutôt qu'une dispersion sur 5-6 fournisseurs
Tester en « First View Only » sur WebPageTest pour mesurer l'impact réel des lookups DNS
Vérifier que le handshake TLS et les redirections n'annulent pas les gains DNS

Réduire le nombre de lookups DNS avant le FCP est un levier sous-estimé — mais complexe à optimiser sans casser des dépendances tierces (analytics, ads, widgets). Si vous gérez un site e-commerce ou éditorial avec de nombreux partenaires techniques, l'arbitrage entre performance et fonctionnalités nécessite une expertise pointue. Faire appel à une agence SEO spécialisée dans l'optimisation technique permet de cartographier ces dépendances, prioriser les gains réels et éviter les régressions — plutôt que de bidouiller des preconnect au hasard.

❓ Questions frequentes

Est-ce que dns-prefetch et preconnect éliminent complètement le problème des lookups DNS ?

Non, ils réduisent la latence en démarrant la résolution DNS en avance, mais ne l'annulent pas. De plus, trop de preconnect simultanés saturent le budget de connexions HTTP/2 du navigateur.

Combien de domaines tiers sont acceptables pour le JavaScript critique ?

Google ne donne pas de chiffre officiel, mais en pratique, au-delà de 5-6 domaines sollicités avant le First Contentful Paint, l'impact devient mesurable sur la première visite.

Les scripts chargés en async ou defer sont-ils concernés par cette recommandation ?

Moins que les scripts bloquants, car ils n'impactent pas le chemin critique. Mais si un script async nécessite un lookup DNS supplémentaire, il ajoute quand même de la latence globale.

Faut-il abandonner les CDN tiers et tout héberger sur son propre domaine ?

Pas nécessairement. Un CDN bien configuré peut offrir une latence DNS et TLS inférieure à votre serveur principal. L'enjeu est de limiter le nombre de domaines distincts, pas de tout rapatrier.

Comment mesurer précisément l'impact des lookups DNS sur mon site ?

Utilisez WebPageTest en mode 'First View Only' pour simuler une visite sans cache DNS. La waterfall affichera chaque lookup DNS (barre verte) et son impact sur le Time to First Byte perçu.

🎥 De la même vidéo 11

Autres enseignements SEO extraits de cette même vidéo Google Search Central · publiée le 17/05/2022

🎥 Voir la vidéo complète sur YouTube →