What Is rel=preconnect? Complete Guide (2026)

Why Connection Setup Time Dominates Third-Party Load

For every cold third-party origin (a font host, an analytics provider, an ads exchange, an embed service), the browser must complete three sequential network round trips before a single byte of payload arrives:

1. DNS lookup — resolve the hostname to an IP address (1 RTT, often cached).
2. TCP handshake — three-way SYN/SYN-ACK/ACK (1 RTT).
3. TLS handshake — TLS 1.3 needs 1 RTT; TLS 1.2 needs 2 RTTs.

On a typical 4G connection with 100 ms RTT, that’s 200–300 ms of pure setup overhead per origin, before the request line is even sent. A page pulling fonts from one origin, analytics from a second, and an embed from a third can pay this cost three times in series — easily 600–900 ms of delay that has nothing to do with payload size.

preconnect moves these handshakes into parallel with HTML parsing, so by the time the parser reaches the actual <link> or <script> tag, the connection is already open and the request can transfer immediately.

How rel=preconnect Works (Worked Example)

Consider a page that loads a font stylesheet from fonts.example.com600 ms into HTML parsing. Without a hint, here’s the timeline at 100 ms RTT:

Without preconnect:
0ms     HTML starts parsing
600ms   Parser discovers <link href="https://fonts.example.com/...">
600ms   DNS lookup starts        (+100ms)
700ms   TCP handshake starts     (+100ms)
800ms   TLS handshake starts     (+100ms with TLS 1.3)
900ms   Request sent             <-- font byte zero begins here

With preconnect (hint at byte 0 of the HTML):
0ms     HTML starts parsing
0ms     DNS + TCP + TLS to fonts.example.com start in parallel
~300ms  Connection ready, idling
600ms   Parser discovers font link
600ms   Request sent             <-- font byte zero, 300ms earlier

The handshakes still happen — they just happen alongside parsing instead of after it. That’s the entire mechanism.

How to Check Where Preconnect Helps

Identify candidate origins from real load data, not guesswork. Each tool tells you slightly different things:

• Greadme deep scan — flags third-party origins discovered late in HTML parsing and shows which ones would benefit most from a preconnect hint, paired with a one-click GitHub PR to add the tag.
• Greadme crawler scan — runs the same audit across every indexable page so you can see which templates (e.g., article pages vs. product pages) are paying the most third-party connection tax.
• Chrome DevTools → Network → Timing — for any cross-origin request, the “Connection start” section breaks down DNS, Initial connection, and SSL phases. If those bars are non-trivial, that origin is a preconnect candidate.
• Google Search Console → Core Web Vitals — confirms whether the LCP and FCP improvements from preconnect translate to real-user 75th-percentile gains.
• web.dev / PerformanceObserver — programmatically read PerformanceResourceTiming entries; large connectStart-to-requestStart gaps mark slow handshakes that preconnect would eliminate.

7 Practical Ways to Use rel=preconnect Correctly

<link rel="preconnect" href="https://fonts.example.com" crossorigin>
<link rel="stylesheet" href="https://fonts.example.com/css?family=...">

<link rel="preconnect" href="https://cdn.example.com">

<link rel="preconnect" href="https://api.example.com" crossorigin>

<link rel="preconnect" href="https://fonts.example.com" crossorigin>
<link rel="dns-prefetch" href="https://widget.example.com">
<link rel="dns-prefetch" href="https://chat.example.com">

if (document.querySelector('.video-embed')) {
  const link = document.createElement('link');
  link.rel = 'preconnect';
  link.href = 'https://video.example.com';
  link.crossOrigin = 'anonymous';
  document.head.appendChild(link);
}

Link: <https://fonts.example.com>; rel=preconnect; crossorigin
Link: <https://cdn.example.com>; rel=preconnect

Common Preconnect Mistakes

preconnect vs. dns-prefetch vs. preload vs. prefetch

All four are <link rel>hints, but they answer different questions. Pick the right one based on certainty and the resource’s role.

FAQ

Does rel=preconnect actually make pages faster?

Yes — when used correctly. Saving a 200–300 ms handshake for a render-blocking font or critical API means the resource arrives that much sooner, which translates directly into faster First Contentful Paint and Largest Contentful Paint. The benefit is largest on high-RTT connections (mobile networks).

How many preconnect tags is too many?

Limit to 4–6 of the most critical third-party origins. Each one reserves a TCP socket. Once you exceed roughly six, you start to crowd out connections to first-party assets and hurt the metrics you were trying to improve. For everything else, use dns-prefetch.

When do I need the crossorigin attribute?

Whenever the resource on that origin will be fetched in CORS mode. That includes all web fonts, scripts loaded with crossorigin="anonymous", and any fetch() request without mode: 'no-cors'. If you forget crossorigin for these, the preconnect is wasted and the browser opens a second connection anyway.

Should I preconnect to my own domain?

No. The browser already has an open connection to the origin that served the HTML. A preconnect to the same origin is a no-op and wastes a tag slot.

Is preconnect a Core Web Vitals ranking signal?

Not directly — there’s no “preconnect score.” But because preconnect speeds up cross-origin fonts and critical resources, it usually improves LCP and FCP, which are ranking signals. The faster you can deliver bytes for the LCP element, the better your Core Web Vitals report in Google Search Console.

Does rel=preconnect affect AI search engines like ChatGPT and Perplexity?

Indirectly. AI-driven search systems disproportionately cite pages that already rank well in traditional search, and Core Web Vitals (which preconnect helps) feed traditional ranking. AI crawlers also tend to fetch pages with timeouts; faster handshakes mean a higher chance the bot completes the fetch successfully and ingests your content. So while no AI engine specifically rewards preconnect, the metrics it improves are universally rewarded.

Can I preconnect via JavaScript at runtime?

Yes. Inserting a <link rel="preconnect"> into document.headat runtime triggers the same handshake. It’s the right approach for connections only needed on user interaction or after a feature flag check, where paying the cost on every page would be wasteful.