Prefetch, preconnect, preload, and 103 Early Hints

These are browser performance hints. They let an application start network work before the browser would discover it naturally.

They solve different problems:

Hint	What starts early?	Best for
preconnect	Connection setup	A critical third-party origin
prefetch	Low-priority download	A likely future page or resource
preload	High-priority download	A critical resource needed by the current page
103 Early Hints	Processing hints before the final response	Starting preload or preconnect while the server is still preparing the page

Mental model: Preconnect prepares the road, while prefetch and preload move resources over it. A 103 response delivers those instructions earlier.

Preconnect

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

preconnect asks the browser to establish a connection to another origin before it is needed.

This may include:

• Domain Name System (DNS) lookup,
• Transmission Control Protocol (TCP) connection,
• Transport Layer Security (TLS) handshake for secure connections.

It does not download a resource.

When to use it

• The page will soon request an important resource from another origin.
• Connection setup is likely to be a meaningful part of the delay.

Trade-off

Connections consume sockets, memory, and server resources. Preconnect only to a small number of high-confidence origins.

dns-prefetch performs only the DNS lookup. preconnect goes further and prepares the full connection.

Prefetch

<link rel="prefetch" href="/next-page.js">

prefetch asks the browser to download a resource at low priority because it may be needed for a future navigation.

Examples:

• code for the next likely route,
• data or assets for a page the user is likely to open next.

The browser stores the response in its cache and may reuse it later. Because this is speculative, the browser can delay or ignore the hint based on network conditions, user settings, or resource priority.

Trade-off

An incorrect prediction wastes user bandwidth and creates unnecessary Content Delivery Network (CDN) or server traffic.

Use prefetch for likely next-page resources, not resources required to render the current page.

Preload

<link rel="preload" href="/hero.webp" as="image">
<link rel="preload" href="/app-font.woff2" as="font" type="font/woff2" crossorigin>

preload tells the browser that the current page will need an important resource soon, so it should fetch it earlier and with higher priority.

It is useful for critical resources that the browser would otherwise discover late, such as:

• a font referenced inside a Cascading Style Sheets (CSS) file,
• a hero image added through CSS,
• a critical script discovered after other dependencies.

preload downloads the resource but does not apply or execute it. The normal stylesheet, script, font, or image request later consumes the downloaded response.

Important details

• Set as correctly—for example, style, script, font, or image—so the browser applies the right priority and security rules.
• The preload request must match the later real request, including credentials and crossorigin behavior. A mismatch can cause the browser to download the resource twice.
• Preload only genuinely critical resources. Too many high-priority downloads compete with each other and can make the page slower.

Use preload when the resource is definitely needed now but discovered too late.

103 Early Hints

103 Early Hints lets the server tell the browser about important resources before the final page response is ready.

The problem it solves

Normally, the browser must wait for the server to generate and return the page’s HTML before it discovers resources such as stylesheets and fonts.

Request page → Wait for server → Receive HTML → Discover CSS/font → Start downloads

If generating the page takes time, the browser sits idle even when the server already knows which critical resources the page will need.

How 103 helps

The server—or a Content Delivery Network (CDN) in front of it—can first send a small 103 Early Hints response containing Link headers.

Request page
    ↓
103 Early Hints → Browser starts CSS/font downloads
    ↓
Server continues generating the page
    ↓
200 OK + HTML

HTTP/1.1 103 Early Hints
Link: </styles.css>; rel=preload; as=style
Link: <https://fonts.example.com>; rel=preconnect
 
HTTP/1.1 200 OK
Content-Type: text/html

Here is what happens:

1. The browser requests the page.
2. The server or CDN quickly sends 103 Early Hints.
3. The browser reads its Link headers and can start a preload or preconnect.
4. At the same time, the server continues generating the page.
5. The server sends the normal final response, such as 200 OK, with the HTML.

The browser does not render the 103 response. It has no page body and does not replace the final response—it simply starts useful network work earlier.

Best use case

Early Hints are most useful when:

• generating the final HTML has noticeable server latency,
• critical resources are known before the HTML is ready,
• a CDN can send the hints immediately while waiting for the origin server.

Trade-off

Only hint at high-confidence resources. If the final page does not use a hinted resource, the early download wastes bandwidth and CDN or server work.

In short: 103 Early Hints does not make the server generate HTML faster. It uses that waiting time to start fetching critical resources sooner.

Preload vs prefetch

	Preload	Prefetch
Needed by	Current page	Likely future page
Confidence	High—the resource is required	Speculative—the resource may be needed
Priority	High	Low
Main risk	Competes with critical page resources	Wastes bandwidth and server/CDN work

Preload vs 103 Early Hints

These are complementary, not competing features:

• Preload describes which resource the browser should fetch early.
• 103 Early Hints delivers that preload instruction before the final response is ready.

The same preload can also be declared in the final HTTP Link header or in the page’s HTML.

Staff-level takeaways

• These APIs are hints; the browser remains in control and may ignore them.
• Optimize discovery and prioritization before adding more hints. Hints cannot fix an unnecessarily large resource.
• Measure real-user performance before and after deployment. An optimization for fast networks may waste bandwidth or hurt users on constrained devices.
• Prefer a few high-confidence hints over broad speculation.
• Watch for duplicate downloads, unused preloads, connection growth, and increased CDN or origin traffic.

Interview answer

Preconnect starts DNS, TCP, and TLS connection work for an origin but downloads nothing. Prefetch downloads a low-priority resource that may be needed on a future page. Preload fetches a high-priority resource definitely needed by the current page but discovered late. A 103 Early Hints response lets the server or CDN send preload or preconnect instructions before the final page response is ready.

Knowledge check — Q&A

Q: Does preconnect download a file?
No. It only prepares the connection to an origin.

Q: What is the simplest distinction between preload and prefetch?
Preload is for a required current-page resource; prefetch is for a speculative future resource.

Q: Why is the as attribute important for preload?
It tells the browser the resource type so it can apply the correct priority, cache behavior, and security policy.

Q: Why might a preloaded resource be downloaded twice?
The preload and the later request may not match—for example, because as, credentials, or crossorigin was configured incorrectly.

Q: What problem does 103 Early Hints solve?
It lets the browser begin useful network work while the server is still preparing the final response.

Q: What is the main risk of all these hints?
Overuse can waste bandwidth, increase server or CDN cost, and make truly critical work compete for network capacity.

References

• WHATWG HTML Standard — link types
• RFC 8297 — 103 Early Hints