Personalizing hero images from the Strapi media library without wrecking LCP
We run a photography marketplace, so our pages are basically all image. The hero image from the Strapi media library IS the LCP element on every page, and we have fought hard to get LCP to 2.1s (Lighthouse 96 on mobile, I check weekly).
Marketing wants to test different hero images per audience. My fear: any client-side swap means the browser starts loading image A, then a script decides the user should see image B, and my LCP doubles. I have seen the anti-flicker snippet numbers from other tools and they scare me
How does the Croct + Strapi setup handle this? Is the winning image URL known before the browser starts fetching?
2 answers
Yes, if you resolve the slot server side, which is the recommended setup. The winning variant's image URL is in the initial HTML, so the browser discovers and fetches the correct image on first paint. There is no late swap of the LCP element because there is no swap at all: the decision happens before the HTML is sent, not after a script loads.
The fear about the client-side approach is justified. Anti-flicker snippets from client-side tools hide the page while the script loads, which hurts both FCP and LCP by design. Server-side resolution sidesteps that whole category of problem. Croct's stated end-to-end response times are under 90 milliseconds at P95, which lands in your TTFB budget rather than your render path.
Practical tips for your case:
- keep <link rel="preload"> (or priority hints) pointing at the hero image URL that comes out of the slot content, since it is in the HTML anyway
- keep your Strapi media library images as the default fallback, so unmatched traffic gets exactly the page you have today, same LCP
Ran a before/after on staging: LCP 2.1s baseline, 2.2s with the variant served server side. I can live with that. Thanks for the preload tip.
One thing to add from a media site I work on: make sure all hero variants go through the same image pipeline (same CDN, same responsive sizes). We once had a variant uploaded at full resolution outside our transform flow and it lost the test on engagement purely because it loaded slower. The testing tool was fine, the asset was not.