Preload Key Requests: How to Fix It

No Comments
Preload key requests: how to fix it

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.

ResourcePreload it?Why
LCP image in CSS backgroundYesPreload scanner cannot see it
Critical above-fold web fontYesKills the swap/flash, discovered late
LCP image already in <img>Usually noUse fetchpriority="high" instead
Below-fold or lazy imagesNoSteals bandwidth from the fold
Every font in the familyNoOnly the weight the fold uses

How to detect it

  1. Lighthouse: the "Preload key requests" opportunity names late-discovered critical resources and estimates the LCP savings from preloading each.
  2. 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.
  3. 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.
  4. 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 as and type.
  • 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 crossorigin set.
  • 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.

Subscribe to our newsletter!

More from our blog