
TL;DR
This audit spots a render-critical file, usually your LCP image or a critical web font, that the browser discovers late because it is buried in CSS or injected by script. A preload hint tells the browser to fetch that exact file immediately, at high priority, instead of waiting to trip over it. Add <link rel="preload"> for the one or two resources that gate your first meaningful paint, and resist the urge to preload everything.
What this check flags
The browser builds its request queue from what it can see while parsing HTML top to bottom. Some critical files hide from that scan: a hero image referenced only inside a CSS background-image rule, a font declared in an @font-face block the browser reaches late, or a script that injects another script. This check fires when a resource that matters for the initial render is discovered too late, so it starts downloading well after it should have.
The consequence is a slow Largest Contentful Paint. If your LCP element is a background image the parser cannot see until the stylesheet is fetched and parsed, the single most important pixel on the page waits in line behind everything the browser found first.
Preload fetches the file, early
Where preconnect only warms a connection, preload actually downloads the file and hands it to the browser at elevated priority, ready the moment the renderer asks for it. You name the URL and the resource type so the browser fetches it correctly:
<!-- Pull the LCP hero forward, before CSS reveals it -->
<link rel="preload" as="image"
href="/img/hero-1600.avif" type="image/avif" fetchpriority="high">
<!-- Critical font, so text paints without a swap flash -->
<link rel="preload" as="font" type="font/woff2"
href="/fonts/inter-var.woff2" crossorigin>The traps: the as attribute is required, and a wrong value makes the browser fetch the file twice, so you have doubled the download instead of speeding it up. Fonts need crossorigin even when same-origin, for the same CORS reason as their preconnect. And a preloaded file you do not use within a few seconds earns a console warning, because you paid for a download that helped nothing.
What is worth preloading (and what is not)
Preload is a scalpel, not a broom. It steals bandwidth from other requests, so every preload must earn its priority.
| Resource | Preload it? | Why |
|---|---|---|
| LCP image in CSS background | Yes | Preload scanner cannot see it |
| Critical above-fold web font | Yes | Kills the swap/flash, discovered late |
LCP image already in <img> | Usually no | Use fetchpriority="high" instead |
| Below-fold or lazy images | No | Steals bandwidth from the fold |
| Every font in the family | No | Only the weight the fold uses |
How to detect it
- Lighthouse: the "Preload key requests" opportunity names late-discovered critical resources and estimates the LCP savings from preloading each.
- PageSpeed Insights: run the URL and cross-check the opportunity against the LCP element it identifies in the diagnostics, so you preload the right file.
- DevTools Performance panel: record a load, find the LCP marker, and trace back to when its resource request started. A late start with idle network before it is your signal.
- DevTools Network panel: sort by start time. If a render-critical file begins downloading after non-critical assets, it was discovered too late.
How to fix it
- Preload the LCP resource when it is hidden from the parser (CSS backgrounds, script-injected images) with the correct
asandtype. - Reach for
fetchpriority="high"first on a normal<img>. It bumps priority without the double-download risk of a mis-typed preload. - Preload only fold-critical fonts, the single weight your visible text uses, with
crossoriginset. - Stay disciplined. One or two preloads. Every extra one competes with the resources that actually gate paint, which is self-defeating.
For the bigger LCP picture, our guide to improving Largest Contentful Paint and the preload glossary entry cover the surrounding tactics.
FAQ
Should I preload my LCP image if it is already an <img> tag?
Usually not. The preload scanner already sees an <img> in the HTML, so adding fetchpriority="high" to that tag is simpler and safer. Reserve preload for LCP images the parser cannot discover, like CSS backgrounds or script-injected sources.
Why did I get a "preloaded but not used" warning?
The browser downloaded the file you preloaded but nothing requested it within a few seconds, so the bandwidth was wasted. It usually means a wrong as value, a stale URL, or a resource that turned out not to be needed. Fix the attribute or drop the preload.
Does preload replace preconnect?
No, they complement each other. For a critical file on a third-party origin you can preconnect to warm the connection and preload to fetch the file, though a preload to a cold origin already opens the connection as part of the fetch.
Can I preload too much?
Easily. Preload elevates priority, and if everything is high priority then nothing is. Extra preloads pull bandwidth away from the genuine critical path and can push your LCP later, the opposite of what you wanted.
Why do preloaded fonts need crossorigin on my own domain?
Font fetches always use CORS-anonymous mode, even same-origin. A preload without crossorigin is treated as a different request than the actual font fetch, so the browser downloads the font twice. Always set crossorigin on font preloads.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.







