# Does preloading the hero image actually improve Shopify LCP? | Storefront Speed Journal Source: https://storefrontspeedjournal.com/blog/2026-09-25-shopify-preload-hero-lcp.html Sep 25, 2026 - Storefront Speed Journal Preloading the hero image shows up in almost every Shopify speed guide, and the advice is usually sound: telling the browser early about the image that will become your Largest Contentful Paint lets it start downloading sooner. But preload is not a magic switch. Applied to the wrong image, or to an image that is not really the LCP element, it does nothing at best and steals bandwidth from more important resources at worst. Here is when it helps and when it backfires. ## When it helps Preload helps when the LCP image is discovered late. That is the normal case on Shopify: the hero image is often set as a CSS background, or it sits inside a section whose markup the browser parses after other content, or it is injected by a theme script. In those cases the browser only learns about the image partway through parsing, and a preload link in the head starts the download seconds earlier. The earlier the discovery, the earlier the paint. The gains are real when the image is genuinely the LCP element on the template you care about. Confirm it first: run PageSpeed Insights on a product or collection page and check which element it names as LCP. If it names the hero image, preload is a reasonable move. If it names a text block or a different image, preloading the hero fixes nothing. ## When it does nothing If the hero image is a plain img tag high in the markup, the browser's preload scanner probably finds it already. The scanner reads ahead of the parser specifically to discover images early, so adding an explicit preload for an image it would have found anyway changes little. The same goes for images that are not the LCP element: preloading a logo or a secondary banner does not move LCP, because LCP measures one specific element. Preload also does nothing if the image is lazy-loaded. Lazy loading defers offscreen images, and preloading one of them is a contradiction: you are telling the browser the image is both urgent and deferrable. If a theme lazy-loads the hero image, remove the lazy loading from that one image instead of adding preload on top of the contradiction. ## When it makes things worse Bandwidth is finite, and preload promotes the image in the download queue. Preloading a large hero image can delay the CSS, the fonts, or the scripts that the page needs to render anything at all. If the preloaded image is oversized, if it is served in a heavy format, or if there are several preloads competing, the net effect can be a slower page with a technically earlier image download. Preload one image, not five. The classic backfire is preloading a mobile hero image that desktop visitors never see, or vice versa. Responsive images with different sources per breakpoint mean there is no single "hero image" to preload. Preloading the desktop variant on mobile wastes the preload and downloads bytes the visitor never uses. Use media attributes on the preload link so each device preloads only its own image, or skip preload and fix discovery another way. ## The better fix order Before reaching for preload, fix the underlying discovery problem. If the hero is a CSS background, move it to a real img element where possible; img tags are discoverable and preloadable, backgrounds are neither. If the theme injects the hero via JavaScript, that is the thing to fix. Preload is a patch over late discovery, and the patch works best when the wound is small. Also check the image itself. A preloaded 3MB hero still paints slowly. Compress it, serve it in a modern format, and size it to the actual rendered dimensions before optimizing its discovery. Preload multiplies the benefit of a well-prepared image and multiplies the cost of a badly prepared one. ## How to verify it worked Measure before and after with the same tool on the same template, and use field data where you can. A lab run that shows LCP improving by half a second is encouraging, but real-user data across a week of traffic is the verdict. If the lab number improves and the field number does not, something else is the binding constraint, and it is time to look at what the field data names as the problem instead of what the guides recommend. ## Frequently asked questions ### Does preloading the hero image always improve LCP? No. It helps when the hero image is the Largest Contentful Paint element and the browser was discovering it late. If your LCP element is text, a video, or a script blocked render, preloading an image changes nothing measurable. Confirm the LCP element first, then preload. ### Can preloading a hero image make performance worse? Yes, when the preloaded file is not the one the device displays, such as a desktop image pushed to mobile, or when several assets are preloaded at once and compete for bandwidth. A wasted preload consumes the early connection budget that critical resources needed. ### Should I preload every slide in a hero slideshow? No. Preload the first slide only. Preloading the full rotation downloads images many visitors never see and recreates the priority problem the hint exists to solve. If the slideshow causes unstable LCP readings, a single static hero is worth considering. ### How do I verify a preload worked? Check the network waterfall in a throttled test: the hero should start downloading early and only once, in the size that device uses. Then watch field LCP over the following weeks, since real user data updates on a rolling window and will not move overnight.