Preconnect, preload, dns-prefetch: preparing connections before the browser needs them

A landing page that loads a Google Fonts typeface, a chat widget, a YouTube video as a hero background, and a Stripe payment script is, most of the time, calling four different domains besides its own. For each one, before it can even download a single useful byte, the browser has to resolve the domain name (DNS), open a TCP connection, then negotiate TLS encryption if the site runs on HTTPS — which is essentially always the case today. Those three steps combined can add up to several hundred milliseconds on a mobile connection, and they repeat, silently, for every new domain discovered as the page loads. Resource hints (dns-prefetch, preconnect, preload) let you trigger some or all of that work before the browser explicitly needs it.

Three hints, three levels of anticipation

<link rel="dns-prefetch"> only resolves the domain name ahead of time — the cheapest of the three, a few tens of milliseconds saved, with no notable side effect. You can apply it broadly, across every known third-party domain on the page, with little risk. <link rel="preconnect"> goes further: DNS, TCP handshake, and TLS negotiation, all at once. The gain is bigger — you remove up to two full network round trips from the critical path — but so is the cost: the connection stays open, using browser memory and CPU, and if no request uses it within the next few seconds, all that work is wasted. <link rel="preload"> is different in nature: it doesn't prepare a connection, it downloads a specific resource (a font file, an image, a script) at high priority, before the browser would otherwise discover it in the HTML or CSS.

What the research says about the loading critical path

A landmark study by Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and David Wetherall, presented at the USENIX NSDI conference in 2013, built WProf, a profiler that reconstructs a page load's full dependency graph — networking, HTML parsing, JavaScript execution, layout, rendering — to pinpoint exactly what sits on the critical path: the steps that, if made faster, would actually speed up the final render. Across 350 web pages, the authors show that establishing network connections (DNS, TCP, TLS) occupies a meaningful share of that critical path, alongside synchronous JavaScript execution that blocks HTML parsing (Wang, Balasubramanian, Krishnamurthy & Wetherall, 2013). In other words: removing a connection from the critical path by establishing it ahead of time isn't a cosmetic micro-optimization — it acts directly on one of the factors that determine actual render time, and on a landing page, that means LCP.

Where it actually matters on a landing page

• A Google Fonts typeface that isn't self-hosted — every visit triggers a connection to fonts.googleapis.com, then fonts.gstatic.com; a preconnect to both domains shortens the delay before the font file starts downloading (self-hosting, which we cover in our article on Google Fonts and GDPR, removes the problem entirely).
• An embedded Stripe payment button or widget — the payment script loads from js.stripe.com; a discreet dns-prefetch spares the visitor a DNS lookup delay right when they click the purchase button.
• A YouTube or Vimeo video used as a hero background — several third-party domains (player, video CDN, tracking) get added at once; here it's often better to defer loading the iframe itself rather than piling on preconnects, as we cover in our article on loading speed.
• A live chat widget — Crisp, Intercom, or similar tools load their own script from a separate domain; worth preconnecting if the widget needs to appear quickly, as we cover in our article on live chat.
• The Meta or GA4 tracking pixel — these scripts almost never need a preconnect: they don't block anything visible, and deferring their execution has no impact on LCP, as we detail for the Meta pixel and GA4 tracking.

The most common mistake: preconnecting to everything

A preconnect connection stays open for several seconds waiting to be used; if it never is, the browser kept it open for nothing, at the cost of some memory and CPU — and most browsers effectively cap how many prepared connections can run at once, which means adding a fifth or sixth preconnect can simply push out the two or three that actually mattered. PageSpeed Insights explicitly flags unused preconnect hints in its "Preconnect to required origins" audit: if it shows up as a warning, that's the signal to trim the list rather than pad it further. The practical rule: two to four preconnect hints at most, reserved for domains that genuinely matter on the first screen; everything else goes to the far cheaper dns-prefetch.

Preload: powerful, but reserve it for what's genuinely critical

preload forces the browser to download a resource at high priority, before it would otherwise discover it while parsing the HTML or CSS — useful for a font file used in the main headline, or a CSS background image that, without it, wouldn't be discovered until the stylesheet had fully downloaded. The trap: every preloaded resource consumes bandwidth and network priority from the very first milliseconds of the load, competing directly with the hero image or the main script. Preloading a font that's only used in the footer, or an image that only appears after a click, pulls resources away from what actually matters for the initial render — and can, paradoxically, hurt the very LCP you were trying to improve.

Implementing it properly on a Next.js landing page

On a Next.js site, like the 10 LanderKit templates, the next/font component already handles preloading self-hosted fonts automatically: no manual tag needed, the file ships with the right priority straight from the build. For the remaining third-party domains (payment, chat, video), the simplest approach is to add <link rel="preconnect"> or <link rel="dns-prefetch"> tags directly in the <head> generated by app/layout.tsx, keeping the list limited to domains actually called on the page. For the scripts themselves, next/script with a lazyOnload or afterInteractive strategy keeps a third-party script from blocking the initial render — we cover the full deployment setup in our article on Next.js and Vercel.

Verify the real effect instead of assuming one

Chrome DevTools' Network tab shows, for every request, the breakdown by phase (DNS, connection, TLS, waiting, download): that's where you can actually see whether a preconnect removed a wait from the critical path, or whether the connection, once opened, was never reused at all. PageSpeed Insights and Lighthouse round out the diagnosis with dedicated audits — we explain why these two tools can show different scores in our article on PageSpeed, Lighthouse, and GTmetrix. As with any technical optimization, it's better to measure before and after each addition than to stack tags out of caution: an unnecessary preconnect is never free — it always costs the browser a bit of resources.