Preconnect and preload

Two Lighthouse findings deal with telling the browser earlier what it will need: Preconnect to required origins and Preload key requests. Both are resource hints, small tags in the HTML head that let the browser start work before it would discover the need on its own. Used well, they shave hundreds of milliseconds off Largest Contentful Paint and font rendering. Used carelessly, they compete with the resources that matter and make the page slower. This guide covers what each hint does, when to use it and the mistakes that turn a hint into a cost.

Preconnect: open the connection before the request

Every request to a new origin pays for a DNS lookup, a TCP handshake and a TLS negotiation before a single byte of content flows. On a mobile connection that setup alone can take several hundred milliseconds. rel="preconnect" tells the browser to do that setup now, in parallel with parsing the HTML, so the first real request to that origin finds a warm connection:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example-images.com">

The crossorigin attribute matters: fonts and fetch() requests use CORS and need a separate connection from plain image or script requests. A preconnect without crossorigin does nothing for a font file, and the other way round.

Lighthouse lists origins where an early connection would have saved time, based on how late the first request to that origin started. Good candidates are the one or two origins that serve resources needed for the first paint: a separate image CDN, a font host, or an API the page needs before it can render. Third-party analytics and chat widgets are not candidates; they should load late, not early.

Keep the list short. Each preconnect opens a connection that costs CPU and memory on the device, and a connection the page does not use within a few seconds is closed again, wasted. More than a handful of preconnects is a sign that the page depends on too many origins, which is a problem resource hints cannot solve.

rel="dns-prefetch" is the lighter sibling: it only resolves the hostname. It is a reasonable fallback for origins that will be used later in the page, and it costs almost nothing.

Preload: fetch a late-discovered resource early

The browser discovers most resources while parsing the HTML. Some it cannot see until much later: a font referenced from inside a CSS file, a hero image set through a CSS background-image, or a script loaded by another script. rel="preload" moves those to the front of the queue:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/hero.avif" as="image" fetchpriority="high">

The as attribute is required; without it the browser cannot assign the right priority and may fetch the file twice. Lighthouse reports Preload key requests for resources that sit deep in the request chain and delay the critical path.

Preload is a sharp tool. Every preloaded file competes with the HTML, CSS and the LCP image for bandwidth during the first seconds. Preloading five fonts and three scripts does not make them all fast, it makes the LCP image slow. The right number of preloads on most pages is between zero and three: the LCP image if CSS or JavaScript hides it from the parser, and one or two fonts used above the fold.

fetchpriority: the simpler fix for the LCP image

If the LCP image is a normal <img> in the HTML, it does not need a preload. The parser finds it, and the only problem is that the browser assigns images a low priority until it knows they are visible. fetchpriority="high" fixes exactly that:

<img src="/img/hero.avif" width="1200" height="600" alt="..." fetchpriority="high">

Use preload for the LCP image only when it is a CSS background or injected by JavaScript. For everything below the fold, do the opposite: lazy-load it.

How to apply resource hints step by step

1. Find the critical origins and files. In the Network panel of Chrome DevTools, sort by start time and look at what the first paint and the LCP element depend on. Lighthouse names the candidates in both findings.
2. Add at most two preconnects for origins that serve render-critical resources, with crossorigin where fonts or CORS requests are involved.
3. Mark the LCP image with fetchpriority="high", or preload it if the parser cannot see it.
4. Preload the one or two fonts used in the first screen, and only those. Combine this with font-display so text renders while fonts load.
5. Re-test and compare the LCP breakdown. A preload that helps shortens the resource load delay of the LCP element. If LCP got worse, remove the last hint you added.
6. Remove hints when the resources change. A preload for a font the site no longer uses is a pure cost; audits rarely catch it because the file still loads fine.

Platform notes

• WordPress: caching and optimization plugins add preconnects for Google Fonts and preloads for fonts. Check that they do not also preload every stylesheet, which is a common default that hurts LCP. Self-hosting fonts removes the need for the Google Fonts preconnect entirely.
• Shopify: the theme controls the head. Themes from the Shopify theme store already preload the primary font and prioritize the hero image; apps that inject their own fonts and scripts are the usual source of unneeded origins.
• Next.js: next/image with priority handles the LCP image, and next/font self-hosts and preloads fonts. Manual preload tags are rarely needed and often duplicate what the framework does.

Frequently asked questions

Should I preconnect to Google Fonts?

If you load Google Fonts, yes: preconnect to fonts.gstatic.com with crossorigin, because that is where the font files live and the CSS from fonts.googleapis.com only references them. The faster option is self-hosting, which removes both origins.

Can too many preloads hurt performance?

Yes. Preloads compete with the critical resources for bandwidth in the first seconds. Limit them to the LCP image, when needed, and one or two above-the-fold fonts.

What is the difference between preload and prefetch?

Preload fetches a resource for the current page at high priority. Prefetch fetches a resource for a likely next page at low priority, once the current page is idle. Do not use prefetch for anything the current page needs.

Why does Chrome warn that a preloaded resource was not used?

Either the as attribute or crossorigin does not match the real request, so the browser fetched the file twice, or the resource is not needed in the first seconds. Fix the attributes or remove the preload.