The Chef's First Stock: On the Peril of a Too-Quick Simmer

We are, as builders of the web, forever being hurried. The gospel of performance is delivered in metrics measured in milliseconds, in audits that brand anything beyond a green score a failure. Our mantra is “faster.” Our sin is “blocking.” And so we rush, with religious fervor, to eliminate every perceivable delay. We in-line critical CSS, we defer every script, we preload, we preconnect, we shave and shave until the initial payload is a gleaming, minimal sliver. We serve a broth so clear it is nearly water. And we call this speed.

But I want to question the altar of First Contentful Paint. Specifically, the counterintuitive idea that sometimes, rendering too little, too quickly is the greater user experience failure. Our race to show something—anything—can leave the visitor in a uncanny valley of completion. They see a headline, a fragment of layout, a logo. And then… they wait. Not for the full page, but for the page to become usable. The stock has not simmered; it has no body, no flavour. The user, presented with a false “ready” signal, tentatively tries to interact, only to find the menu JavaScript isn’t here yet, the tap target jumps as a font loads, the article body is still a blank white rectangle awaiting its asynchronous text. The promise of the quick paint is broken by the reality of a non-functional shell.

The Deception of the First Glimpse

This is a different kind of layout shift. It’s not a visual jump, but a cognitive and interactive one. The user’s mental model of the page—formed in that first, eager glimpse—is fundamentally wrong. They believe they can act, but the infrastructure for action is still on its way. This breeds a unique frustration, one that feels like betrayal. It is often worse than a slightly longer, monolithic load where a spinner sets clear expectations: “Not yet.” The too-quick partial render whispers “Now,” and then slaps the hand away.

The common advice is to break everything apart, to stream content in. But coherence is a performance metric too, if we measure performance as the user’s ability to accomplish their goal. A coordinated, slightly later arrival of all core components—the scaffold, the content, the primary controls—can feel dramatically faster than a staccato series of “almost ready” states. It is the difference between a chef presenting you with a single, perfectly cooked carrot while the rest of the meal burns in the kitchen, and asking you to wait five more minutes for the complete, balanced dish.

This isn’t an argument for bloat or for ditching progressive enhancement. It is an argument for intentionality in what “ready” means. Perhaps, for a content page, we should not celebrate painting the navigation bar at 800ms if the article body won’t be hydrated for another 2000. Perhaps those two seconds should be spent building a single, stable, and truly interactive unit. The performance tools won’t praise this; our Lighthouse score may even dip. But the person using the site might just find it more dignified, more trustworthy. They are spared the anxiety of an interface that pretends to be born before its time. Sometimes, the best first impression is not the fastest, but the most honest.

Notes & further reading

A few pages I came back to while writing this: