fetchpriority and loading=eager for Critical Image Fallbacks

Why it matters

fetchpriority keeps LCP images from waiting in the resource queue

Browsers assign a default priority to every resource based on type and document position. Images are medium priority by default, which means the browser can start loading CSS and blocking scripts before fetching your hero image. On a constrained connection this ordering costs real milliseconds at the top of the page.

When a fallback image is the largest visible element at page load — a hero banner placeholder, an 800×400 product photo, a full-bleed section background — it often becomes the LCP element. Without fetchpriority=high, that image waits in the same queue as deferred scripts and web fonts.

Adding fetchpriority=high moves the request to the high-priority network queue. The preload scanner picks it up earlier, before layout is complete. On a 4G connection this change can reduce LCP by 200–500ms. On slower connections the improvement is larger because more requests compete for limited bandwidth.

Syntax

Adding fetchpriority=high to a fallback img element

The fetchpriority attribute accepts three values: high, low, and auto. Auto is the default and lets the browser decide based on context. High tells the browser to treat this resource as competing with the most important requests on the page. Low explicitly deprioritizes decorative or offscreen content.

For fallback images, apply high only when the image is visible on initial render and large enough to be an LCP candidate. Use low for decorative fallback images in grids or sections below the fold where delaying the fetch has no impact on perceived performance.

<!-- Above-the-fold hero fallback: high priority, eager load -->
<img
  src="https://fallback.pics/api/v1/1200x630/7C3AED/FFFFFF?text=Product+Hero"
  width="1200"
  height="630"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  alt="Product hero image"
/>

<!-- Below-fold product grid item: low priority, lazy load -->
<img
  src="https://fallback.pics/api/v1/400x300/E4E4E7/71717A?text=Product"
  width="400"
  height="300"
  fetchpriority="low"
  loading="lazy"
  decoding="async"
  alt="Product placeholder"
/>

Loading attribute

loading=eager vs loading=lazy for above-the-fold content

The loading attribute controls when the browser initiates a fetch, not how it prioritizes the request. loading=lazy defers the fetch until the image is near the viewport threshold. loading=eager, which is the default, fetches immediately regardless of scroll position.

When you combine fetchpriority=high with loading=eager, you get two distinct benefits: the image is not deferred (eager), and it competes at the front of the network scheduler (high priority). For fallback placeholder images in the initial viewport, this combination produces the fastest possible render time.

Never set loading=lazy on any image that appears above the fold. Lazy loading triggers a fetch only when the image enters the viewport proximity threshold, which on mobile can be several hundred milliseconds after initial render. This delays LCP even when the image is immediately visible to the user.

LCP candidate

Fallback images as Largest Contentful Paint elements

The LCP metric measures the render time of the largest image or text block visible in the viewport at load. Browsers consider img elements, CSS background images loaded via url(), video poster frames, and SVGs with intrinsic size as LCP candidates.

Fallback placeholder images from fallback.pics are standard img elements with explicit width and height. When used for a hero or banner section, the placeholder will be the LCP element until the final image arrives — or permanently, if the fallback is the intentional loading state.

This means fallback image performance directly impacts Core Web Vitals scores. If the fallback takes 2.2 seconds to load, your LCP is 2.2 seconds regardless of when the actual image arrives. Treat the fallback URL with the same performance discipline as the real asset.

Preload scanner

Dynamically inserted fallbacks bypass the preload scanner

The browser preload scanner reads raw HTML before the DOM is fully constructed. It finds img src attributes and link rel=preload tags and queues their fetches early in the page lifecycle. This is why static img tags load faster than JavaScript-injected images — the scanner sees them first.

If your fallback src is set via JavaScript — an onerror handler, a React state update, or a framework component with conditional rendering — the preload scanner cannot see it. The fetch starts only after JavaScript executes, which is after the initial parse and at least one render cycle.

For critical fallback images, declare the fallback URL as the initial src in static HTML rather than injecting it later. If the primary image URL is unknown at render time, set the placeholder as the src server-side before sending the HTML response.

Framework usage

fetchpriority in React, Vue, and Astro image components

React supports fetchpriority as a camelCase JSX prop: fetchPriority='high'. Vue passes it as a standard HTML attribute. In Astro, use the HTML attribute directly. The underlying browser behavior is identical regardless of which framework wraps it.

The priority should be determined by where the image appears, not by whether it is a fallback. An above-the-fold placeholder deserves the same high priority as the final image it temporarily replaces. Pass the priority prop based on the image's visual position, not its content state.

// React: hero image with fetchpriority and eager loading
function HeroImage({ src, alt }: { src?: string; alt: string }) {
  const fallback =
    "https://fallback.pics/api/v1/1200x630/7C3AED/FFFFFF?text=Hero";
  return (
    <img
      src={src || fallback}
      width={1200}
      height={630}
      fetchPriority="high"
      loading="eager"
      decoding="async"
      alt={alt}
      onError={(e) => {
        e.currentTarget.src = fallback;
      }}
    />
  );
}

Audit checklist

Verify fetchpriority is working before deploying

Open DevTools Performance panel and run a page load trace. Find the LCP candidate callout in the timing lane. If the LCP element is your placeholder image loading at medium priority, fetchpriority=high is the correct fix.

Cross-check in the Network panel: requests with fetchpriority=high show as Highest or High in the Priority column. If your image still shows as Medium, verify the attribute is on the correct img element and not being overridden by a JavaScript framework's rendering pass.

# API reference and docs
https://fallback.pics/docs/
https://fallback.pics/placeholder-image-api/

# Related posts
https://fallback.pics/blog/lcp-optimization-failed-hero-images/
https://fallback.pics/blog/core-web-vitals-cls-missing-images/