Performance conversations used to start with the page load. How quickly did the first screen appear? How large were the images? How much JavaScript was being shipped before the visitor could do anything useful? Those questions still matter, but they do not explain the whole experience anymore.
This year, with Interaction to Next Paint becoming part of the Core Web Vitals conversation, I have found myself paying much more attention to what happens after the page appears. A website can load quickly and still feel poor if the first menu click, filter change or form interaction feels delayed. The visitor does not separate those moments in the way a performance report does. To them, the site either feels responsive or it does not.
That changed the way I review front-end work. I still look at loading behaviour, but I also spend more time clicking through the site like somebody trying to get something done. Open the navigation. Expand the filters. Type into the search box. Submit the form. Move between tabs. The delays that appear during those moments are often the delays that people remember.
The Page Can Be Loaded And Still Feel Slow
One of the problems with load-focused performance work is that it can create a false sense of completion. The homepage loads in a reasonable time, the main image is compressed, the CSS is not too large and the report looks acceptable. Then somebody uses the site on a mid-range phone and the first interaction feels sticky.
That delay might come from JavaScript still working in the background. It might come from a heavy third-party script, a menu animation doing too much, a filter component rebuilding more of the page than necessary or a click handler tied to other work that should have been deferred. The page is visible, but the browser is not ready to respond cleanly.
This is where I think INP is useful, not because it gives us another score to chase, but because it pushes the conversation closer to lived experience. A person does not only care that the page appeared. They care whether the page responds when they touch it.
That is especially important on websites that are no longer static collections of pages. Even fairly normal business sites now include filters, overlays, menus, accordions, forms, embedded tools, tracking scripts and content that changes after load. All of those pieces can affect how responsive the page feels.
Testing The Interface Like A Visitor
The first change I made was simple. I stopped treating performance testing as something that only happens at the start of a page visit. After the page loads, I interact with the parts of the interface that matter most. If the website has a product filter, I test the filter. If the enquiry route depends on a modal, I test the modal. If the mobile navigation is the main route through the site, I open and close it repeatedly.
I also try to test on less forgiving devices. A fast laptop hides a lot of front-end decisions. It can make a heavy menu feel acceptable and a large JavaScript bundle feel less damaging than it is. A lower-powered mobile device is usually more honest. If the interaction feels delayed there, the site probably has work to do.
The useful part is that this kind of testing often points directly to practical changes. A listener can be simplified. A script can wait until it is needed. A layout shift can be removed. A component can update less of the DOM. An animation can be made cheaper. None of those changes are particularly glamorous, but they make the site feel better in daily use.
Where I Usually Find The Delay
The delay is often not in the place I first expect. A button might feel slow, but the button itself is rarely the whole problem. The click may trigger validation, analytics, animation, layout recalculation and a fetch request. Each piece may be reasonable on its own, but together they make the interface feel heavier than it should.
Third-party scripts can make this harder because they are often added outside the original development flow. A tracking script, chat widget or embedded tool might run at exactly the wrong moment. The site then has to compete with code that was not written for that specific interaction. This is one reason I have become more careful about what gets added to a page by default.
Menus are another common source of poor interaction. A mobile menu can look simple, but if it triggers large layout changes, blocks scrolling awkwardly, animates expensive properties or waits for JavaScript that has not settled, it can feel slow even when the rest of the site is fine. The navigation is often the first interaction on mobile, so that cost is very visible.
Forms deserve the same attention. Validation should help people, not punish them with delayed feedback. If a field changes, the interface should respond quickly and clearly. Waiting until submission to reveal avoidable problems is not only a UX issue, it can also make the page feel less trustworthy.
Changing The Way I Build Components
I have started building components with their interaction cost in mind from the beginning. If a component needs JavaScript, I want to know what that JavaScript does, when it starts and whether it keeps working after the visitor has stopped using the component. That thinking affects event listeners, animation choices and how much state the component needs to manage.
In many cases, the answer is to keep the behaviour smaller. A disclosure component does not need a large dependency. A basic filter might not need to rebuild the whole page. A hover effect should not require a script. The less work an interaction has to trigger, the more responsive the interface usually feels.
This does not mean removing all JavaScript. It means being more honest about what JavaScript is being asked to do. Some interactions justify a richer client-side approach. Others are better served by HTML, CSS and a small amount of carefully placed scripting.
Retrospective Thoughts
I think the useful shift in 2024 is that performance is becoming harder to separate from interface design. A website is not fast just because it appears quickly. It is fast when the person using it can continue moving through it without the interface getting in their way.
That makes performance a design concern as much as a development concern. A heavy interaction is not only a technical issue. It affects how confident the site feels, how quickly someone can complete a task and whether the interface behaves in a way that matches their expectation.
For me, the question has become simple. After the page loads, does the site still feel ready? If it does not, the performance work is not finished.