Should you really use preload for all your critical resources?

What is the preload attribute and why is Google talking about it now?

The preload attribute has been available for several years in modern browsers. It signals to the browser that a specific resource (font, image, script, CSS) should be fetched immediately after parsing the HTML, even before the browser naturally discovers that resource in the code.

Unlike prefetch, which prepares resources for future navigation, preload works on the current page. The browser downloads the resource with high priority and caches it, ready to be used as soon as the code calls for it. This declaration from Google validates a practice already common in optimizing Core Web Vitals.

How does this differ from normal resource loading?

Without preload, the browser follows a sequential discovery order: it parses the HTML, discovers the CSS, downloads it, parses the CSS, discovers fonts or background images, and then downloads them. Each step waits for the previous one. This waterfall effect can delay rendering by hundreds of milliseconds.

With preload, you bypass this cascade. You explicitly indicate, "This Montserrat font is critical for my hero; load it now." The browser retrieves it in parallel with parsing instead of waiting for the download and parsing of the CSS to finish. The gain on the Largest Contentful Paint can reach 200-500ms on average connections.

What resources does Google consider to be 'critical'?

Google deliberately remains vague on this definition. In practical terms, critical resources are those necessary for above-the-fold rendering: custom fonts used in the hero, critical CSS, LCP images, blocking synchronous scripts if unavoidable.

Web fonts are the most common use case. A non-preloaded font creates a FOIT (Flash of Invisible Text) or FOUT (Flash of Unstyled Text), visually degrading the loading experience and delaying the LCP. Hero images can also benefit from preload, especially if they are called via CSS and not directly in the HTML.

• Custom web fonts used in above-the-fold content (highest priority)
• LCP images loaded via CSS background-image or discovered late
• Critical CSS if your setup involves multiple files that block rendering
• Essential scripts for the first render (rare, generally to be avoided)
• Video poster files if the video is the LCP element on your page

Is this recommendation consistent with field observations?

Absolutely. PageSpeed Insights audits regularly flag non-preloaded fonts and images as optimization opportunities. Measured gains are real: between 150ms and 600ms on the LCP depending on network latency and resource weight. E-commerce sites that have preloaded their hero fonts and product images have seen their LCP drop below the 2.5-second mark.

That said, Google dangerously oversimplifies the message. Preload is not a magic wand: when misused, it creates bandwidth congestion that delays everything else. Preloading 8 resources simultaneously on a 3G connection saturates the network and degrades overall performance. The attribute should be reserved for the 1-3 resources that are truly blocking for the first paint.

What are the risks of abusing preload?

The first risk is saturation of the download queue. Each preloaded resource gets high priority. If you have 6, they all compete for available bandwidth. As a result, the browser may delay downloading the main CSS or critical JavaScript that are not preloaded, ultimately degrading the TTI (Time to Interactive).

The second risk is wasting bandwidth. Preloading a font that only displays in the footer forces the download of a resource that is unnecessary for the first render. On mobile with a data cap, this is problematic. Google never mentions this downside in its statement, which is typical of their simplified communication. [To verify]: no public data from Google on the optimal threshold of resources to preload simultaneously.

When does preload serve absolutely no purpose?

If your resource is already discovered early in the HTML (an image directly in an <img> at the top of the page), the browser will automatically load it with high priority. Preload adds nothing. The same goes for critical inline CSS: there is no need to preload what is already in the DOM.

Resources that do not block rendering should never be preloaded: analytics scripts, fonts used only in the footer, images below-the-fold. For these cases, use lazy loading or prefetch if you anticipate navigation. Preload should remain the exception, not the general rule for all your resources.

How can I identify which resources to preload on my site?

Open Chrome DevTools, go to the Network tab, and load your page while throttling for 3G Fast. Visually identify what element constitutes your LCP (typically a hero image or a text block with a custom font). Check in the waterfall when this resource starts downloading. If it starts after 2-3 seconds, it's a perfect candidate.

For fonts, look in the waterfall for .woff2 files. If they load late (after the CSS), it's because they are discovered late. Preload only the fonts visible above-the-fold: if you use 4 weights of Roboto, preload only Regular and Bold if those are the only ones in the hero. The others can wait.

What syntax should I use and where should I place the preload?

The correct syntax in the <head> is: <link rel="preload" href="/fonts/montserrat-bold.woff2" as="font" type="font/woff2" crossorigin>. The as attribute is mandatory for the browser to apply the correct priority. For fonts, crossorigin is required even if the resource is on the same domain; otherwise, it will be downloaded twice.

Place preloads as high as possible in the <head>, ideally before CSS and scripts. Order matters: the browser processes preloads in the order of discovery. If your LCP is an image, its preload should be first. For images, use as="image" and add fetchpriority="high" to enhance the priority.

What errors should I absolutely avoid?

A classic mistake: preloading a resource and then never using it within 3 seconds. Chrome displays a console warning saying, "The resource was preloaded using link preload but not used within a few seconds." This means you are wasting bandwidth. Ensure that each preloaded resource is genuinely critical for the first paint.

Another pitfall: forgetting the type="font/woff2" for fonts. Without this attribute, the browser cannot optimize the download and may ignore the preload. For CSS, never use as="style" with a media query different from that of the file: the browser will download the resource twice. Lastly, never preload a resource served with a Cache-Control too short: you force a download that will be immediately invalidated.

• Audit the Network waterfall while throttling for 3G to identify critical resources discovered late
• Limit preload to 2-3 resources maximum per page (hero font + LCP image typically)
• Use the complete syntax with as, type, and crossorigin for fonts
• Place preload tags at the top of the <head>, before CSS and scripts
• Check the console for any "preload not used" warnings
• Test the real impact on LCP with Lighthouse before/after to validate the gain