Preload Key Requests.

Performance Asset Optimization

Preloading critical resources starts downloads earlier

What does this check test?

This check identifies critical resources that are discovered late in the loading process and would benefit from being preloaded. By default, the browser discovers resources as it parses HTML and CSS — a font referenced in CSS is only discovered after the CSS file is downloaded and parsed, a JavaScript module imported by another module is only discovered after the parent module is parsed. `<link rel="preload">` tells the browser to start downloading a resource immediately, before it would naturally discover it. This is particularly valuable for resources hidden behind chain dependencies: HTML -> CSS -> Font, or HTML -> JS -> JS module.

Why does it matter?

Resource discovery chains create waterfall loading patterns where each resource must be discovered before the next can start downloading. A font file referenced in a CSS file that is itself referenced in HTML has a 3-step discovery chain — the font download does not begin until the CSS is fully downloaded and parsed. Preloading breaks these chains by starting downloads immediately when the HTML is parsed, potentially saving hundreds of milliseconds per chained resource. For LCP elements that depend on CSS (background images) or fonts, preloading can dramatically improve the LCP score.

Who is affected?

Sites using custom web fonts (loaded via CSS `@font-face`), sites with CSS background images used as hero/LCP elements, sites using JavaScript module dependencies that load additional modules dynamically, and sites with critical resources loaded through CSS `@import` chains are most affected. Single-page applications that lazy-load route bundles can also benefit from preloading the most likely next route.

Where does this apply?

Identify resources with late discovery by examining the waterfall chart in Chrome DevTools Network panel — look for resources that start downloading significantly after page load begins because they depend on other resources being loaded first. Common candidates for preloading: the primary web font file, hero/LCP background images referenced in CSS, critical JavaScript modules loaded via dynamic `import()`, and above-the-fold images referenced in CSS.

How to fix it

Add `<link rel="preload">` tags in the HTML `<head>` for critical late-discovered resources. Be selective — limit preloads to 3-5 truly critical resources. Preload critical fonts, images, and modules:

html

<head>
  <!-- Font (crossorigin required even if same-origin) -->
  <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin />

  <!-- LCP hero image -->
  <link rel="preload" href="/images/hero.webp" as="image" />

  <!-- Critical JS module -->
  <link rel="modulepreload" href="/js/critical-module.js" />
</head>

Use responsive preloading for images:

html

<link rel="preload" as="image"
      imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
      imagesizes="100vw" />

Preloading too many resources reduces the benefit because everything competes for bandwidth.

References

AppVet checks Preload Key Requests automatically

Run a free performance scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit

← All checks