What does personalization cost us in LCP on 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
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.
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.