Preconnect to Origins.

Performance Asset Optimization

Early DNS/TLS handshakes to third-party origins save 100-300ms

What does this check test?

This check identifies third-party origins that the page loads resources from but does not preconnect to. Each new origin requires DNS lookup (50-200ms), TCP connection (50-200ms), and TLS negotiation (100-200ms) before any data can transfer. `<link rel="preconnect">` tells the browser to establish these connections early, in parallel with other work, so resources from that origin can be fetched immediately when needed. A lighter alternative, `<link rel="dns-prefetch">`, only performs DNS resolution. Preconnecting saves 100-300ms per origin on first request.

Why does it matter?

Connection setup to third-party origins is a hidden performance cost that adds up quickly. A page loading resources from 5 different third-party origins (Google Fonts, CDN, analytics, ads, social widgets) incurs connection overhead for each one. These connections happen sequentially in the critical path — the browser must complete DNS, TCP, and TLS before downloading the first byte from each origin. Preconnecting moves this overhead to idle time early in the page load, so when the resource is actually needed, the connection is already established. This is especially impactful for origins that serve render-critical resources like fonts and CSS.

Who is affected?

Sites loading resources from multiple third-party origins are most affected: Google Fonts (fonts.googleapis.com + fonts.gstatic.com), CDNs (cdn.example.com), analytics services, ad networks, and social media widgets. Sites using font services, image CDNs, or API endpoints on different domains benefit significantly. Each additional origin adds 100-300ms of connection overhead without preconnect.

Where does this apply?

Chrome DevTools Network panel shows connection timing for each request in the Timing tab — look for long DNS, Connect, and SSL segments on third-party resources. Lighthouse identifies origins that would benefit from preconnect in the 'Preconnect to required origins' diagnostic. Focus on origins that serve resources needed within the first few seconds of page load — preconnecting to origins used much later provides less benefit.

How to fix it

Add `<link rel="preconnect">` tags in the `<head>` for critical third-party origins. Limit preconnects to 4-6 origins. Preconnect to critical origins (use both preconnect and dns-prefetch for broad support):

html

<head>
  <!-- Google Fonts (two origins required) -->
  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

  <!-- CDN with dns-prefetch fallback -->
  <link rel="preconnect" href="https://cdn.example.com" />
  <link rel="dns-prefetch" href="https://cdn.example.com" />

  <!-- Less critical — dns-prefetch only -->
  <link rel="dns-prefetch" href="https://analytics.example.com" />
</head>

Add `crossorigin` when the resource will be fetched with CORS (fonts, fetch API calls). Each preconnect consumes CPU and network resources, and connecting to too many origins simultaneously can actually hurt performance. Prioritize origins that serve render-blocking resources (fonts, critical CSS/JS). Self-hosting resources (fonts, analytics scripts) eliminates the need for preconnect entirely.

References

AppVet checks Preconnect to Origins automatically

Run a free performance scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit

← All checks