The Myth of the Preloaded Hero
We’ve been told a story for years, a simple parable of web performance. It goes like this: the hero image, the key visual above the fold, is the star of the show. To prevent the dreaded layout shift, to ensure the user sees something meaningful as quickly as possible, we must preload it. We dutifully add that `<link rel="preload">` tag, confident we are doing the right thing. But what if this well-intentioned act is, in many cases, a performance placebo—or worse, a subtle saboteur?
The common wisdom is seductive. By preloading the hero image, we tell the browser to fetch this critical asset with high priority, theoretically getting it painted on the screen faster. This should stabilize the layout early and improve our Core Web Vitals. The logic seems unimpeachable. Yet, this advice ignores a fundamental, often overlooked truth: the browser’s resource scheduler is already astoundingly good at its job.
When you preload an image discovered in the HTML, you are essentially second-guessing the browser’s native prioritization. The browser, upon parsing your HTML and CSS, creates a dependency graph of resources. It knows which CSS file blocks rendering and which image is in the viewport. By preloading, you are effectively shouting over this sophisticated system, demanding immediate attention for a single asset. This can and does backfire.
The Quiet Cost of a Loud Command
The unintended consequence is resource contention. By forcing the browser to fetch your hero image at the highest possible priority, you might be diverting bandwidth and connection slots away from other, equally critical resources. That tiny, render-blocking CSS file? The font that defines your entire typographic experience? They are now competing with a massive image for network bandwidth. You may shave a few milliseconds off your Largest Contentful Paint (LCP), but at what cost to your First Contentful Paint (FCP) or even the time to first byte of that crucial CSS?
Worse, this preemptive strike is often redundant. Modern browsers that support preload also typically support native lazy loading and eager loading. Using `loading="eager"` on an image already in the initial viewport often achieves the same perceived outcome without the potential for network disruption. It works within the browser’s natural order of operations, not against it.
This isn’t to say preload is without merit. It remains a powerful, surgical tool for truly critical resources that the browser wouldn’t otherwise find quickly enough—like a background image defined in an external CSS file, or a font file not hinted correctly. But for the hero image sitting plainly in your `` tag? You are likely solving a problem that the browser has already optimized for, and in doing so, you risk creating new, less visible ones. Sometimes, the best way to be a hero is to trust the team behind the scenes.
Notes & further reading
A few pages I came back to while writing this: