Most storefront teams working on AI visibility have focused on one half of the problem: making conte…
Core Web Vitals in the Storefront: Media Delivery and LCP
For most storefronts, Largest Contentful Paint is not a JavaScript problem. It is one hero image, one product photo, or one video poster frame that arrives too slowly. Fix the media pipeline and the Core Web Vitals score usually follows.
How LCP Is Actually Measured
Largest Contentful Paint measures the render time of the largest visible element in the viewport during page load, typically a hero image, a product photo above the fold, a video poster, or in text-heavy layouts a large text block. Google scores it in three bands: under 2.5 seconds is good, 2.5 to 4 seconds needs improvement, and anything above 4 seconds is poor. These thresholds apply to field data from the Chrome User Experience Report (CrUX), which is what actually affects search ranking, not the lab numbers you see in a local Lighthouse run.
The distinction matters because lab data runs on a fixed connection and device profile. Field data reflects real customers on real connections, including the 3G handset in a train tunnel and the older Android device your analytics dashboard would rather not show you. A storefront that scores 95 in Lighthouse can still post a 3.8-second field LCP once you account for that spread. On e-commerce category and product pages specifically, the LCP element is a media asset in the large majority of cases, which is exactly where the rest of this piece is going.
Why Media Delivery Dominates the LCP Budget
Once you accept that the LCP element on most PDPs and PLPs is an image or a video poster, the LCP budget stops being a framework question and becomes a delivery question. A perfectly optimized Nuxt or Next.js render tree buys you nothing if the hero image request starts late, arrives in the wrong format, or gets throttled behind a third-party script. We have already made the revenue case for this elsewhere: how frontend performance drives revenue walks through the conversion and bounce-rate impact of Core Web Vitals directly. What that piece does not do, and what matters here, is the mechanism: media delivery is the lever that actually moves the LCP number on a typical storefront.
Four failure modes account for most of the damage: oversized source files served without responsive variants, a format mismatch (JPEG where AVIF or WebP would cut payload by 30 to 50 percent), a discovery delay where the browser cannot find the image URL early because it is buried in client-side JavaScript instead of the initial HTML, and third-party or unmanaged CDN latency that adds hundreds of milliseconds before the first byte of the image even starts downloading. None of these are framework problems. All of them are media pipeline problems.
The Image Pipeline: Formats, Responsive Sizes, and CDN Delivery
A media pipeline built for LCP has to get four things right at the same time: format, responsive sizing, discoverability, and caching.
Format selection should default to AVIF with WebP as the fallback and JPEG only as the last resort for edge cases. Responsive sizing means generating a real `srcset` with multiple widths and a correct `sizes` attribute, so a phone downloads a 640px image and not the same 2400px master the desktop gets. Discoverability means the LCP image tag needs to be present in the initial server-rendered HTML, marked with `fetchpriority="high"`, and never wrapped in `loading="lazy"` (a mistake we still see on live storefronts, and it single-handedly adds a full second or more to LCP). Caching means the actual bytes should come from an edge-cached image CDN, not a cold origin fetch on every request.
If you want the deeper mechanics of how an image CDN actually works, including on-the-fly transformation and edge caching, we cover that in detail separately: how an image CDN actually works. The short version for this piece: an image CDN sitting between your storefront and your asset origin is what makes format negotiation, responsive resizing, and edge delivery possible without a build-time asset pipeline per device size.
Video Delivery Pitfalls That Break LCP
Video hero sections are common on category landing pages and campaign pages, and they introduce a second failure surface. If autoplay video sits above the fold, the poster frame, not the video file, is what typically becomes the LCP element, so the same rules apply to the poster: correct format, correct size, high fetch priority. The pitfall is treating the poster as an afterthought while over-engineering the video itself.
The video file has its own failure modes: a single high-bitrate MP4 with no adaptive bitrate ladder, a video player library that blocks the main thread before it even starts fetching, and self-hosted video with no CDN in front of it, which turns every storefront visit into a fresh origin request. Below-the-fold video should lazy-load without exception. Above-the-fold video needs adaptive bitrate streaming and a CDN layer, or it should not autoplay at all on mobile connections, where data caps and variable bandwidth make a large unmanaged video file one of the more expensive things you can put on a page.
A Performance Layer, Not Client-Side Tag Chaos
The common failure pattern is not a lack of effort. It is a stack of client-side band-aids: a lazy-load library, a separate image optimization plugin, a third-party video embed, and a personalization script, each one loaded independently, each one competing for the same main thread and the same network priority, none of them aware the others exist. Every one of these tools was chosen to solve a real problem, and together they create a new one: uncoordinated, unpredictable LCP.
The alternative is treating performance as a platform layer instead of a client-side accumulation of tools. On Composable Headless Frontend, media delivery, responsive image generation, and edge caching are built into the rendering and hosting layer itself, not bolted on afterward per project. That is also the premise behind Frontend as a Service: the storefront, the connect layer, and the cloud delivery layer operate as one managed system, so a performance budget set once applies across every page and every locale, instead of being re-fought by every new marketing script that gets added six months later.
FAQ
Does compressing images alone fix LCP? No. Compression reduces file size but does not fix a wrong format, missing responsive variants, or a delayed discovery path. All four factors (format, size, priority, caching) need to be right together.
What LCP score should an e-commerce storefront target? Aim for field data under 2.5 seconds at minimum, and treat 1.8 seconds as a realistic mobile target. Laioutr's own live frontends report a 1.2-second median LCP in field data, which shows what a properly managed media and hosting layer can achieve.
Can a video ever be the LCP element, and should it be? Yes, if the poster frame is the largest visible element before the video loads. Treat that poster exactly like a hero image: correct format, correct size, high fetch priority, and never lazy-loaded.
Next Steps
If your storefront's LCP is inconsistent across devices and markets, the fastest way to find out whether it is a framework issue or a media delivery issue is a technical walkthrough of your current pipeline. See platform pricing or talk to us about what a managed performance layer would change on your specific storefront.