The Shopify LCP Render Delay Your Image Fixes Can't Move

Open PageSpeed Insights on your store. Scroll to the Largest Contentful Paint entry in the diagnostics section, click the small expand arrow next to it, and read the four sub-phase numbers that appear underneath. If the fourth one, element render delay, is over 500ms, most of the speed advice you have been reading is aimed at the wrong part of the timeline. I spent two months last year giving that advice myself before I stopped and actually looked at the phase breakdown.

Quick answer: when LCP render delay is the dominant phase, compressing the hero image will not move the score. What the page is waiting on is the browser's main thread, which is busy running Shopify's own platform scripts, your web font, and usually a slice of render-blocking CSS from your theme.

The screenshot that made me stop optimizing images

A merchant on the Shopify community forum, posting under ZohaibAsif001, put their LCP breakdown up in early August. I remember reading it and feeling something between recognition and mild professional shame.

• TTFB: 10ms
• Resource load delay: 130ms
• Resource load duration: 20ms
• Element render delay: 2,140ms

The image finished downloading in 20 milliseconds. The browser then waited 2.14 seconds before painting it. Everything below the image request in the waterfall, all the srcset work, the fetchpriority hint, the compression from 115KB to 23KB, was already fine. They had spent two days on the wrong problem and still had 2.14 seconds of LCP render delay to explain.

I have shipped fix lists that started with "compress your hero" more times than I would like to count. The reason it happened, and keeps happening, is that "compress your hero" is the only advice most page-speed articles have. The other three phases in the LCP total barely get discussed. When a merchant lands on a store audit expecting an image checklist, an image checklist is what most auditors deliver.

What I checked first, and what wasn't it

When a merchant sends me a store with LCP over 4 seconds and asks me to look, my first three moves used to be predictable. Compress the hero. Add fetchpriority="high". Make sure the first image is not lazy-loaded. In roughly a third of the stores I saw, none of that moved the score more than a few tenths of a second.

That is the pattern LCP render delay creates. The image is small, the priority hint is correct, the loading attribute is right, and the number does not move because the number is not measuring what you are fixing. The image is downloaded and sitting in memory. The browser will not paint it until the main thread lets go.

I used to think this was a Shopify Plus story, some heavy-app edge case that did not apply to smaller merchants. It is not. A Reddit thread from earlier this month walked through the numbers on a stock Horizon dev store with zero apps installed: 212 first-party JavaScript requests, roughly 1.19 MB of Shopify's own JavaScript, DOMContentLoaded at 768ms, TTFB at 159ms. That is what every merchant is starting from before they install anything. You cannot compress your way through it.

The four phases nobody expands in PSI

The expand arrow next to the LCP entry in PageSpeed Insights is small and easy to miss. Click it and you get four numbers, and the four numbers are the whole diagnostic. They are the total LCP broken into sequential parts:

1. TTFB - your server's time to first byte. On Shopify this is usually 100 to 300ms and there is very little a merchant can do about it.
2. Resource load delay - the gap between TTFB and when the browser starts fetching the hero image. Preload lives here.
3. Resource load duration - the download itself. Compression, WebP, srcset, and CDN resizing all live here.
4. Element render delay - the gap between the image finishing its download and the browser committing to paint it.

If one number dwarfs the others, that phase is your problem, and the fixes for one phase do almost nothing for the others. A 20ms download time cannot be improved by making the image smaller. A 2,140ms render delay cannot be improved by making the image faster.

The mistake I made for years was reading the LCP total and skipping the breakdown. I read "your LCP is 4.2s" and reached for the image tool. If I had clicked the arrow, I would have seen a small download duration and a huge render delay staring back, and the fix would have been a different fix from a different section of the theme.

The main thread was busy with Shopify itself

The Chrome DevTools Performance panel is where you find out what the browser is actually doing during element render delay. Set CPU throttle to 4x, record a page load, find the LCP marker on the timeline, and zoom in on the window between the LCP image's responseEnd event and the marker itself.

What you see in that window, on almost every store I look at, is a stack of tasks in this order:

• Shopify's own shop-js/modules/v2 initialization, platform code that is not removable
• The Web Pixels sandbox loader, also platform code, also not removable
• A web font resolving in the critical path, usually fixable
• One or two third-party app scripts loading synchronously from content_for_header, sometimes fixable
• Theme JavaScript initializing carousels, cart drawers, or reveal animations

The first two contribute the LCP render delay floor. Every zero-app Shopify store carries them. In the 204-Lighthouse-audit benchmark that circulated on r/shopify in September, the fastest LCP anyone got on any stock 2.0 theme was 1.23 seconds, on Expanse, with nothing installed. That is the ceiling of what stock Shopify allows, not a target most real stores will hit.

Once I understood the floor, I stopped promising merchants LCP under 1 second on Shopify. I aim for the "Good" band, roughly 2 to 2.5 seconds on mobile, and I tell people that up front rather than after two weeks of scrolling through PSI reports. If you want a second pair of eyes on your phase breakdown before you spend a weekend chasing a number that is not achievable, the first 15 minutes with a help1 expert is free and that is usually enough time to spot which phase is dominant.

Fonts and CSS: what I could actually move

The removable share of LCP render delay is smaller than you would hope and larger than nothing. On the August case study I keep coming back to, the community identified three specific sources beyond the platform floor: a hosted web font resolving at roughly 2.9 seconds in the critical path, three render-blocking CSS files summing to about 490ms, and a handful of app scripts. The font was the biggest single lever.

Web fonts in the critical path are the render delay source I fix first because I trust the mechanism and the change is small. Shopify's Liquid font_face filter accepts a font_display: 'swap' argument. Generic CSS @font-face edits do not apply, because Shopify rewrites the font URL on the way out. Preload the primary font file with <link rel="preload" as="font" crossorigin> in the theme head. Subset the font by weight or by character set if you can. A font that resolves at 2.9 seconds is a 2.9-second contribution to render delay regardless of what the image is doing.

CSS is messier. Theme-compiled CSS on Horizon and Dawn is usually what PSI flags as render-blocking, and it is also the CSS that styles your hero image container. Deferring it makes the LCP element paint without its styles first, which is visible flicker and sometimes a layout shift. There is no clean way I know of to defer Shopify's compiled stylesheet without breaking cart drawers, carousels, and product-page search. I have tried. What I do instead is remove render-blocking CSS added by apps, not by the theme, and I accept the theme CSS as part of the floor.

What we changed, in the order I would do it again

Here is the sequence I now walk merchants through when the phase breakdown points at render delay. Each step should measurably reduce the render delay number in PSI before you move to the next. If it does not, you found a dead end and should back out the change.

1. Read the phase breakdown first. If element render delay is under 200ms, close this article and go back to image work. If it is over 500ms, keep reading.
2. Fix the web font. Add font_display: 'swap' inside the Liquid font filter, preload the primary weight with a crossorigin link tag, and if you have never opened the Network tab to check when your font actually resolves, this is a good afternoon.
3. Audit the head for synchronous app scripts. Chrome DevTools, Sources tab, Page view. Anything third-party loading from <head> before the LCP image request is contributing. Remove the apps you can, and use app blocks pinned to specific pages for the ones you cannot fully remove.
4. Check for opacity transitions on the hero section. Shopify's own performance team documented a Case-Mate store where a reveal attribute applied opacity: 0 and the fade-in only fired when theme.js completed its initialization about 12 seconds in. Removing the transition took LCP from 12 seconds to 7 seconds with no image change. Search your sections/image-banner.liquid (or theme equivalent) for opacity, reveal, is-loaded, or animate classes on the hero. If you find one, extract or delete.
5. Check the carousel library. Swiper, Splide, and Slick each weigh 30 to 40KB and block the main thread when loaded synchronously. Add defer to the script tag, or lazy-initialize the carousel on slides after the first. The first slide can render as a static image while the library boots.
6. Then, and only then, revisit the image. WebP, srcset, dimensions, priority hints. If element render delay is already below 300ms, the image fixes will move the number you care about. If it is not, phases 3 and 4 will keep arguing over the same 200ms.

I want to name one caveat: I have not run step 4 on Shopify Plus stores using theme extensions with heavy custom JavaScript on top of Horizon. The mechanism is the same, but the search path may be different if the reveal attribute lives inside an app block rather than a section file. If someone reading this has done it on Plus, or inside a Hydrogen storefront, I would like to compare notes.

For a mental model of what the four phases look like when the download itself is the story, I wrote up a plainer hero image LCP case study a while back. The two posts are best read together: that one covers phase 3, this one covers phase 4 (LCP render delay), and knowing which phase you are in is most of the diagnosis on Shopify.

One quiet closing thought

Page speed on Shopify is one of those problems where the phase breakdown was always inside the tool; the fix has always been to click the arrow and look, and most of us just did not until the image work stopped moving the score.