Bit of a stream-of-consciousness rant, and of course there is no absolutely right or absolutely wrong answer.
Different situations/products/apps could have very different “most important” metrics.
But I am hoping to do create a little discussion, hear others’ input/opinions on the matter.

Technically-speaking, I want to say Time to First Byte (TTFB) is the most important, because nothing can happen before stuff arrives in the browser…
(Okay, I know there’s Early Hints, Service Workers, cached assets, local storage, IndexedDB, etc., but let’s focus here.)

User Experience (UX) might say First Contentful Paint (FCP), because until you see something, you’re wondering if anything is happening…

Business/Marketing might say Largest Contentful Paint (LCP), because, that’s the thing that the latest campaign is likely trying to push!

Interaction to Next Paint (INP), well, kind of feels to me like a rich man’s problem… a real first-world metric. It’s like, you have nothing else to complain about except “I clicked a thingy and had to wait…” (Snarky, I know, but moving on…)

So, to me, the most important is Cumulative Layout Shift (CLS).

TTFB, FCP and LCP are all, to some extend, reliant on resources we as developers cannot 100% control: a bad connection, a low-powered device, network latency, etc.
Any issue with any of these could easily be explained away in the user’s own mind by something like “Hmm, maybe I have a bad connection or something…”
Plus, we’re all still at least a little accustomed to waiting for the Internet; until things start happening, we might just assume there’s an issue out “there” somewhere…

And I think I have already sufficiently thrashed INP…

But CLS… CLS is something that, for the most part, we as developer should be able to 100% control (okay, maybe like 99.9999%?).
We build the HTML, and we crafted the CSS that affects it.
The browser won’t show stuff to the user until it has the CSS.
So, once the browser has all of that, things should just render, and stably. Shouldn’t they?

If stuff starts rendering, then jumps around, and maybe jumps some more, isn’t that all on us?
Shouldn’t we have been able to plan for that, and avoid it?

Okay, maybe something got injected by JS, or JS initialized and did something, but that too is under our control.
Or at the very least is something we should have been aware or, and thus been able to plan for, to avoid any layout shift that would be related to it…
Maybe we need to reserve some space for something or insert a placeholder element that gets nuked-over when the JS does it’s business?

Well, short-and-sweet, that’s my take.
What’s yours??

Happy perfing,
Atg

Top⇪