How to Preload Your LCP Image

Deep
15 Apr, 2026
How to Preload Your LCP Image

How to Preload Your LCP Image (WordPress, Shopify & Next.js)

Key Takeaway: Preloading your LCP image tells the browser to fetch it as early as possible — before it would normally discover it. Adding <link rel="preload"> with fetchpriority="high" in your <head> is the single highest-impact LCP fix available. Most sites see a 200–600ms LCP improvement from this one change alone. It takes under 5 minutes to implement.

Most LCP fixes require server changes, hosting upgrades, or image compression pipelines. Preloading your LCP image requires one line of HTML.

It is the fastest, cheapest, and most impactful LCP fix available — and it is consistently underused because most developers and site owners do not know it exists.

This article covers exactly what preloading does, how to implement it on every major platform, what mistakes to avoid, and how to verify it is working correctly.

If you are still working out what your LCP score is or which element is your LCP element, read what is a good LCP score first — then come back here.

What does preloading your LCP image actually do?

To understand why preloading matters, you need to understand how browsers normally discover images.

When a browser loads a page, it works through a sequence:

  1. Requests the HTML from your server (TTFB)
  2. Starts parsing the HTML top to bottom
  3. Discovers <link> tags in the <head> — loads CSS files
  4. Parses the CSS files
  5. Continues parsing the HTML body
  6. Discovers the <img> tag for your hero image
  7. Requests the hero image

The problem is step 6. By the time the browser reaches your <img> tag in the body, it has already spent time downloading and parsing your CSS files. On a typical page, this means the LCP image is not discovered until 500–1,500ms into the page load — even though the browser has been running the whole time.

Preloading moves the image request to the very beginning of the load process:

Normal: HTML → CSS files → body parsing → image discovered → image loads

Preloaded: HTML → image request starts immediately → CSS files → body → image already loading

The browser starts downloading your hero image at the same time it starts downloading your CSS — instead of waiting until after CSS is parsed. On a 4G connection, this saves 300–700ms of LCP time. On slower connections, the saving is even larger.

The basic preload implementation

Add this single line to your <head>, before any stylesheet links:

html

<head>
  <link rel="preload" as="image" href="/images/hero.webp" fetchpriority="high">

  <!-- your stylesheets come after -->
  <link rel="stylesheet" href="/css/styles.css">
</head>

Position matters. The preload hint must come before your stylesheets in the <head>. If you place it after your CSS links, the browser will start downloading CSS first and the preload loses much of its benefit.

Also add fetchpriority="high" directly on the <img> element in your HTML body:

html

<img
  src="/images/hero.webp"
  width="1200"
  height="600"
  alt="Hero image description"
  fetchpriority="high"
>

The fetchpriority="high" attribute on the <img> tag tells the browser to treat this image as the highest priority download. Combined with the preload hint in<head>, this gives the LCP image the earliest possible start time and the highest possible download priority.

Preloading responsive images with srcset

If your hero image uses srcset to serve different sizes to different screen sizes, the basic preload above will only preload one fixed image. For responsive images, use imagesrcset and imagesizes in your preload link:

html

<link
  rel="preload"
  as="image"
  imagesrcset="
    /images/hero-400.webp 400w,
    /images/hero-800.webp 800w,
    /images/hero-1200.webp 1200w
  "
  imagesizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  fetchpriority="high"
>

This tells the browser which image to preload based on the current viewport width — the same logic your <img srcset> uses. Mobile users preload the 400px image. Desktop users preload the 1200px image. Nobody downloads a larger image than they need.

Your <img> tag should match:

html

<img
  srcset="
    /images/hero-400.webp 400w,
    /images/hero-800.webp 800w,
    /images/hero-1200.webp 1200w
  "
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  src="/images/hero-1200.webp"
  width="1200"
  height="600"
  alt="Hero image description"
  fetchpriority="high"
>

Preloading CSS background images

If your LCP element is a background image set via CSS — common for hero sections styled with background-image — the standard <img> preload approach does not apply. The browser discovers CSS background images even later than <img> tags because it has to download and parse the CSS file first.

For CSS background images, preload the image directly:

html

<link rel="preload" as="image" href="/images/hero-bg.webp" fetchpriority="high">

The preload hint works the same way — it starts the image download immediately, regardless of when the CSS is parsed. The image will be in the browser cache by the time the CSS rule that references it is processed.

How to implement preloading on every platform

WordPress (without a plugin)

Add the preload hint to your theme's <head> by editing header.php:

php

// In your theme's header.php, inside <head>:
<link rel="preload" as="image" href="<?php echo get_template_directory_uri(); ?>/images/hero.webp" fetchpriority="high">

If your hero image is set through the WordPress Customizer (theme options), use get_theme_mod() to dynamically output the correct image URL:

php

<?php
$hero_image = get_theme_mod('hero_image');
if ($hero_image) {
  echo '<link rel="preload" as="image" href="' . esc_url($hero_image) . '" fetchpriority="high">';
}
?>

Place this before wp_head() in your header.php.

WordPress with WP Rocket

WP Rocket has a built-in LCP preload feature:

  1. Go to WP Rocket → Media
  2. Enable "Preload LCP Image"
  3. WP Rocket automatically detects your LCP element and adds the preload hint

This is the easiest WordPress implementation — no code editing required. WP Rocket also handles the fetchpriority="high" attribute automatically.

WordPress with RankMath or manual theme editing

If you are not using WP Rocket, use the "Insert Headers and Footers" plugin:

  1. Install Insert Headers and Footers
  2. Go to Settings → Insert Headers and Footers
  3. Paste the preload <link> tag in the Header section
  4. Save

This avoids editing theme files directly — useful if you are on a theme you cannot modify or do not want to touch.

Shopify

In Shopify, edit your theme's theme.liquid file:

  1. Go to Online Store → Themes → Edit code
  2. Open layout/theme.liquid
  3. Find the <head> section
  4. Add the preload link before any {{ 'style.css' | asset_url | stylesheet_tag }} lines:
liquid
{%- if section.settings.hero_image != blank -%}
  <link
    rel="preload"
    as="image"
    href="{{ section.settings.hero_image | image_url: width: 1200 }}"
    fetchpriority="high"
  >
{%- endif -%}

For the Shopify Dawn theme, the hero image is set in the main-banner section settings. Adjust the section and setting names based on your theme.

Next.js

In Next.js, use the <Head> component to add the preload hint:

jsx
import Head from 'next/head';

export default function HomePage() {
  return (
    <>
      <Head>
        <link
          rel="preload"
          as="image"
          href="/images/hero.webp"
          fetchpriority="high"
        />
      </Head>
      <main>
        <img
          src="/images/hero.webp"
          width={1200}
          height={600}
          alt="Hero image"
          fetchPriority="high"
        />
      </main>
    </>
  );
}

Note: In Next.js, use fetchPriority (camelCase) on the <img> element — JSX uses camelCase for HTML attributes.

If you are using next/image, set priority={true} Instead of manually adding the preload hint:

jsx
import Image from 'next/image';

export default function HomePage() {
  return (
    <Image
      src="/images/hero.webp"
      width={1200}
      height={600}
      alt="Hero image"
      priority={true}
    />
  );
}

priority={true} in next/image automatically adds both the preload hint and fetchpriority="high". It is the recommended approach for all LCP images in Next.js applications.

Blogger

On Blogger, you cannot directly edit the <head> HTML for individual posts. However, you can add a preload hint to your theme's <head> for site-wide hero images:

  1. Go to Theme → Edit HTML
  2. Find the <head> section
  3. Add your preload link directly before </head>

For post-specific hero images on Blogger, the most practical approach is to ensure your first post image has explicit dimensions  fetchpriority="high" via an HTML block in the post editor. This does not add a preload hint but does ensure the browser prioritises the image correctly.

If your Blogger site is struggling with page speed beyond just the LCP image, see why your Blogger page speed is low for a full walkthrough of Blogger-specific performance issues.

Critical mistakes to avoid

Mistake 1: Preloading with lazy loading on the same image

This is the most common and most damaging LCP mistake on the web:

html

<!-- WRONG — these two attributes directly contradict each other -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

<img src="/hero.webp" loading="lazy" alt="Hero">

loading="lazy" tells the browser to delay loading the image until it enters the viewport. rel="preload" tells the browser to load the image immediately. They cancel each other out — or worse, the lazy loading wins, and the preload is wasted.

Never add loading="lazy" to your LCP image. For all other images below the fold, lazy loading is correct. For the LCP image specifically, it must be removed.

This is especially common on WordPress sites where image optimisation plugins apply loading="lazy" globally to all images. Check your plugin settings and exclude your hero image from lazy loading.

Mistake 2: Preloading the wrong image

If your LCP element changes between desktop and mobile (different hero images, different layouts), preloading a fixed image URL may preload the wrong image for some users.

Use media queries in your preload hint to preload the correct image for each viewport:

html

<!-- Preload mobile image for small screens -->
<link
  rel="preload"
  as="image"
  href="/images/hero-mobile.webp"
  media="(max-width: 768px)"
  fetchpriority="high"
>

<!-- Preload desktop image for large screens -->
<link
  rel="preload"
  as="image"
  href="/images/hero-desktop.webp"
  media="(min-width: 769px)"
  fetchpriority="high"
>
Mistake 3: Preloading too many images

Preloading tells the browser to treat an image as the highest priority download. If you preload three or four images, they all compete for bandwidth at the highest priority level. The browser cannot meaningfully prioritise between them, and you end up with all of them loading slowly instead of one loading fast.

Preload exactly one image per page — the LCP element. Nothing else.

Mistake 4: Placing the preload hint after stylesheets

The preload hint must come before your stylesheet links in <head>. If it comes after, the browser starts downloading CSS first, and the preload provides minimal benefit.

html

<!-- WRONG — preload after stylesheet -->
<head>
  <link rel="stylesheet" href="/css/styles.css">
  <link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
</head>

<!-- CORRECT — preload before stylesheet -->
<head>
  <link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
  <link rel="stylesheet" href="/css/styles.css">
</head>
Mistake 5: Preloading an image that is not actually the LCP element

Preloading an image that is below the fold or not the largest visible element wastes bandwidth and does nothing for your LCP score. Always confirm which element PageSpeed Insights identifies as your LCP element before implementing the preload.

How to verify your preload is working

Method 1: Chrome DevTools Network panel

  1. Open Chrome DevTools → Network panel
  2. Reload the page with the cache cleared (Ctrl+Shift+R)
  3. Filter by Img type
  4. Look at your hero image in the waterfall
  5. Check the Priority column — it should show Highest
  6. Check the Initiator column — it should show Preload or Link

If the priority shows as High or Medium instead of Highest, the preload hint is not being read correctly — check its position in <head> and make sure fetchpriority="high" is present.

Method 2: PageSpeed Insights

Run PageSpeed Insights before and after implementing the preload. Look for two changes:

  • The LCP time should decrease
  • The diagnostic "Preload Largest Contentful Paint image" should disappear from the Opportunities section

If PageSpeed Insights still shows the preload opportunity after your implementation, the preload hint is either missing, in the wrong position, or pointing to the wrong image URL.

Method 3: Chrome DevTools Performance panel

  1. Open Performance panel
  2. Click the record button and reload the page
  3. Stop recording
  4. Find the LCP marker in the timeline
  5. Look at the image download bar — it should start very early in the timeline, close to when the HTML finishes loading

A successfully preloaded LCP image starts downloading within the first 200–300ms of the page load. An unpreloaded image typically does not start until 800–1,500ms in.

How much LCP improvement can you expect?

The improvement from preloading your LCP image varies based on your current setup:

Scenario Typical LCP Improvement
Image in <img> tag, no preload, fast server 200–400ms
Image in <img> tag, no preload, slow server 300–600ms
Image as CSS background, no preload 500–900ms
Image in JavaScript-rendered component 600–1,200ms
Image already preloaded, but no fetch priority 100–200ms additional

These are typical ranges based on real-world implementations. The actual improvement depends on your server speed, CDN setup, image file size, and the connection speed of your users.

If your TTFB is slow (above 800ms), fix that first — preloading an image from a slow server still results in a slow LCP. See how to fix slow server response time for the full TTFB fix guide.

Preloading in context — how it fits with other LCP fixes

Preloading is one part of a complete LCP fix strategy. Here is how it connects to the other fixes:

Preloading + fast TTFB = maximum impact A preloaded image from a server with a 200ms TTFB starts loading at approximately 200ms. A preloaded image from a server with a 1,500ms TTFB does not start loading until 1,500ms. Fix TTFB first to get the full benefit of preloading.

Preloading + image compression = faster download after discovery. Preloading gets the image discovered early. Image compression makes the download fast once it starts. Both are needed. A preloaded 3MB image is still slow. See what is a good LCP score for the full list of factors that affect LCP time.

Preloading + no render-blocking resources = earliest possible paint. Even with a preloaded image, if your page has render-blocking CSS or JavaScript, the browser cannot paint the LCP element until those resources finish loading. Remove render-blocking resources to allow the preloaded image to paint as soon as it finishes downloading.

Preloading + explicit image dimensions = no CLS. Always add width and height attributes to your LCP image alongside fetchpriority="high". Preloading gets the image fast. Explicit dimensions prevent the layout shift when it loads. Both together give you good LCP and good CLS simultaneously. For a full guide to preventing layout shift, see what causes cumulative layout shift.

Frequently asked questions

Q1. What is the difference between preload and prefetch? 

rel="preload" downloads a resource immediately because it is needed for the current page. rel="prefetch" downloads a resource in the background because it might be needed for the next page visit. For your LCP image, always use preload — never prefetch. Prefetched resources have the lowest download priority and will not help your LCP score.

Q2. Should I preload every image on my page? 

No. Preload exactly one image — your LCP element. Preloading multiple images dilutes the priority signal and can actually slow down your LCP by competing for bandwidth. Every other image on the page should either use loading="lazy" (below the fold) or default browser priority (above the fold but not the LCP element).

Q3. Does preloading work for all image formats? 

Yes. The rel="preload" as="image" Hint works for WebP, AVIF, JPEG, PNG, and SVG. If you are serving different formats to different browsers using <picture> multiple <source> elements, use the imagesrcset approach with type attributes to preload the correct format for each browser.

Q4. My LCP image is loaded by JavaScript. How do I preload it? 

If your LCP image is rendered by a JavaScript framework (React, Vue, Angular) and is not present in the initial HTML, the browser cannot discover it early, regardless of preloading. The fix is to either server-side render the component containing the LCP image so it appears in the initial HTML, or add a preload hint that points to the known image URL, even if the <img> element is JavaScript-rendered.

Q5. Does preloading help on mobile? 

Yes — and the impact is often larger on mobile than on desktop. Mobile connections have higher latency, which means the delay between the browser being ready to load an image and the image actually starting to download is longer. Preloading eliminates this latency by starting the download before the browser would normally discover the image.

Q6. Will preloading hurt my other page load metrics? 

Preloading one image  fetchpriority="high" slightly delays other resources because the browser prioritises the preloaded image above everything else. In practice, this is always a worthwhile tradeoff — LCP improvement far outweighs any minor delay to non-critical resources. Do not preload multiple images or resources that are not needed for the initial render.

Q7. My preload is implemented, but PageSpeed Insights still flags it. Why? 

The most common reasons are: the preload <link> is after your stylesheets in <head>, the href URL does not exactly match the src used in your <img> tag (including query strings, CDN domains, and image transformation parameters), or the preloaded image is not actually the LCP element on the page. Check all three carefully.

Summary

Preloading your LCP image is the single highest-impact LCP fix available for the effort involved. One line of HTML in the right place can save 300–600ms of LCP time — often the difference between a failing and a passing score.

The implementation:

html

<!-- In <head>, before stylesheets -->
<link rel="preload" as="image" href="/your-hero-image.webp" fetchpriority="high">
html
<!-- On the <img> element -->
<img src="/your-hero-image.webp" width="1200" height="600" alt="Description" fetchpriority="high">

The rules:

  • Place the preload before the stylesheets in <head>
  • Never combine with loading="lazy" on the same image
  • Preload exactly one image per page
  • Verify it is working in Chrome DevTools Network panel

Once your LCP image is preloaded, work through the remaining LCP fixes — server response time, image compression, and render-blocking resources. The complete Core Web Vitals guide covers all of them in order of impact.

Author Image

Hardeep Singh

Hardeep Singh is a tech and money-blogging enthusiast, sharing guides on earning apps, affiliate programs, online business tips, AI tools, SEO, and blogging tutorials. About Author.

Previous Post