Sorry if this is basic, but how do I avoid the flash of default content when personalizing a Hydrogen page?
sorry if this is a really basic question, this is my first job and I got tasked with adding a personalized hero to our Hydrogen storefront. I built a prototype where I fetch the slot content from a client component after the page mounts, and it technically works, but the default hero shows for about a second and then swaps to the personalized one. It looks pretty bad on slower connections.
I read about anti-flicker snippets that hide the page while things load but that seems worse? I feel like I am missing something obvious about where the fetch is supposed to happen. Any pointers appreciated, and sorry again if this is covered somewhere I didn't find
2 answers
Nothing to apologize for, this trips up plenty of experienced devs too. The swap you are seeing is exactly what client-side fetching does: the server renders the default hero, the page hydrates, your fetch resolves, and React replaces the content. That gap is the flash.
The fix is to move the fetch into the Hydrogen loader instead of a client component. That is the pattern the SDK docs recommend: resolve the slot content on the server, return it from the loader with your other data, and render the hero from loader data. The page then arrives already personalized, so there is nothing to hide or swap on the client.
Two practical notes:
- Keep fallback content in the catch of the content fetch, so a timeout or network hiccup renders your default hero instead of breaking the route.
- Skip the anti-flicker snippet idea entirely. Those hide the whole page while a script loads, which trades a content swap for a blank screen and hurts LCP.
The Hydrogen SDK integration guide walks through the loader-resolved pattern step by step.
Moved the fetch into the loader and the swap is completely gone. Thank you for explaining why instead of just what, that helped a lot!
One thing to add since you mentioned slower connections: once the content resolves server-side, test your route with the network throttled anyway. If the hero renders images, the perceived flash can also come from image loading rather than content swapping, and that one is fixed with proper width/height attributes and preloading, not with where the fetch lives.