Preload in Frontend Performance

Preload explicitly tells the browser to fetch an important resource earlier than normal discovery would allow. It is useful when a resource is needed soon but is otherwise discovered late, such as a critical font, image, stylesheet, or script.

`` creates an early fetch request for a resource while leaving its eventual use to the consuming element or code. The browser can therefore begin downloading it before normal parsing or dependency discovery reaches it.

A preload should identify the resource with `href` and normally specify `as`, such as `as="image"`, `as="font"`, `as="style"`, or `as="script"`. The `as` value helps the browser apply the correct fetch priority, security policy, and cache handling.

Preload is most valuable when the browser's normal loading path creates a discovery delay. For example, a hero image referenced from CSS or a font needed by above-the-fold content may not become known immediately. Preloading can move that discovery earlier, potentially reducing the time before the resource is usable.

Preload is not a generic command to download everything early. An unnecessary preload consumes bandwidth and connection capacity and can compete with resources that matter more to rendering. It should therefore be reserved for resources that are both important and likely to be requested shortly.

For fonts and cross-origin resources, the preload configuration must match the eventual request closely, including relevant `crossorigin` behavior. A mismatch can cause an additional fetch rather than allowing the preloaded response to satisfy the later request.

Key points

• Preload moves resource discovery earlier; it does not itself render or execute the resource.
• Use `as` to describe the resource type and help the browser handle the request correctly.
• Good candidates are critical resources discovered late in the loading process.
• Overusing preload can waste bandwidth and compete with higher-priority requests.
• For fonts and cross-origin resources, preload attributes must align with the eventual request.

Interview questions

What problem does `` solve?

Preload reduces the delay before the browser discovers an important resource. It is particularly useful when normal parsing or dependency discovery would reveal that resource late. The browser starts fetching it when it encounters the preload declaration, while the normal element or code still determines how the resource is used.

Why is the `as` attribute important on a preload link?

`as` tells the browser what kind of resource is being requested. This lets it apply appropriate request handling, including relevant security and caching behavior, and helps the browser prioritize the fetch correctly. Common values include `image`, `font`, `style`, and `script`.

When would you preload an image?

I would consider preloading an image when it is important to the initial view but is discovered late through the normal loading path. A common case is a prominent image whose URL is initially hidden behind CSS or another dependency. I would verify that the image is actually needed early, because an unnecessary preload can compete for bandwidth with more important resources.

How can preload improve Core Web Vitals?

Preload can improve a Core Web Vital when it advances a critical resource that otherwise delays meaningful rendering. For example, earlier discovery of a critical image can reduce the time before that image is available, which may help metrics such as LCP. The benefit is workload-dependent: an unnecessary preload can instead consume bandwidth and delay other important resources.

What special considerations apply when preloading fonts?

Font preloads should use `as="font"` and normally include `crossorigin` when the eventual font request is CORS-enabled, including common cross-origin font scenarios. The preload and eventual request need compatible request characteristics so the browser can reuse the fetched response. Fonts should also be preloaded selectively because fetching unused fonts consumes bandwidth.