preload, prefetch, and preconnect Explained

Modern browsers are very good at deciding what to load and when.

Most of the time, you should let them do their job.

But sometimes you know something the browser does not know yet. Maybe a font will be needed after the CSS file loads. Maybe the next page is likely to be opened. Maybe your page needs to connect to another domain before an important request can start.

HTML resource hints can help.

The three names people often mix up are:

preload
prefetch
preconnect

They sound similar, but they do different things.

`preload`

preload tells the browser that a resource is important for the current page and should be discovered early.

<link
  rel="preload"
  href="/fonts/site.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>

The browser can start the request before it discovers the font later in CSS.

Preloading an image

<link
  rel="preload"
  as="image"
  href="/images/hero.webp"
>

This can help when an important image is discovered too late.

Do not preload every image.

If everything becomes high priority, the browser has less room to prioritize the things that really matter.

`as` matters

When using preload, tell the browser what kind of resource it is.

Examples:

as="style"
as="script"
as="font"
as="image"
as="fetch"

The browser uses this information for priority and security rules.

`preconnect`

preconnect does not download the final resource.

It tells the browser to prepare a connection to another origin.

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

Before downloading from another domain, the browser may need to do:

DNS lookup
↓
connection
↓
TLS setup
↓
request

Preconnect can start some of that work earlier.

A good preconnect use

If important images come from:

https://images.example-cdn.com

you might add:

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

This may save time before the first image request.

Do not preconnect to everything

Every connection costs resources.

This is not a good idea:

<link rel="preconnect" href="https://site-a.com">
<link rel="preconnect" href="https://site-b.com">
<link rel="preconnect" href="https://site-c.com">
<link rel="preconnect" href="https://site-d.com">

Use it only for origins that matter early.

`prefetch`

prefetch is more about future use.

It tells the browser that a resource may be useful later but is not needed for the current page.

<link
  rel="prefetch"
  href="/next-article/"
>

The browser may fetch it at low priority when it has spare time.

A simple way to remember them

preload
→ important now

preconnect
→ prepare a connection now

prefetch
→ maybe useful later

That is the main difference.

What about `dns-prefetch`?

There is also:

<link
  rel="dns-prefetch"
  href="//example.com"
>

This asks the browser to resolve the domain name early.

preconnect goes further by preparing more of the connection.

Fonts are a common preload case

A font inside CSS may be discovered later than you want.

<link
  rel="preload"
  href="/fonts/site.woff2"
  as="font"
  type="font/woff2"
  crossorigin
>

Only preload fonts used on the current page.

If you use system fonts, you do not need this at all.

Compare with `fetchpriority`

Another related feature is:

<img
  src="/hero.webp"
  fetchpriority="high"
  alt=""
>

fetchpriority changes the priority of a resource the browser is already going to request.

preload can make the browser discover a resource earlier.

They solve different parts of the loading problem.

Measure before adding hints

Do not add every performance hint just because it exists.

Ask:

Is an important request discovered late?
Is a third-party connection delaying something important?
Is there a likely next page worth prefetching?

Then add the smallest hint that solves that problem.

A realistic example

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

  <link
    rel="preload"
    href="/fonts/site.woff2"
    as="font"
    type="font/woff2"
    crossorigin
  >

  <link
    rel="stylesheet"
    href="/style.css"
  >
</head>

That may be reasonable.

A site using local system fonts and same-origin images may need none of it.

Resource hints are hints, not magic performance switches.

Use them to give the browser useful information it cannot easily know yet, and avoid trying to control every request.