Key takeaways
- The 80% cut in hero image weight came from three changes made together: AVIF at the correct size, removing a render-blocking web font, and deferring third-party scripts. Compression alone would not have done it.
- Mobile Largest Contentful Paint (LCP) is the metric that tracks lost sales on an ecommerce homepage. It measures how long the biggest visible element, usually the hero, takes to appear.
- Most Shopify themes load review widgets, chat tools and marketing pixels before the hero image. That is the most common cause of a slow mobile LCP.
- A theme tune-up fixes symptoms. A headless storefront lets you control render order in code, which is why speed rescues on themes tend not to last.
- Fixed-price speed audits and rebuilds start at $2,000, quoted in writing after a free 30-minute call. No hourly billing.
What actually moves mobile LCP on an ecommerce homepage
An ecommerce site speed fix that holds up comes down to three things: how heavy the hero image is, whether a web font blocks the first paint, and whether third-party scripts load before the product does. Get those three right and mobile LCP drops. Leave any one of them alone and the other two only partly help.
Google's standard is clear. LCP needs to happen within 2.5 seconds for a good score, and anything above four seconds is poor. Field data shows only around 62% of mobile sites hit the 2.5-second threshold. Premium stores with large lifestyle photography tend to sit in the other 38%.
Why LCP matters more than PageSpeed score
The PageSpeed score is a lab number, blended from several metrics and run on a simulated device. LCP is the moment a shopper on a real phone sees your product. That is the moment they decide whether to stay.
For core web vitals ecommerce work, Google defines a good page as one with LCP at or under 2.5 s, INP at or under 200 ms and CLS at or under 0.1. INP measures how quickly the page responds to a tap. CLS measures how much the layout jumps while it loads. Both matter. On a homepage, though, LCP is the one shoppers feel first.
The three levers: image weight, font blocking, script order
- Image weight. The hero is usually the LCP element. Every kilobyte has to cross a mobile connection before it can paint.
- Font blocking. If the browser waits for a font file before drawing text, the whole hero section can wait with it.
- Script order. Apps and pixels that start downloading early take bandwidth and main-thread time away from the hero.
Before any work starts, we audit all three and put a fixed price in writing.
The teardown: before and after on a real homepage
This is a premium ecommerce homepage with a full-bleed product photograph as the hero, running on Shopify. The anchor figure: mobile hero weight fell by 80%. Here is where that 80% came from.
Hero image: from a 2.4MB JPEG to a sized AVIF
The hero was a 2.4MB JPEG, uploaded at full camera resolution and served to every device at the same size. A phone with a 390-pixel-wide screen was downloading an image built for a large monitor.
We re-exported it as AVIF, generated several widths, and let the browser pick the one that matched the screen. The shot looked the same. The file on a phone came to roughly a fifth of the original weight.
| Before | After | |
|---|---|---|
| Hero format | JPEG | AVIF, with WebP and JPEG fallbacks |
| Mobile hero weight | 2.4MB | About 480KB (−80%) |
| Sizing | One original upload for every device | Several widths, chosen by the browser via `srcset` |
| Loading priority | Lazy-loaded by the theme | `fetchpriority="high"` and preloaded |
| Web font | Google Fonts stylesheet in the ``, render-blocking | Self-hosted WOFF2, `font-display: swap` |
| Third-party scripts | Reviews, chat and pixels requested before the hero | Deferred until after first paint or first interaction |
What the Lighthouse trace showed before the fix
Lighthouse breaks LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. Server response was not the problem here. The time went on the other three.
Resource load delay was long because the browser found the hero late. The theme lazy-loaded it, and a stack of scripts came first. Load duration was long because 2.4MB is 2.4MB. Render delay was long because the hero headline waited on a font file from a third-party domain. Three causes, three fixes. That is why the result came from shopify site speed optimisation across all three levers rather than from one clever trick.
Fixing the hero image without losing the shot
"Compress your images" is where most advice stops. On its own, it rarely gets a heavy hero under the threshold.
Format: AVIF over WebP over JPEG
AVIF usually produces the smallest file at the same visual quality. WebP comes second and JPEG a distant third. Current guidance for hero sections is to serve AVIF with WebP and JPEG fallbacks, at higher quality (85-90%), since these are focal points. Don't crush the hero to 60% quality to save a few kilobytes. It is the image that sells the product, and the format change does most of the work.
Sizing: serve the pixel dimensions the device needs, not the original upload
This is where most of the weight goes. Generate the hero at several widths, for example 640, 960, 1280 and 1920 pixels. List them in srcset, and tell the browser how wide the image will display with sizes. On Shopify you can do this with the image_url filter and a width parameter for each size. Responsive images combined with modern formats can reduce mobile image delivery by 60-70% compared to single-size traditional formats. On high-traffic stores, smaller files also cut bandwidth bills: one case study found that reducing a hero-scale image to 600 KB reduced CDN egress by 70%.
Priority hints and preloading the hero
- Remove
loading="lazy"from the hero. Lazy loading is for images below the fold. Many themes apply it to everything. - Add
fetchpriority="high"to the hero<img>, so the browser fetches it ahead of other images. - Add a
<link rel="preload" as="image">in the<head>with matchingimagesrcsetandimagesizes, so the request starts before the browser has parsed the rest of the page. - Set
widthandheighton the image, so the layout doesn't shift when it arrives.
Fonts: the render-blocking mistake almost every theme makes
Text on the page waits for its font. If the hero headline is the largest element, or sits inside it, LCP waits too.
Why a Google Fonts link tag blocks the hero
A Google Fonts <link> in the <head> is a stylesheet. The browser treats stylesheets as render-blocking. It has to connect to one domain for the CSS, then a second domain for the font files, before it can paint the text. On a mobile connection, those extra connections cost real time before anything useful appears.
font-display: swap and self-hosting
The fix is short:
- Self-host the font as WOFF2 on your own domain, so there are no extra connections.
- Subset it to the characters you use. A Latin-only site doesn't need the Cyrillic glyphs. A bilingual site needs both scripts, but not five weights of each.
- Preload the one weight the hero uses.
- Set
font-display: swap, so text shows in a fallback font straight away and switches when the brand font arrives. - Tune the fallback with
size-adjust, so the swap doesn't shift the layout and damage CLS.
For core web vitals ecommerce work, this is often the cheapest win on the list: one afternoon, no change to the design.
Third-party scripts: the apps that load before your product does
This is the most common problem on Shopify. One industry index found that third-party apps accounted for 44% of total page load time. Another analysis puts it at 75% on Shopify stores. The same analysis makes the useful point: you don't have to delete the tools. Getting the load order right can improve site speed by 30-60% while maintaining full functionality.
Review widgets, chat and pixels: what to defer
- Review widgets. Nobody reads reviews in the first two seconds. Load them when the review section scrolls into view.
- Chat tools. Show a lightweight button and load the full chat script on first tap.
- Marketing pixels. Load them after first paint, or move tracking to the server side where your platform supports it.
- Pop-ups and upsell apps. Delay them. A discount modal that blocks the hero loses the sale it was meant to win.
One audit found that 62% of all third-party integrations have a negative impact on a site's performance. Also count what you have installed. If you have more than 20 ecommerce plug-ins installed, you likely aren't using them all. Uninstalled apps can leave script tags behind in the theme, so check the code as well as the app list.
How to audit script order in the network tab
- Open the homepage in Chrome, then open DevTools and go to the Network tab.
- Set throttling to a mobile profile and tick "Disable cache".
- Reload the page and sort by the Waterfall column.
- Find the hero image request. Everything that starts above it competed with it.
- Filter by JS and note which domains belong to apps rather than to your store.
- Open the Performance tab, record a reload, and find the LCP marker. Look at what was running on the main thread just before it.
If a review widget or pixel starts before the hero, that is your mobile LCP Shopify problem.
When an ecommerce site speed fix is enough, and when the theme has to go
Sometimes the fix is enough. If the theme is reasonably lean and the problem is one oversized image and a font link, a few days of work will get you under 2.5 seconds and keep you there.
Often it won't last. Six months later, a new app, a new pixel or a theme update puts the scripts back ahead of the hero. We've seen sites carrying this weight for years: Oilcrete, an olive oil mill in Tympaki, Crete exporting to forty-nine countries, ran on a site that, in the mill's own words, "dated from another era of the web." That kind of site rarely needs a nip and tuck. It needs replacing.
Signs the theme is the ceiling, not the content
- Apps inject scripts into the
<head>through Shopify's own hooks, and you can't change their order. - The theme ships JavaScript for sections you don't use, on every page.
- Each theme update overwrites your fixes.
- You have already optimised the images and LCP is still over 2.5 seconds on a real phone.
What changes when the storefront is code you control
In a headless build, the storefront is its own application, in Next.js or Shopify Hydrogen, reading products from Shopify. Checkout stays in Shopify. Because you own the code, you decide what loads first: the hero image, then the text, then everything else.
That is also why speed rescues on themes tend to be temporary. On a theme, you are reordering someone else's code. On a headless storefront, the order is yours. A custom build doesn't mean your team loses control of the content, either. On Lava Space we built a Next.js site on a bespoke CMS, so the studio uploads and organises its own projects, galleries and client logos without calling a developer.
A rebuild costs more than a fix, and it isn't always worth it. We'll tell you plainly which one your site needs before you spend anything.
Frequently asked questions
How do I check my Shopify store's mobile LCP score right now?
Run your homepage through PageSpeed Insights and read the field data at the top, which comes from real Chrome users. The lab result underneath is a single simulated test. Search Console's Core Web Vitals report and the web performance report in your Shopify admin show the same metrics over time.
What's a good Core Web Vitals score for an ecommerce homepage?
Google treats LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1 as good. Check mobile first. That is where most homepages fail and where most shoppers are.
Will compressing images alone fix a slow LCP?
Rarely. Compression reduces file size, but a hero that is lazy-loaded, too large for the screen, or queued behind a font and a dozen scripts will still paint late. Our 80% reduction came from format, sizing, font and script order together.
Does a faster site actually increase ecommerce conversion rate?
Usually, but we won't give you a universal percentage, because the effect depends on your traffic and your product. The honest approach is to measure: record conversion rate and mobile LCP before the work and compare after.
How much does a Shopify speed audit or rebuild cost?
Projects start at $2,000. We quote a fixed scope and a fixed price in writing after a free 30-minute call. There is no hourly billing, and the price you sign is the price you pay.
Can I keep my current theme and just fix the speed issues?
Often, yes. If the theme is lean and the problems are images, fonts and a few scripts, a fix on the theme works and costs less. If apps inject code you can't reorder, or theme updates keep undoing the work, we'll tell you the theme is the limit before you spend money on a rescue.
If your homepage is heavy, book a free 30-minute call. We'll walk through it together and tell you honestly whether a fix or a rebuild is the right move.



