SOVOR Shopify Performance and Core Web Vitals Case Study

The four numbers that matter, stated by device

Desktop and mobile were measured separately on all four URLs, and the two results are different enough that reporting them together would be misleading.

On desktop, the homepage reached 100, the anti-skid use-case page reached 100, the protein product page reached 97, and the COD hub reached 83. Three of four sampled commercial and content surfaces sit at or near the top of the scale. The COD hub is the exception, and its limitation is layout stability rather than load speed: its desktop LCP was 0.6 seconds, which is fast, but its CLS measured 0.337, meaning the page visibly moves as it loads.

On mobile, the same four URLs scored 86, 89, 65 and 63. The homepage and the anti-skid page are strong. The protein product page and the COD hub are not, and they are not in the same way. The product page’s problem is load time: its mobile LCP measured around 10.1 seconds, roughly four times the threshold usually treated as acceptable. The COD hub’s problem is again layout stability, with mobile CLS around 0.529.

The headline a store owner would want is ‘the site is fast’. The measurement says something narrower and more useful: on desktop, three of four sampled surfaces are excellent; on mobile, two of four are, and the two that are not fail for different reasons that need different fixes.

The homepage story is about layout, not speed

The homepage’s headline improvement is layout stability rather than raw speed, and that distinction is worth being precise about.

Its mobile CLS is now 0.000 in the repeated run set. The homepage previously moved as it loaded: content shifted after first paint, which is the experience where a reader starts to tap something and the page moves underneath them. That mechanism was addressed, and it is now effectively gone in the measured runs. Its desktop score reached 100 with an LCP of 0.6 seconds.

The homepage mobile LCP, however, measured 3.8 seconds, which is above the 2.5-second threshold usually treated as good. So the honest description of the homepage is that it is fast on desktop, stable on mobile, and still slower to paint on mobile than it should be. Layout stability and load speed are separate measurements, and improving one did not automatically improve the other.

The mobile performance score moved from an owner-recorded baseline of 49 to a measured 85 to 86 across the run set. That is a large move on the recorded figures, and it is reported with the provenance caveat attached: the 49 was recorded before the work and its original report was not archived.

Where mobile is genuinely slow, and why the score hides it

The protein product page is the clearest remaining problem. It scored 65 on mobile against 97 on desktop, with a mobile LCP around 10.1 seconds. That is not a marginal miss. A ten-second load on a product page is long enough that a shopper may leave before seeing the product at all.

One contributing factor was measurable and was addressed: a body image on the product page was requesting roughly 6.57 megabytes without a width transform or stable dimensions. That image opportunity was reduced from approximately 706 kilobytes to 249 kilobytes. The product page’s performance score, however, moved only from 65 to 66.

That gap between the size reduction and the score movement is the most instructive detail in this study. It shows that reducing image weight, on its own, was not enough to move the number — because the bottleneck on that page is when the largest image is requested and how long it takes to arrive, not merely how large it is. Fixing the request path matters more than compressing the file.

The COD hub is a different problem again. Its mobile CLS measured around 0.529 across runs, with two distinct layout shifts detected. The hub had recently been expanded with a substantial internal link block, and the honest position is that it needs its own mobile layout pass before it can be presented as resolved.

Repeated runs, because one result is not a measurement

Every URL was measured three times per device and the median reported. That is not pedantry. The local Chrome cold-run set for the homepage showed an LCP range from 0.51 seconds to 6.31 seconds across five runs, and two runs recorded CLS around 0.412 where the median was 0.000.

That spread means a single run can produce almost any result you want, depending on luck. Reporting a best run would have produced a flattering number that no real visitor reliably experiences. Reporting the median is the only figure that describes what the page typically does.

The cold and warm comparison is also worth stating because it separates two different questions. Cold runs, starting with an empty cache, are closer to a first-time visitor and are visibly variable. Warm runs, with assets cached, were stable at an LCP of around 1.25 seconds and a CLS of 0.000. That difference tells you the homepage’s remaining speed problem is largely about what has to be fetched, not about what happens after it arrives.

What the evidence supports, and what it does not

The evidence supports a specific set of claims. Desktop lab performance reached 97 to 100 on three of four sampled URLs. Homepage layout stability reached effectively zero in the repeated run set. The work identified and fixed a large, measured image opportunity on the product page and reduced a known layout-shift mechanism on the homepage. The same work made the remaining mobile bottlenecks visible rather than hiding them behind an aggregate.

The evidence does not support the claim that the whole site is fast, and this study does not make it. Two of four sampled URLs score in the 60s on mobile. It does not support a claim that rankings, conversion or revenue improved. It does not support the claim that the site is faster on mobile as a universal statement, because two sampled mobile pages are slow and one of them is the product page.

No field data was available for these URLs, so nothing here describes the experience of real visitors on real devices with real network conditions. These are lab measurements, and lab measurements are a model, not the thing itself.

The baseline that was not saved

The homepage’s before values — desktop 73, mobile 49, mobile LCP 5.2 seconds — were recorded before the remediation work, but the original PageSpeed report or raw JSON was not archived. They are the store owner’s recorded measurements, not independently reproducible artefacts.

That does not make them false. It does mean the study labels them as recorded rather than verified, and explains why. A reader can see the after values reproduced in the dated run set. The before values rest on a record rather than an artefact, and the difference is disclosed rather than blurred.

This is now the standing rule for this kind of work: archive the report URL or raw output, the exact URL, the strategy, the date, the device emulation and the test count at the moment of measurement. A case study is only as strong as the provenance of its baseline, and provenance is cheapest to capture at the time and cannot be recovered afterwards.