Official statement
Other statements from this video 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 confirms that DNS preloading reduces latency by resolving domain names before resources are needed. For sites using CDNs, third-party scripts, or external fonts, this technique can significantly speed up initial rendering. The benefit remains marginal if your critical resources are already on the same domain.
What you need to understand
What is DNS resolution and why does it slow down loading?
Each time a browser needs to load a resource from an external domain, it first performs a DNS request to translate the name (example.com) into an IP address. This operation, although invisible, adds between 20 and 120 ms depending on geolocation and the quality of the DNS resolver.
On a modern site that loads Google Fonts, analytics scripts, image CDNs, and tracking pixels, each external domain requires its own DNS resolution. If five third-party domains are requested, you accumulate 100 to 600 ms of latency before the first byte is even downloaded.
How does DNS prefetching work in practice?
The browser can be instructed to resolve a domain in advance before it is explicitly required in the HTML. This directive, inserted in the <head>, triggers the DNS resolution while the browser parses the document or runs JavaScript.
When the resource is finally requested (a font, a script, an image), the browser already has the IP address cached. The DNS latency is eliminated, and the HTTP request starts immediately. The gain is particularly noticeable on mobile and 3G/4G connections where network latency is structurally high.
Does this optimization apply to all types of sites?
DNS prefetching is only useful if your site loads cross-domain resources. A site with all its resources on the same domain or a single well-configured CDN will not gain anything. Google implicitly specifies this: the benefit only exists if "the resource is requested later."
E-commerce sites, media, and SaaS platforms frequently load 5 to 15 third-party domains: analytics, advertising, social widgets, video CDNs. For them, prefetching 3 to 5 critical domains can reduce the Largest Contentful Paint (LCP) by 100 to 300 ms depending on network conditions.
- Pre-emptive DNS resolution: translates the domain name into IP before the browser needs it
- Measurable gain: between 20 and 120 ms per third-party domain, cumulative on mobile
- Priority target domains: fonts, CDNs, analytics, tracking scripts
- No effect: if all critical resources are on the main domain
- Implementation: link rel="dns-prefetch" tag in the HTML head
SEO Expert opinion
Is this statement consistent with real-world observations?
Yes, WebPageTest and Chrome DevTools measurements confirm that DNS prefetching does effectively reduce connection initialization latency. In real-user data audits (CrUX), sites that correctly prefetch 3 to 5 third-party domains show LCP improvements of 5 to 8 % on average for mobile.
The problem is that Google does not specify the optimal number of domains to prefetch or the cases where this directive is counterproductive. Prefetching 20 domains generates unnecessary DNS traffic and can saturate the browser's connection pool, degrading overall performance.
What are the practical limits of this technique?
DNS prefetching only works if the browser has available CPU time to process the directive. On a mid-range mobile with blocking JavaScript, the browser may ignore or delay the prefetch. The gain is maximized on pages with few synchronous scripts and rapid HTML parsing.
Moreover, modern browsers (Chrome 108+, Safari 16+) already apply automatic prefetching for domains detected in link preconnect or identified in the HTML. Manually adding dns-prefetch for these domains can be redundant. [To be verified]: Google provides no data on the actual application rate of these directives by crawlers and bots.
In what cases is this optimization useless?
If your site loads all its critical resources from the same domain or if you already use rel="preconnect" (which includes DNS + TCP + TLS), adding dns-prefetch is unnecessary. Preconnect is strictly superior as it completes TCP/TLS negotiation, not just DNS resolution.
The dns-prefetch becomes relevant only for non-critical third-party domains that you do not want to preconnect (as preconnect consumes more resources). For example: a tracking pixel or a social widget loaded lazily. In this case, prefetching the DNS prepares the ground without monopolizing a TCP socket.
Practical impact and recommendations
Which domains should you prioritize for prefetching?
Identify the 3 to 5 third-party domains hosting critical resources for initial rendering. Google Fonts, image CDNs (Cloudinary, Imgix), analytics scripts (Google Analytics, Hotjar), and APIs for dynamic content are classic candidates. Avoid prefetching domains that load after user interaction or at the bottom of the page.
A typical e-commerce site might prefetch: fonts.googleapis.com, cdn.shopify.com, www.google-analytics.com. A media site could include: fonts.gstatic.com, video-cdn.example.com, player.vimeo.com. The choice depends on your actual loading waterfall, not a generic list.
How can you implement DNS prefetching without errors?
Insert the <link rel="dns-prefetch" href="//example.com"> tags in the <head>, before any script or stylesheet. Place them above preconnect if you combine both techniques. The double slash // automatically preserves the protocol (http/https).
Never prefetch your own domain: it's already resolved. Don't prefetch domains loaded lazily or after scrolling: you waste bandwidth. Test the impact using WebPageTest in "First View" mode to measure the real gain on simulated 3G connection.
What errors should you avoid during implementation?
Prefetching too many domains (>7-8) can saturate the browser's DNS resolver and degrade performance instead of improving it. Every prefetch consumes a DNS connection, and browsers limit the number of concurrent resolutions.
Don't confuse dns-prefetch with preconnect. If a domain hosts a critical resource (font, CSS, hero image), use rel="preconnect" which completes TLS negotiation. Dns-prefetch is reserved for secondary or conditional resources. Finally, remember to monitor: if your CDN changes domains, your directives become obsolete.
- Audit the WebPageTest waterfall to identify the 3-5 critical third-party domains
- Insert dns-prefetch tags in the head, before preconnect and scripts
- Limit to a maximum of 5-7 domains to avoid saturating the DNS pool
- Prioritize preconnect for critical resources (fonts, CSS), dns-prefetch for the rest
- Test the real impact on a simulated 3G connection with Chrome DevTools or WebPageTest
- Regularly monitor: CDNs and third-party domains change, directives must follow
❓ Frequently Asked Questions
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 ?
🎥 From the same video 4
Other SEO insights extracted from this same Google Search Central video · duration 42 min · published on 25/01/2018
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.