Quick to load, slow to use
The home page opens quickly. But searching for an order, applying a filter or opening its details means waiting again. Someone working with the application every day is unlikely to be reassured by a green score for the initial page load.
To me, this is an easy mistake in acceptance testing: we inspect the entrance, not the route through the actual work. The customer portal below is a fictional example, not a measurement of a TNSystem application.
A new view of navigation
On 13 October 2026, Google added experimental Core Web Vitals variants to the Chrome UX Report that include soft navigations: changes of view without fully reloading the document. [1]
These additions do not yet replace the stable metrics. Google is evaluating them alongside the established versions. The announcement therefore establishes neither a new universal ranking rule nor an automatic improvement for every website. [2]
Separate a response from a finished result
A button should acknowledge that an input has arrived. That does not mean a search has finished. INP measures responsiveness up to the next presentation, not the total duration of every subsequent network request and processing step. [3]
I would therefore ask two separate questions: does the user receive prompt feedback, and when is the required result actually available? An immediate loading indication may reduce uncertainty without fixing a slow database query.
Test a real working journey
For our example, I would define a simple sequence: sign in, search for an order, filter by status, open a result and return to the list. The test should use data volumes appropriate to normal operation. An empty test list answers a different question from a populated order-management system.
I would also choose devices and connectivity deliberately. A fast development machine is useful, but not automatically a substitute for an older office computer or a mobile device. Conditions belong with the result so comparisons remain meaningful.
Attribute the delay to the right stage
For a slow search, I would trace the route from the click through the request to the displayed result. Is the interface blocked before it sends anything? Is it waiting for the server? Or have the data arrived but rendering takes too long?
Only then would I choose a change. Reducing unnecessary transfers, improving a query or limiting the result set may be useful starting points. Replacing the web framework wholesale would not, in itself, constitute a diagnosis.
Look beyond the average
An application may feel pleasant most of the time and still be unacceptably slow during individual essential tasks. I would not merge unrelated activities into one average. Search, saving and export each deserve a traceable assessment.
Privacy and access controls matter during measurement too. I would use technical timings and approved test cases rather than automatically sending search terms, customer details or complete forms to analytics services. Performance testing is not permission to collect everything.
My conclusion
A useful performance assessment should explain what work feels like, not merely how quickly the first page appears. I would base acceptance on typical tasks and record the conditions under which they were checked.
Experimental metrics can provide additional clues. They replace neither investigation of a particular bottleneck nor comparison before and after a justified change. This article contains no independent benchmarks or performance promises.
Sources and context
Research date: 23 October 2026. Vendor publications are not independent product tests. Examples and recommendations are identified as such in the article.
[1] Google: September 2026 CrUX dataset, published 13 October 2026
Read source ↗
[2] Google: experimental soft-navigation metrics, 13 October 2026
Read source ↗
[3] Google: Interaction to Next Paint and measurement boundaries
Read source ↗