Sander van Surksum (@sandervs.bsky, in/sandervansurksum, @SSurksum) is a Web Performance Consultant, with 20+ years in tech, founded Iron/Out, dedicated to speeding up websites. He's passionate about improving online user experiences.
Web performance is a lot like walking on those moving walkways at the airport.
When it moves smoothly, you barely notice it. You feel fast. Supported. In control.
But when one section stutters, even just a hiccup, your whole body reacts.
You lose balance for a moment. You hesitate. Something feels off.
Websites behave the same way.
Not in neat charts or dashboards or the tidy language of KPIs, but in the lived experience of someone trying to get something done. The page either helps them move forward or, without meaning to, slows them down.
And that momentum, that quiet sense of “this is easy”, is everything.
The strange thing is: we all feel this when using a website, but we rarely talk about it. We talk about speed, metrics, budgets… but not the experience itself. At some point, I realised I needed a way to describe what actually happens to users when a site helps them move or quietly holds them back.
That was also when I started using the language of friction and flow more deliberately. People like Tammy Everts and Jeroen Tjepkema had already been talking about this in the context of web performance for years. Their work made it clear that friction is not a technical issue but a user experience issue. It finally gave me the vocabulary to explain what was actually happening to users.
It was a useful shift in perspective, but it did not immediately change how performance was discussed day to day. That became clear in the many sprint reviews that followed, where engineers shared real wins such as reducing TTFB, cutting bundle sizes and fixing layout shifts that had quietly frustrated users for months. Yet the moment the conversation turned to performance metrics the energy in the room slipped away.
The work reduced friction.
The explanation, somehow, added it right back.
That’s when it clicked for me:
Performance isn’t a technical discipline. It’s a human one.
And if that’s true, then the way we talk about it needs to change.
Flow: the experience everyone instinctively recognises
Flow is what happens when everything just works. A page loads, nothing jumps, you tap and it responds immediately. No drama. No surprises. Nothing calling attention to itself.
It’s the feeling of not noticing the website at all.
Psychologists describe flow as a state of effortless progress and full engagement.
On the web, users feel something similar when they can move through a journey without needing to think about the interface.
Flow isn’t a metric.
You can’t chart it.
But you can feel it.
And once a user is in that rhythm, they convert more. They explore more. They trust more.
Users expect rhythm — and the rhythm breaks easily
People pick up on speed faster than we like to admit. If the homepage loads quickly, every step afterward is judged by that first impression.
One slow PDP.
One PLP that flickers.
One filter interaction that lags for half a second.
It only takes one break in the rhythm to make the whole experience feel slow.
Research from Nielsen Norman Group is clear:
- Around 0.1s feels instant
- Up to 1s keeps the user’s flow of thought
- Beyond that, attention drifts
There’s no negotiation with this. It’s how our brains work.
The user doesn’t care why something is slow.
They only feel that it is.
Friction: the kind that quietly erodes trust
Friction isn’t always a big issue. Often it’s the accumulation of tiny ones:
- A tap that doesn’t respond right away
- A button that jumps as the layout settles
- Images that flicker into place
- A screen that stays blank just a beat too long
Individually, these look harmless.
Together, they start to chip away at confidence.
Google’s research shows that delays as small as 70–100 ms affect a user’s sense of control.
Other case studies show that even slowdowns of a few hundred milliseconds can hurt conversions.
Friction breaks trust long before anyone realises trust was on the table.
A moment that changed how I communicate
There was a sprint review last year where we were looking at improvements to a product listing page. I explained the issue: the filter interaction on mobile had an INP of around 450 ms, caused by JavaScript blocking the main thread.
I could tell it wasn’t landing. Everyone understood the words but not the problem.
So I pulled up a session replay.
A user tapped the filter. Nothing happened.
For almost half a second, the whole PLP looked frozen. No movement, no feedback, not even the tiniest nudge that the site had heard them. Then out of nowhere everything updated at once.
One of the stakeholders leaned forward and said:
“Ah… okay. That feels broken.”
That single moment did more than 10 minutes of charts ever could.
The metric didn’t matter.
The friction did.
A broader industry challenge
This isn’t just something I’ve seen. At the WebPerfDays Unconference at the Google office last year, the topic surfaced again: performance still struggles to get traction outside of engineering. Not because it isn’t important, but because the way we talk about it doesn’t connect with stakeholders.
It stays a conversation among specialists when the people who need to hear the story are often the ones who never do.
Why this language works (and metrics alone don’t)
Most stakeholders don’t care about the specifics of Web Vitals, and that’s completely fine.
What they do care about is:
- customer frustration
- moments of hesitation
- broken user journeys
- conversion drop-offs
- brand perception
- how confidently a user moves through the site
- why people abandon baskets they meant to finish
Friction and flow translate performance into those outcomes.
Metrics validate.
But they cannot lead the story.
Metrics should support the story — but never be the story.
Performance language vs business language
UX teams are wrestling with this problem again today. Just last week Vitaly Friedman shared a post about why designers are often misunderstood inside organisations. His point was simple: UX language is full of terms that do not connect to business goals. And the moment designers shift to talking about outcomes like loyalty, adoption or reduced support volume, everything becomes clearer.
The same pattern appears in performance work. The language does not match the audience.
When we open with LCP, INP, CLS, thread blocking, JavaScript hydration or render costs, we lose the room.
But when we talk about:
- trust
- certainty
- ease
- predictability
- momentum
- confidence
- effort
…suddenly the conversation shifts. Because these are words leaders understand.
These are words users understand.
Friction and flow give performance a vocabulary that resonates across teams.
It’s the bridge performance has been missing.
Bringing the message home
Technical work matters, deeply.
But that isn’t enough.
The work deserves to be understood.
It deserves to be seen.
It deserves to shape decisions.
That only happens when we stop leading with numbers and start leading with meaning.
Friction and flow give us a language everyone can understand. A language that turns performance from “a technical thing” into a business-critical story. A language that helps engineers communicate the impact of their work, not just the mechanics of it.
Use metrics to measure the work.
Use friction and flow to communicate the work.
We don’t fix metrics.
We fix moments.
And the story of those moments is what finally makes performance matter.