How do resource hints like preconnect, preload, and prefetch work?
guide // , 5 min read, by Darthwares
Resource hints are instructions you can provide to browsers to perform actions before they are explicitly requested, improving page load performance and user experience. These hints, such as preconnect, preload, and prefetch, tell the browser to prepare for or fetch resources speculatively. By initiating connections or downloading assets earlier, these hints can make your website feel faster and more responsive to users.
On this page // 7 sections
The short version
- Preconnect establishes early connections to other origins.
- Preload fetches critical resources for the current page.
- Prefetch fetches resources for future navigations.
- Use preconnect for the most critical cross-origin connections.
- Preload has a higher priority than prefetch because it serves the current page.
What are resource hints?
Speculative loading involves performing navigation actions, like fetching resources or rendering documents, before the associated pages are actually visited. This is based on predictions about which pages a user is most likely to visit next. Resource hints are a way to communicate these predictions to browsers, allowing them to optimize the loading process.
How does preconnect work?
MDN Web Docs explains that the preconnect hint, specified using <link rel="preconnect">, suggests to browsers that the user will likely need resources from a particular origin. This allows the browser to improve performance by initiating a connection to that origin ahead of time. Preconnecting speeds up future loads by performing part or all of the connection handshake, which includes DNS resolution, TCP connection, and TLS negotiation for HTTPS origins.
This hint provides a benefit to any future cross-origin HTTP request, whether it is for navigation or a subresource. However, it offers no benefit for same-origin requests because the connection to the current domain is already open.
- Resolves the domain name (DNS lookup).
- Establishes a TCP connection.
- Performs a TLS handshake for secure connections.
When should you use preconnect?
MDN Web Docs advises that preconnect is best used for only the most critical connections. If a page needs to establish connections to many third-party domains, preconnecting all of them can be counterproductive. For less critical connections, it is more efficient to use <link rel="dns-prefetch"> to save time on just the first step of the connection process, which is the DNS lookup.
How does preload work?
The preload hint, specified using <link rel="preload">, informs browsers about high-priority resources needed for the current page. MDN Web Docs states that this allows the browser to start downloading these resources early when it encounters the <link> element in the <head> of the page, before the browser's main rendering machinery begins. This ensures the resources are available sooner and are less likely to block the page's render, which improves performance.
While preload schedules a resource to be downloaded and cached with a higher priority, it does not execute scripts. Using the as attribute to specify the content type, such as as="script" or as="font", helps the browser store the resource correctly in the cache for future requests, allowing for reuse. For resources fetched with CORS enabled, such as fonts, the crossorigin attribute must be set on the <link> element to match the resource's CORS and credentials mode, even if the fetch is not cross-origin.
Browsers can accept media attributes on <link> elements, but specifying preload for multiple types of the same resource is generally discouraged.
- Targets high-priority resources for the current page.
- Initiates download early in the page lifecycle.
- Does not execute scripts, only schedules download and caching.
- Requires the as attribute to specify content type for proper caching.
- Needs the crossorigin attribute for CORS-enabled fetches.
How does prefetch work?
MDN Web Docs explains that the prefetch hint, specified using <link rel="prefetch">, suggests to browsers that a user is likely to need a target resource for future navigations. This allows the browser to improve the user experience by preemptively fetching and caching the resource. The fetched resource is stored in the HTTP cache on disk, making it useful for prefetching subresources, even if they are not used by the current page.
Prefetch is typically used for same-site navigation resources or subresources used by same-site pages. Browsers generally assign a lower priority to prefetch resources compared to preload resources, as the current page's needs are considered more important than those for a future page. When a prefetch operation occurs, the HTTP request includes the Sec-Purpose: prefetch header.
It is important to be careful with HTTP Cache-Control headers, as certain values like no-cache or no-store could block prefetching. Additionally, many browsers now implement cache partitioning, which makes prefetch ineffective for resources intended for use by different top-level sites.
- Targets resources for future navigations.
- Fetches and caches resources preemptively.
- Has a lower priority than preload.
- Results in an HTTP request with Sec-Purpose: prefetch header.
- Ineffective for resources across different top-level sites due to cache partitioning.
What is the difference between preload and prefetch?
The primary distinction between preload and prefetch lies in their scope and priority. MDN Web Docs clarifies that preload is for resources that are high-priority on the current page and will be needed very soon, allowing them to be downloaded early to prevent blocking the page's render. In contrast, prefetch is for resources that the user is likely to need for future navigations.
Browsers prioritize preload resources higher than prefetch resources because the current page's performance is considered more critical than anticipating a future page load.
| Hint | Purpose | Priority | Timing |
|---|---|---|---|
| Preload | Critical resources for the current page | High | Early in current page's lifecycle |
| Prefetch | Resources for future navigations | Lower | After current page's critical resources |
Common questions
What is speculative loading?
Speculative loading is the practice of performing navigation actions, such as DNS lookups, fetching resources, or rendering parts of documents, before a user actually visits the associated pages. This is done based on predictions about which pages the user is most likely to visit next, aiming to improve perceived performance.
Does preconnect help with same-origin requests?
No, preconnect does not provide a benefit for same-origin requests. The connection to the current domain is already open, so there is no handshake process to speed up for resources from the same origin. It is designed for cross-origin connections.
Can prefetch be used for resources on other top-level sites?
No, prefetch is generally useless for resources intended for use by different top-level sites. This is due to many browsers implementing cache partitioning, which prevents resources prefetched for one top-level site from being used by another.
What happens if I preload a resource my page doesn't use?
If you preload something that your current page does not use as a subresource, it is generally a waste of resources. While the result might populate the HTTP cache if headers allow, the primary benefit of preload for improving current page performance is lost.
Why is prefetch lower priority than preload?
Browsers give prefetch resources a lower priority than preload ones because the current page is considered more important than a page the user might visit next. Preload addresses immediate needs for the current page's rendering, while prefetch anticipates future needs.
Primary sources and further reading
This article was researched and written by an AI model and published automatically. It was written from sentences that were checked to appear on the pages below, but a person has not reviewed the text. If something is wrong, tell us at chibivikramathithan@darthwares.com and we will correct it.