Your LCP Is Broken Before the First Line of Code

Website performance is often treated as a frontend problem — and that assumption isn’t entirely wrong. With modern techniques like streaming rendering and code splitting, it’s now much easier to build fast applications without sacrificing developer experience. With just a few adjustments, you can significantly reduce the initial JavaScript payload and improve key performance metrics.

However, there is one metric in particular whose responsibility is far more shared and yet frequently overlooked: LCP (Largest Contentful Paint).

Unlike many other metrics, LCP rarely originates in the code. In most cases, it starts in the design.

The Case: When Desktop Has a Clear LCP and Mobile Doesn’t

This was a real scenario I encountered recently.

On desktop, the layout featured a clear, prominent slider above the fold. The primary element was obvious, visually dominant, and immediately visible. For the browser, there was no ambiguity — that element was the natural LCP candidate.

On mobile, however, the situation was completely different.

The banner was removed, leaving:

• multiple blocks of text,

• combined with CTAs,

• with no single dominant element.

As a result, the LCP varied between different elements on the page, making the metric unstable and difficult to optimize.

The outcome was interesting — though not surprising:

Even with more JavaScript loaded and server-side rendering strategies in place, desktop achieved a better LCP score than mobile.

Not because of superior technical implementation, but because of clearer design decisions.

LCP Doesn’t Measure What Looks Best — It Measures What Dominates

A common misconception is that LCP reflects visual intent.

It doesn’t.

LCP simply measures the largest visible element above the fold during page load.

When design fails to clearly define that dominant element — often in an attempt to “simplify” the layout — priority is lost. Without a well-defined hero element, the browser is forced to decide on its own.

And that decision can be costly.

Headings, paragraphs, or even lists of cards may end up competing for LCP, leading to:

• unstable metrics,

• inconsistent performance,

• and ineffective technical optimizations.

Why Text as LCP Is More Fragile Than Images or Other Dominant Elements

When text or HTML becomes the LCP, it depends on several factors:

• font loading

• CSS application

• layout calculations

• incremental rendering

Any delay in these steps directly affects the metric.

A clearly defined dominant element — such as an image — is far more predictable for the browser. It can be:

• preloaded,

• prioritized,

• and explicitly optimized.

For this reason, a well-chosen and well-positioned image is often cheaper to optimize than a confusing, text-heavy layout.

Designing With LCP in Mind

By now, the takeaway should be clear:

Designers need to treat LCP as part of the design process — not as a problem to be solved later by frontend engineers.

An LCP-oriented layout should clearly answer two questions:

• Which element is supposed to win the LCP race?

• Is that answer the same on desktop and mobile?

If these questions don’t have clear answers at the design stage, the problem already exists before the first line of code is written.

Conclusion

Performance is a more shared responsibility than it often appears to be.

It’s not entirely a frontend issue, nor solely a design or backend concern. More often than not, it’s a matter of alignment — or the lack of it.

Thinking about performance from the beginning means acknowledging that certain metrics, especially LCP, are fundamentally design decisions.

And when LCP behaves very differently between desktop and mobile, the problem is rarely technical.

It’s structural. And it’s decisional.