Core Web Vitals: headless and Hydrogen stores vs Liquid themes

Headless gets sold on speed, so we checked what the real-world data says. We looked at how often stores pass all three Core Web Vitals, and their typical LCP, INP and CLS, split by platform and front end. Here is what the figures show, and what we'd do with them whether you're choosing a stack or building one.

What passing actually means

Core Web Vitals are three measurements of how a page feels to use. LCP (largest contentful paint) is how long the biggest thing on screen, usually a hero image or product photo, takes to appear. INP (interaction to next paint) is how quickly the page responds when someone taps or clicks. CLS (cumulative layout shift) is how much the page jumps around while it loads.

A store only passes if all three are good. One weak metric fails the whole thing, which is why a decent LCP doesn't save a page whose banner shoves the add to cart button down as it loads. The figures are also taken from real Chrome visits over the previous month, at the 75th percentile. That means a quarter of visits can be worse than the number you see, and the pass still counts. It's a harder bar than a one-off lab test on your fast laptop.

So when you read the charts below, remember that a typical LCP of 1.9 seconds for Liquid themes is the figure that three in four visits beat, not an average. Our tip: test on a mid-range phone over a throttled connection before you trust any local result, and check the field data for the pages that earn the money, like product and collection pages.

Liquid themes pass more often than headless

Liquid themes lead on pass rates. In our sample, 72% of Shopify stores on a Liquid theme pass all three Core Web Vitals, across 193 stores. Headless Shopify sits lower at 51%, from 45 stores. Salesforce Commerce Cloud is lower still at 33%, and other platforms and custom builds land in between at 46%.

The headless group is much smaller, so read it as a direction, not a verdict. A handful of slow or fast builds can move that figure a long way. We'd also be careful about why it sits lower. The figures show the gap, not the cause. One plausible reason is that a custom front end leaves more of the performance work to your team, where a Liquid theme arrives with a lot of it already done.

So here's the tip: judge a headless build on its own field data, not on the architecture's reputation. Hydrogen can be fast, but nothing about it guarantees a pass. If you're a developer, check real-user numbers from Chrome (the Chrome UX Report, or your own monitoring) before and after launch, and set a budget for the page types that earn the revenue. If you're a merchant, ask any agency proposing a rebuild how they'll prove the new storefront is at least as fast as your current theme.

Where the gap shows up: load time and layout shift

Start with load time. The typical Liquid theme store has a median LCP of 1.9 s, and headless sits a little behind at 2.2 s. LCP is Largest Contentful Paint: how long the biggest thing above the fold, usually the hero image, takes to appear. That gap is modest, and INP tells a different story. Interactions feel the same at the median, 150 ms for both. For comparison, Salesforce Commerce Cloud sits at 225 ms, so headless isn't the slow one here.

Layout shift is where headless stands out. Liquid themes come in under 0.01 for CLS, while headless is at 0.05. CLS measures how much the page jumps around as it loads. Shoppers feel it as a button moving just as they tap. Our guess is that it comes from how headless pages are put together, not from the platform itself. A Liquid theme ships finished HTML with its layout mostly fixed. A custom front end often fills in parts of the page later.

So the tips are about reserving space and controlling the order things arrive. Give every image explicit dimensions or an aspect ratio, so the browser holds the room before the file lands. Do the same for reviews, recommendation rows and announcement bars: a placeholder of the right height beats a block that pops in and shoves everything down. Prioritise the hero image, and in Hydrogen stream the main content so the first view arrives early. Then watch hydration, the step where JavaScript makes server-rendered HTML interactive, and any client-side data fetching. Both tend to rewrite the page after it has already painted, which is exactly what causes shifts. If a price or stock badge has to load late, render its container first.

What to do next

If you're on a Liquid theme that already passes, speed alone is a weak reason to go headless. In our sample, 72% of Liquid stores pass all three Core Web Vitals, against 51% of headless ones. That doesn't prove headless causes slower pages, but it does suggest you shouldn't expect a rebuild to fix speed. Go headless for something else: richer content modelling, custom flows a theme can't handle, or one front end serving several channels. If that's the case, fine. Just go in knowing the speed has to be earned.

If you're building with Hydrogen, put performance work in the plan from day one, not as a clean-up phase. Set up field monitoring early, using Chrome UX Report data, so you see what real visitors experience rather than only what a lab test shows. Keep a close eye on third-party scripts too. Tag managers, chat widgets and review tools are easy to add and tend to hurt interaction speed, because they compete with your own code for the browser's attention. Load them late, and ask of each one whether it earns its place.

On Liquid, the job is mostly restraint. Themes are quick out of the box, and stores tend to lose ground as apps pile up and each one adds scripts and styles. Audit what's installed every so often and remove anything unused, since leftover code from uninstalled apps can linger. Prefer apps that use theme app extensions and app blocks, so you can place and remove them cleanly. Defer anything that isn't needed for the first view of the page.

How we measured this

Of 312 stores we index that Chrome reports Core Web Vitals for, not the whole market.

Core Web Vitals and device mix come from the Chrome UX Report: real Chrome visits over the previous month, at the 75th percentile. Stores with too little Chrome traffic aren’t in it.

Platform and front end are detected from public HTML and headers; groups with fewer than 8 stores are left out.