Designing For Interaction Before It Becomes A Score

I have started paying more attention to how a page behaves after it has loaded.

For a long time, performance conversations were dominated by the beginning of the visit. How fast did the page appear? How quickly did the main content load? Did the layout jump around? Those questions still matter, but they do not describe the whole experience. A page can load quickly and still feel heavy the moment someone opens a menu, clicks a filter or starts typing into a search field.

That is why interaction performance has felt more important this year. It is not enough for a website to arrive quickly. It needs to respond properly once the visitor starts using it. The delay after a click can be more frustrating than a slightly slower first load because the visitor has already made a decision and is waiting for the interface to acknowledge it.

Looking For The Delay After The Click

The first thing I started doing was testing interactions more deliberately. Not just the obvious page load, but the moments where someone actually uses the interface. Navigation toggles, accordions, filters, tabs, search boxes and modal windows all became part of the performance check.

Sometimes the problem was obvious. A click would trigger too much JavaScript, rebuild too much DOM or wait for a request before showing any feedback. Other times the delay was subtle, especially on a fast machine, but became noticeable once the page was tested on a slower phone or with throttling enabled.

This changed how I thought about loading states. If an action takes time, the interface should acknowledge it quickly. That does not mean adding movement everywhere. It means making sure the visitor knows their action has been received before they start wondering whether the site has frozen.

Reducing Work During The Interaction

A common problem is doing too much work at the exact moment someone interacts with the page. If a filter button has to find a large set of elements, calculate layout, update several areas and trigger a network request before anything changes visually, the browser has a lot to do before the visitor sees a response.

I prefer to separate immediate feedback from heavier work where possible. The button can change state first. The interface can show that filtering has started. The heavier update can happen after that, or be split into smaller tasks if the amount of work is significant.

button.addEventListener('click', () => {
  button.setAttribute('aria-busy', 'true');
  button.classList.add('is-loading');

  window.requestAnimationFrame(() => {
    updateResults();
    button.removeAttribute('aria-busy');
    button.classList.remove('is-loading');
  });
});

That is a simplified example, but the principle is useful. The interface should not wait until every piece of work is finished before it admits that something is happening. A responsive feeling often comes from acknowledging the visitor’s action early.

Third-Party Scripts Can Make This Harder

Interaction performance also makes third-party scripts harder to ignore. A site might load a collection of analytics tools, widgets and embeds that all compete for main-thread time. The visitor does not know which script is responsible. They only know that the page feels slow when they try to use it.

This is where performance stops being a purely technical issue. Every extra tool added to a site can affect the way interaction feels. Some scripts are worth that cost, but the cost still exists. If a website depends on fast filtering, quick navigation or smooth form behaviour, those interactions need to be protected from unnecessary background work.

I have found it useful to test interaction-heavy pages with extensions disabled, then again with all third-party scripts active. The difference can be revealing. Sometimes the site code is not the main problem. Sometimes the page is being slowed down by things added after the build was finished.

Designing The Interaction, Not Just The State

This also affects design. A design file can show the closed menu and the open menu, but it does not always show the moment between those two states. That middle moment matters. How quickly does the interface respond? What happens while content is loading? Does focus move to the right place? Does the visitor understand what changed?

Those questions are easy to miss because they do not always appear in static screens. They appear when the website is used. That is why I like testing prototypes and real builds as early as possible. Interaction problems are easier to feel than to describe.

What I Take From It

I think performance work is moving beyond the question of whether a page loads quickly. That still matters, but the next question is whether the site keeps its promises after the visitor starts interacting with it. A slow response after a click is a broken promise in a small form.

The useful habit is to test the website the way a visitor uses it. Click things, type into forms, open overlays, filter results and do it on devices that are not perfect. Scores can help point to problems, but the experience itself should be the starting point.