Skip to main content
All Docs
FeaturesBlockManOSUpdated March 26, 2026

Performance Deep-Dive: Preconnecting to Avatar & CDN Domains

Performance Deep-Dive: Preconnecting to Avatar & CDN Domains

Release: v1.0.92 · Control: PERF-23 · Category: Resource Loading

Background

The platform's top navigation bar displays an authenticated user's avatar. Depending on the sign-in provider, that image is fetched from one of several external origins:

ProviderDomain
Google OAuthlh3.googleusercontent.com
GitHub OAuthavatars.githubusercontent.com
Gravatarwww.gravatar.com
AWS S3 uploads*.amazonaws.com
Cloudflare R2 uploads*.r2.cloudflarestorage.com

All of these domains were already declared in the remotePatterns section of next.config.ts so Next.js Image Optimization could proxy and optimise them. The <Avatar> component also set priority=true, which generates a <link rel="preload"> tag for the image itself — but only after the browser has established a connection to the origin.

The Problem

Before this release, there were no preconnect or dns-prefetch hints for any of the external avatar domains. This meant the browser had to:

  1. Parse the HTML response
  2. Discover the <img> tag (or its preload)
  3. Begin DNS resolution for the external domain
  4. Complete the TCP handshake
  5. Complete the TLS negotiation
  6. Only then send the first byte of the image request

Steps 3–5 can collectively add 100–300 ms of latency on a cold connection, even when the image itself is small. For an above-the-fold element, this directly harms the page's Largest Contentful Paint (LCP) score.

The Fix

Adding preconnect and dns-prefetch hints in src/app/layout.tsx allows the browser to start warming up connections immediately when it begins parsing the <head>, before it has even encountered the avatar <img> tag.

// src/app/layout.tsx  (simplified)
export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <head>
        {/* Warm up the full connection stack for high-probability origins */}
        <link rel="preconnect" href="https://lh3.googleusercontent.com" />
        <link rel="preconnect" href="https://avatars.githubusercontent.com" />

        {/* DNS-only for origins used less frequently */}
        <link rel="dns-prefetch" href="https://www.gravatar.com" />
      </head>
      <body>{children}</body>
    </html>
  )
}

Why preconnect for Google & GitHub but only dns-prefetch for Gravatar?

  • preconnect opens a full DNS + TCP + TLS connection speculatively. This is ideal when you are confident the connection will be used (e.g. every Google or GitHub OAuth user loads an avatar on every page). Keeping unnecessary idle connections open wastes browser resources.
  • dns-prefetch only resolves the DNS record, which is cheap. It is the right choice for Gravatar (used by a smaller subset of users) and wildcard domains like *.amazonaws.com and *.r2.cloudflarestorage.com, where a full preconnect to the wildcard apex would not actually warm the correct subdomain connection anyway.

Expected Impact

MetricBeforeAfter
Avatar image TTFB (cold connection)DNS + TCP + TLS penalty (~100–300 ms)Near-zero (connection pre-warmed)
LCP (avatar as largest element)Impacted by connection costReduced by connection warm-up
Functional behaviourUnchangedUnchanged

Note: The gains are most visible for first-time visitors or users with cleared browser caches. Repeat visits benefit from the browser's built-in connection caching.

Next Steps

Future improvements in the PERF roadmap may include:

  • Adding crossorigin attributes to preconnect hints where CORS is required (e.g. for fonts or credentialed requests).
  • Evaluating preload hints for predictable avatar URLs when the URL is known at render time on the server.
  • Auditing additional third-party scripts for connection warm-up opportunities.