# Personalizing the hero image, how do I keep LCP fast?

Asked by tomek on 2026-08-14. Tags: performance, lcp, ssr.

my hero image changes per audience, and the hero image is my LCP element on
every landing page. i am worried that choosing it at request time means it
swaps in after load and my LCP regresses.

what i want is the correct image already present in the first paint, not a
default that gets replaced once the personalization resolves. is that
achievable, and how do i optimise it so the LCP element is stable?

## 2 answers

### Answer from priya_n (2026-08-15)

It is achievable because the content resolves on the server, so the chosen
image is already in the initial HTML. There is no default that gets
replaced later, which means no post-load swap and no client-side content
replacement to shift your LCP. The browser sees the right hero on the first
paint.

That is the whole reason LCP holds up here, there is no flicker step in the
middle. We looked at exactly this and the numbers held, see
[measured LCP improvement after migrating](/answers/measured-lcp-improvement-after-migration).

### Answer from tomdev83 (2026-08-16)

To add the practical bit: keep your normal priority and preload hint on the
resolved hero image, exactly like you would for any static LCP image.
Because the resolved URL is in the HTML at request time, the preload hint
points at the real image, not a placeholder.

Also pass a fallback image on the fetch. If the call fails or times out the
fallback renders, so your LCP element is never empty. There is a broader
rundown in [core web vitals after adding personalization](/answers/core-web-vitals-after-personalization).

#### Reply from tomek (2026-08-17)

preload hint on the resolved url is the detail i was missing, thanks.
fallback image makes sense too, no empty LCP box on a bad fetch