The page opens quickly. Then you tap a filter and nothing seems to happen.
So you tap again. The interface eventually responds with the faint irritation of someone who was about to do it anyway.
That experience is why initial loading speed isn’t the whole performance conversation. A website also has to respond while people use it: searching, selecting options, opening menus and completing forms.
Interaction to Next Paint, or INP, became a Core Web Vital in March 2024, replacing First Input Delay. It brings more attention to responsiveness during a visit. For a custom .NET application, it is also a reminder that a faster server and a responsive interface solve related but different problems.
Follow the action past the speed-test score
A performance report can help identify a problem. It cannot explain every customer’s experience without knowing what they tried to do.
Take a fictional account portal with a slow order-history filter. The delay might involve browser work, a server request, a database query or several of them.
The browser may be busy before the action starts
JavaScript can keep the browser’s main thread occupied. A user interaction then waits before the relevant handler can run.
The customer cannot see that queue. They see a control that appears unresponsive and may reasonably wonder whether the tap registered.
Review long-running work, unnecessary scripts and expensive operations around the interaction. The fact that code came from a useful plugin or tracking tool doesn’t mean it has no cost at this particular moment.
We can be glad the business has useful analytics and still ask whether all of it needs to start talking at once.
A small action can trigger a large update
A filter may run substantial logic or ask the browser to update a large part of the page. The control itself is small; the work behind it may not be.
INP concerns the delay to the next paint associated with an interaction. It should not be treated as a measurement of every later network request or the complete business task.
Somebody has to own the quiet, unglamorous work. See our hosting and support plans.
That distinction helps the team choose the right evidence. Immediate feedback can show that the filter was accepted. Efficient rendering can keep the interface responsive. The result still needs to arrive and be correct.
A spinner is a useful acknowledgment, not a legal settlement of the performance complaint.
Separate feedback from completion
People benefit from knowing that the application received their action. They also need an accurate understanding of whether the work is finished.
Those states should support the underlying process rather than disguise it.
The server may be the next bottleneck
If the filter starts an API request, measure the request and its dependencies. A slow database query needs a different remedy from a blocked browser thread.
.NET 8’s runtime and library improvements can help suitable workloads, as Stephen Toub’s analysis demonstrates.2 They don’t automatically remove waiting on a database or an external provider.
The diagnostics and tracing emphasized around .NET Aspire at Microsoft Build 2024 can help connect parts of a request.3 Their value is locating the delay, not supplying a generic claim that changing frameworks will make the page feel fast.
Follow the actual work before pricing the cure.
The task may continue after the page responds
An export can be accepted quickly and prepared in the background. That may be a good design, provided the application explains the state and offers a dependable way to obtain the result.
Don’t label it Complete merely because the request entered a queue. Don’t make the person press Generate repeatedly to discover whether the first attempt exists.
Check out this blog: The hero image should stay where we put it.
Show progress or a useful status where appropriate, preserve the operation’s identity and provide a recovery path if preparation fails.
The user came for an export. A quick acknowledgment is part of the service, not the finished product.
Measure the journeys people complain about
Start with a few representative actions and the devices and connections people actually use. A developer’s laptop is helpful for investigation; it isn’t a representative sample of everyone else’s afternoon.
Look at real-user responsiveness information where available, then reproduce the problematic interaction locally. Google’s INP launch guidance recommends that combination of field evidence, diagnosis and verification after changes.
Keep the business task alongside the metric. A responsive filter with incorrect results is not an improvement anyone can use.
Zulu Shack recommends making one focused change and repeating the relevant journey before widening the work. You may need less browser work, a better query, clearer feedback or a different workflow.
The goal is not to persuade a report that the website is fast. It’s to let someone do the thing they came for without negotiating with the button first.