The Unseen Hand: How Our Obsession with LCP Betrays the User

There’s a mantra in our world, repeated in conference talks and blog posts until it has hardened into gospel: make your Largest Contentful Paint as fast as possible. It’s the north star of Core Web Vitals, the singular metric we’re told defines a user’s perception of speed. We chase it with religious fervor, preloading, preconnecting, and pruning our pages to shave off milliseconds. But in our blind pursuit of a low LCP score, I fear we’ve become performance engineers, not craftspeople. We’ve started building for the metric, not the human.

The problem isn’t that LCP is a bad metric. The problem is that it’s an easy one to game, and in gaming it, we often sacrifice the very experience it was designed to protect. We’ve all seen the tricks. A page loads with a giant, low-quality hero image that paints instantly, ticking the LCP box, while the actual text—the content the user came for—remains a blurry, unreadable jumble for seconds more as a web font loads over a shaky connection. The metric is green, but the user is squinting.

Or consider the clever hack of using a giant, styled text node as the LCP element instead of an image. The text renders fast, the numbers look great in CrUX reports, but the user is left staring at a page that is technically ‘fast’ yet feels eerily barren and incomplete. The critical content—the article body, the product details—is still queued up, waiting for its turn in the main thread. We’ve optimized for the first impression at the expense of the entire conversation.

The Illusion of Completion

This creates a dangerous illusion of completion. A fast LCP tells the browser, and the business, that the main content is here. But it tells the user a lie. It says, “You are done waiting,” when in fact, they are just beginning. The interactive elements are still frozen, the layout is about to shift as the real content streams in, and the user’s initial click is met with nothing but a ghost of the page we promised them.

This metric-first approach leads us down a path of local optimizations that can globally degrade. We slice our JavaScript into smaller bundles to improve Time to Interactive, but we ignore the cumulative cost of the network requests. We lazy-load everything below the fold to get that LCP, only to have the page stutter and jump as the user scrolls, a carnival of layout shifts that makes reading a moving target. We serve tiny, blurry placeholder images that paint fast, forgetting that a user might prefer to wait two seconds for a clear photo than one second for a meaningless smudge.

True performance craft isn’t about worshiping a single number. It’s about understanding the symphony of loading, not just the first note. It’s the subtle art of managing expectations, of providing meaningful feedback (like a proper skeleton screen instead of a blank white space), and of prioritizing the resources that deliver value, not just points. It’s about building a page that feels coherent and responsive throughout its entire lifecycle, not just in the first fleeting moment. Let’s stop building for the dashboard and start building for the person on the other side of the screen. They deserve more than a high score; they deserve a good experience.

Notes & further reading

A few pages I came back to while writing this: