Declaration officielle
Autres déclarations de cette vidéo 4 ▾
- 4:09 La vitesse de chargement est-elle vraiment un critère de ranking ou juste une histoire d'UX ?
- 26:55 Faut-il vraiment utiliser le preload pour toutes vos ressources critiques ?
- 34:14 Le pré-rendu complet de page nuit-il à votre SEO mobile ?
- 36:21 Précharger les ressources améliore-t-il vraiment le référencement ?
Google confirme que le prechargement DNS reduit la latence en resolvant les noms de domaine avant que les ressources ne soient requises. Pour les sites utilisant des CDN, scripts tiers ou polices externes, cette technique peut concretement accelerer le rendu initial. Le gain reste marginal si vos ressources critiques sont deja sur le meme domaine.
Ce qu'il faut comprendre
Qu'est-ce que la resolution DNS et pourquoi ralentit-elle le chargement ?
Chaque fois qu'un navigateur doit charger une ressource depuis un domaine externe, il effectue d'abord une requete DNS pour traduire le nom (exemple.com) en adresse IP. Cette operation, bien qu'invisible, ajoute entre 20 et 120 ms selon la geolocalisation et la qualite du resolveur DNS.
Sur un site moderne qui charge des polices Google Fonts, des scripts analytics, des CDN d'images et des pixels de tracking, chaque domaine externe necessite sa propre resolution DNS. Si cinq domaines tiers sont sollicites, vous cumulez 100 a 600 ms de latence avant meme que le premier octet ne soit telecharge.
Comment fonctionne le DNS prefetching concretement ?
Le navigateur peut recevoir l'instruction de resoudre un domaine de maniere anticipee, avant qu'il ne soit explicitement requis dans le HTML. Cette directive, inseree dans le <head>, declenche la resolution DNS pendant que le navigateur parse le document ou execute JavaScript.
Lorsque la ressource est finalement demandee (une police, un script, une image), le navigateur possede deja l'adresse IP en cache. Le temps de latence DNS est elimine, et la requete HTTP demarre immediatement. Le gain est particulierement visible sur mobile et connexions 3G/4G ou la latence reseau est structurellement elevee.
Cette optimisation s'applique-t-elle a tous les types de sites ?
Le DNS prefetching ne sert que si votre site charge des ressources cross-domain. Un site avec toutes ses ressources sur le meme domaine ou sur un unique CDN bien configure ne gagnera rien. Google le precise implicitement : le gain n'existe que si "la ressource est demandee plus tard".
Les sites e-commerce, medias, et plateformes SaaS chargent frequemment 5 a 15 domaines tiers : analytics, publicitaires, widgets sociaux, CDN video. Pour eux, prefetcher 3 a 5 domaines critiques peut reduire le Largest Contentful Paint (LCP) de 100 a 300 ms selon les conditions reseau.
- Resolution DNS prealable : traduit le nom de domaine en IP avant que le navigateur n'en ait besoin
- Gain mesurable : entre 20 et 120 ms par domaine tiers, cumulative sur mobile
- Domaines cibles prioritaires : polices, CDN, analytics, scripts de suivi
- Sans effet : si toutes les ressources critiques sont sur le domaine principal
- Implementation : balise link rel="dns-prefetch" dans le head HTML
Avis d'un expert SEO
Cette declaration est-elle coherente avec les observations terrain ?
Oui, les mesures WebPageTest et Chrome DevTools confirment que le DNS prefetching reduit effectivement la latence d'initialisation de connexion. Sur des audits real-user data (CrUX), les sites qui prefetchent correctement 3 a 5 domaines tiers affichent des LCP ameliores de 5 a 8 % en moyenne mobile.
Le probleme, c'est que Google ne precise ni le nombre optimal de domaines a prefetcher, ni les cas ou cette directive est contre-productive. Prefetcher 20 domaines genere du trafic DNS inutile et peut saturer le pool de connexions du navigateur, degradant la performance globale.
Quelles sont les limites pratiques de cette technique ?
Le DNS prefetching ne fonctionne que si le navigateur a du temps CPU disponible pour traiter la directive. Sur un mobile milieu de gamme avec JavaScript bloquant, le navigateur peut ignorer ou retarder le prefetch. Le gain est maximal sur les pages avec peu de scripts synchrones et un parsing HTML rapide.
De plus, les navigateurs modernes (Chrome 108+, Safari 16+) appliquent deja du prefetching automatique pour les domaines detectes dans les link preconnect ou reperes dans le HTML. Ajouter manuellement dns-prefetch pour ces domaines peut etre redondant. [A verifier] : Google ne communique aucune donnee sur le taux d'application reelle de ces directives par les crawlers et bots.
Dans quels cas cette optimisation ne sert-elle a rien ?
Si votre site charge toutes ses ressources critiques depuis le meme domaine ou si vous utilisez deja rel="preconnect" (qui inclut DNS + TCP + TLS), ajouter dns-prefetch est inutile. Preconnect est strictement superieur car il complete la negociation TCP/TLS, pas seulement la resolution DNS.
Le dns-prefetch devient pertinent uniquement pour les domaines tiers non critiques que vous ne voulez pas preconnect (car preconnect consomme plus de ressources). Exemple : un pixel de tracking ou un widget social charge en lazy. Dans ce cas, prefetcher le DNS prepare le terrain sans monopoliser une socket TCP.
Impact pratique et recommandations
Quels domaines faut-il concretement prefetcher en priorite ?
Identifie les 3 a 5 domaines tiers qui hebergent des ressources critiques pour le rendu initial. Google Fonts, CDN d'images (Cloudinary, Imgix), scripts analytics (Google Analytics, Hotjar), et APIs de contenu dynamique sont les candidats classiques. Evite de prefetcher des domaines charges apres interaction utilisateur ou en bas de page.
Un site e-commerce type pourrait prefetcher : fonts.googleapis.com, cdn.shopify.com, www.google-analytics.com. Un media : fonts.gstatic.com, video-cdn.example.com, player.vimeo.com. Le choix depend de ta waterfall de chargement reelle, pas d'une liste generique.
Comment implementer le DNS prefetching sans erreur ?
Insere les balises <link rel="dns-prefetch" href="//example.com"> dans le <head>, avant tout script ou stylesheet. Place-les au-dessus des preconnect si tu combines les deux techniques. Le double slash // preserve le protocole (http/https) automatiquement.
Ne prefetche jamais ton propre domaine : c'est deja resolu. Ne prefetche pas des domaines charges en lazy ou apres scroll : tu gaspilles de la bande passante. Teste l'impact avec WebPageTest en mode "First View" pour mesurer le gain reel sur connexion 3G simulee.
Quelles erreurs eviter lors de la mise en place ?
Prefetcher trop de domaines (>7-8) peut saturer le resolveur DNS du navigateur et degrader les performances au lieu de les ameliorer. Chaque prefetch consomme une connexion DNS, et les navigateurs limitent le nombre de resolutions paralleles.
Ne confonds pas dns-prefetch et preconnect. Si un domaine heberge une ressource critique (police, CSS, hero image), utilise rel="preconnect" qui complete la negociation TLS. Dns-prefetch est reserve aux ressources secondaires ou conditionnelles. Enfin, n'oublie pas de monitorer : si ton CDN change de domaine, tes directives deviennent obsoletes.
- Auditer la waterfall WebPageTest pour identifier les 3-5 domaines tiers critiques
- Inserer les balises dns-prefetch dans le head, avant preconnect et scripts
- Limiter a 5-7 domaines maximum pour eviter la saturation du pool DNS
- Privilegier preconnect pour les ressources critiques (polices, CSS), dns-prefetch pour le reste
- Tester l'impact reel sur connexion 3G simulee avec Chrome DevTools ou WebPageTest
- Monitorer regulierement : CDN et domaines tiers changent, les directives doivent suivre
❓ Questions frequentes
Quelle est la difference entre dns-prefetch et preconnect ?
Le DNS prefetching ameliore-t-il le crawl budget Googlebot ?
Combien de domaines peut-on prefetcher sans degrader les performances ?
Le DNS prefetching fonctionne-t-il sur Safari et Firefox ?
Faut-il prefetcher les domaines deja en preconnect ?
🎥 De la même vidéo 4
Autres enseignements SEO extraits de cette même vidéo Google Search Central · durée 42 min · publiée le 25/01/2018
🎥 Voir la vidéo complète sur YouTube →
💬 Commentaires (0)
Soyez le premier à commenter.