The slowest app I ever worked on had a perfect performance score.
That sentence used to confuse me.
Everything was optimized. Bundles were trimmed. Images were compressed. Lighthouse smiled back at me like a proud teacher.
And yet, users kept behaving strangely.
They clicked twice.
They hesitated.
They abandoned flows halfway through.
At first, I blamed users. Then devices. Then networks.
Eventually, I blamed myself.
That was the moment I started understanding performance first UI.
Speed is not what developers think it is
As developers, we grow up believing speed is a number.
Milliseconds.
Scores.
Graphs.
But users never see numbers. They feel moments.
The moment after a click.
The moment after a tap.
The moment when they expect acknowledgment.
If nothing happens in that moment, something breaks not technically, but emotionally.
The day I stopped trusting Lighthouse alone
Lighthouse is useful. It taught an entire generation to care about performance.
But in 2026, relying on Lighthouse alone is like judging a car by how fast it accelerates on an empty track.
Real users drive in traffic.
They scroll while data loads.
They click while JavaScript executes.
They type while hydration finishes.
That’s where performance first UI lives, not at load time, but during interaction.
Interaction is the real contract with the user
A page load is an introduction.
An interaction is a promise.
When a user clicks a button, they are not asking for data. They are asking for reassurance.
Did you hear me?
Are you working?
Can I trust you?
If your interface stays visually silent, the promise is broken.
Why Interaction to Next Paint quietly changed everything
Interaction to Next Paint does something rare in web metrics.
It measures reality.
Not when logic finishes.
Not when promises resolve.
But when pixels change.
This sounds obvious, but it reframes how you write UI code.
Because suddenly, doing work before paint feels dangerous.
If this shift in thinking around Interaction to Next Paint resonated with you, I’ve explored it in much more depth in my long-form guide Performance First UI Mastery: A Critical Guide for 2026 Developers, where I break down real-world examples, beginner-to-advanced concepts, and how this mindset plays out in modern Next.js apps.
The hidden enemy of modern interfaces
Most INP problems are not caused by slow servers.
They are caused by good intentions.
- Too much logic inside event handlers
- Too many state updates
- Too many components reacting at once
Everything works. Everything is correct. Everything is just slightly late.
And that slight lateness compounds.
The small habit that fixed most of my issues
The biggest improvement I ever made to interaction performance was embarrassingly simple.
I stopped doing real work before showing feedback.
Instead of:
Click → compute → update UI
I switched to:
Click → update UI → compute
Nothing fancy. No new libraries.
Just respect for the paint cycle.
Why modern Next.js makes this mindset possible
Next.js quietly evolved alongside performance first UI thinking.
- Partial Prerendering lets interfaces appear ready before they are complete.
- Streaming lets content arrive without blocking interaction.
- Server Actions let the UI move first and confirm later.
- Edge Middleware removes entire decision trees from the client.
Used correctly, these tools keep the browser free to respond.
Performance is not about doing less, it’s about doing things later
This was a hard lesson for me.
I used to chase minimalism. Fewer features. Smaller bundles.
But performance first UI taught me something better.
You can do a lot, just not all at once.
Defer what the user cannot see.
Delay what the user does not care about yet.
Focus on what the user just did.
The business side developers rarely talk about
Here’s an uncomfortable truth.
A sluggish interaction costs more than a slow page load.
Because interaction delay happens when the user is already invested.
They clicked.
They intended.
They were ready.
Losing them here hurts conversion far more than a slow landing page.
Performance is becoming a human skill again
In 2026, AI can generate components.
AI can refactor code.
AI can optimize assets.
But AI cannot feel hesitation.
It cannot sense when a transition feels awkward.
It cannot sense when feedback arrives too late.
That sensitivity is now the developer’s real value.
What performance first UI actually demands from us
It demands patience.
It demands that we observe our own interfaces instead of trusting dashboards.
It demands that we click our own buttons slowly and ask:
Does this feel respectful?
Not impressive.
Not clever.
Respectful.
Final thought
Performance first UI is not a trend. It is a correction.
A return to building software that listens.
If your UI responds instantly, users forgive imperfections.
If it hesitates, they remember.
In the end, performance is not about speed.
It is about trust.
Top comments (3)
Makes sense, point well made ...
Thanks, really appreciate you reading.
I would prefer if you put in an example here to understand what you did exactly rather than all the fluff around INP
Thanks for the article though, food for my thoughts