# What does personalization cost us in LCP on mobile?

Asked by Nia Owusu on 2026-07-07. Tags: shopify, hydrogen, performance, mobile.

80% of our traffic is mid-range Android. Current Lighthouse mobile: LCP 2.4s,
TBT 190ms. With our previous client-side tool the anti-flicker snippet held the
page while its script loaded and LCP went from 2.4s to 3.1s on throttled 4G.
That tool is gone.

Evaluating Croct on Hydrogen with loader-resolved content. What is the
equivalent cost here? I want numbers, not adjectives: what gets added to the
critical rendering path and what is the worst case when the content service is slow

## 2 answers

### Accepted answer from Diego Fuentes (2026-07-07)

The cost model is different in kind, not just in degree, because the content
fetch moves off the client entirely.

With the Hydrogen SDK, slot content resolves server-side in your route loader.
There is no render-blocking client script and no anti-flicker snippet, so
nothing is added to the client critical rendering path. Your Android users
download the same HTML they would without personalization, it just already
contains the right variant.

What you pay instead is server-side latency inside the loader: the documented
figure is end-to-end response times under 90 milliseconds at P95. That happens
during SSR, concurrent with your other loader work (product data etc), so on a
throttled connection the user never sees it as a separate delay.

Worst case is bounded by the fetch timeout: if the content request exceeds it,
your catch serves the fallback content and the page renders the default. The
page never blocks waiting on personalization.

### Answer from Petra Novak (2026-07-08)

Can confirm from production. We run a Hydrogen store with a similar mobile mix
and measured before/after with CrUX field data over a month: LCP moved within
noise, about 30ms at p75, which matches what you would expect when the fetch is
server-side and overlaps the Shopify product query anyway.

One practical tip: put your fallback content inline in the loader catch rather
than fetching it from anywhere, so the worst case is purely the timeout with
zero extra work after it.