INP on Service Websites: Keeping Menus and Forms Responsive

A service website can load quickly and still feel broken. A visitor taps the menu icon and nothing happens, so they tap again. When the browser catches up, it handles both taps, and the menu opens and then closes. The page loaded fine. The problem is what happened after it loaded.

Interaction to Next Paint (INP) is the Core Web Vitals metric built to measure that moment. This article explains what INP measures, what the HTTP Archive’s 2025 Web Almanac shows about responsiveness on mobile, and where service sites tend to lose time: mobile menus, FAQ accordions, inquiry forms, and the third-party scripts that load alongside them.

---

Why a fast-loading page can still feel slow

Most performance work concentrates on loading: how soon the headline and hero image appear. Loading is only the start of a visit. In its INP guide, the Chrome team at web.dev says Chrome usage data shows 90% of a user’s time on a page is spent after it loads. That’s when visitors open menus, expand service details, and fill in the inquiry form.

On a typical service site, the interactions that matter most are simple:

• Opening the mobile navigation to find a service page.
• Expanding an FAQ or pricing accordion to check a detail before getting in touch.
• Typing into and submitting an inquiry form, often with validation running on each keystroke.
• Dismissing a cookie banner or chat prompt that sits over the content.

None of these is technically demanding. When one of them stalls, though, the visitor can’t tell whether the site is slow or broken, and that uncertainty arrives at the worst point in the visit.

---

What Interaction to Next Paint measures

INP looks at every click, tap, and keyboard interaction during a visit and reports one value: the slowest interaction, with an allowance for outliers on very busy pages. MDN notes that INP replaced First Input Delay (FID) as a Core Web Vital in May 2024. The difference is scope. FID measured only the delay before the first interaction was handled, while INP covers all of them and runs until the browser paints the next frame.

Each interaction has three parts, as web.dev describes them:

1. Input delay: the wait before the page’s event handlers can start, often because the browser is busy with other work.
2. Processing duration: the time those handlers take to run.
3. Presentation delay: the time from the end of the handlers until the browser paints the next frame showing the result.

The thresholds apply at the 75th percentile of page visits, measured separately for mobile and desktop. An INP of 200 milliseconds or less is “good.” Above 200 and up to 500 milliseconds “needs improvement,” and above 500 milliseconds is “poor.” In practice, this means three out of four visits should get visible feedback within a fifth of a second.

Some things aren’t counted. Scrolling, hovering, and zooming are excluded. MDN also notes that asynchronous work such as a network request usually doesn’t delay INP, because the browser can paint while it waits. A form that shows a “Sending…” state immediately and then waits for the server can still score well. A form that does nothing visible until the server replies may score well too, but it will still feel unresponsive. INP measures the first visible feedback, not whether the whole task is finished.

Why the main thread is the bottleneck

Most of this work happens on the browser’s main thread, which handles one task at a time. web.dev defines any task longer than 50 milliseconds as a long task. While it runs, a tap has to wait in line.

It works much like a shop with one cashier. The queue moves quickly until someone ahead of you has a long, complicated order, and then everyone behind them waits, however small their own purchase. The comparison has a limit: a browser can split its work into smaller tasks and let urgent input go first, which a cashier usually can’t. That splitting is where most INP improvements come from.

---

What the 2025 Web Almanac shows, and its limits

The HTTP Archive’s Web Almanac 2025 Performance chapter, published in January 2026, combines lab crawls with field data from the Chrome UX Report (CrUX), a dataset of real Chrome users’ experiences. Its main analysis uses July 2025 data. Several findings are relevant to service sites:

• Mobile still trails desktop. 77% of websites had good INP on mobile, up from 74% in 2024. On desktop the figure was 97%. The 20-point gap narrowed by three points from the previous year.
• Inner pages are worse than the homepage on mobile. Using page-level CrUX data, 80% of mobile home pages had good INP, compared with 69% of secondary pages. In 2024 the two were almost the same (73% and 72%). The authors suggest that secondary pages carry more complex interactions, such as filters, carousels, and form validation, and collect third-party scripts that run deeper in the visit.
• Main-thread blocking is growing in the lab. The median mobile Total Blocking Time (TBT), a lab measure of how long the main thread was blocked after first content appeared, rose to 1,916 milliseconds, 58% above 2024’s 1,209 milliseconds. The authors call this an apparent contradiction with improving field INP, and give possible explanations: faster real devices hiding heavier code, sites optimizing only the interactions that dominate INP, and changes to the metric itself.

The Almanac’s Third Parties chapter adds context. At least 90% of pages load one or more third parties, and the median inclusion chain is three deep. In other words, a script you add often loads other scripts you never chose directly.

These are web-wide figures. They describe trends across millions of origins, not the performance of any particular service site, and they’re based on Chrome data. For a service site, the practical reading is to check the pages where visitors make decisions, such as service details, pricing, and contact, rather than judging responsiveness by the homepage alone.

What INP and the data don’t tell you

INP is a useful measure, but it doesn’t cover everything. It reports the visible response, not whether the task was completed, so a form can score well and still lose inquiries to unclear errors. It ignores scrolling, so heavy scroll effects need separate checks. CrUX data comes only from Chrome, although the Almanac notes that support for reporting INP has started to expand to other browsers.

Search rankings deserve an equally careful reading. Google Search Central says Core Web Vitals are used by its ranking systems, but also that good scores in its reports or third-party tools don’t guarantee top rankings, and that chasing a perfect score only for SEO reasons “may not be the best use of your time.” The stronger reason to work on INP is the visitor holding a phone who wants the menu to open.

There is also a cost tradeoff. Some fixes, like deferring a chat widget, are simple configuration changes. Others mean rewriting component logic. Base the decision on field data and on how much each interaction matters to inquiries, rather than on a lab score.

“A fast homepage proves the site can load. A responsive contact page proves it can be used.”
— Windware Studio Practice Note

---

Where service sites lose responsiveness

The three parts of an interaction give each kind of delay a likely cause. This table maps common service-site components to where the time usually goes:

Component	Where the delay usually sits	Likely cause	Native-first or lighter alternative
Mobile menu toggle	Input delay	Scripts still parsing and running while the page loads	A <button> that toggles a class, with non-critical scripts deferred
FAQ or pricing accordion	Processing duration	Handlers that also track analytics or re-measure the layout	<details> and <summary>, or a handler that only toggles visibility
Inquiry form validation	Processing duration	Validating every field on every keystroke, or validating and saving in the same task	Validate on blur or submit, and update the error message before other work
Form submission	Processing and presentation delay	Waiting for analytics or CRM scripts before showing any feedback	Show the “Sending…” state first, then run the rest
Cookie banner or chat widget	Input delay	Third-party scripts competing for the main thread during load	Load the widget after the main content or behind a click, and keep the consent script light
Embedded maps or video	Any phase	Interactions inside an iframe count toward the page’s INP	A static preview that loads the embed on request

The iframe row is easy to miss. web.dev explains that interactions inside embedded frames count toward the top-level page’s INP, because the visitor doesn’t know or care what’s in an iframe. A map embed on a contact page is part of that page’s responsiveness.

---

A measurement-first method for improving INP

Start with evidence, then reproduce, then fix. web.dev recommends this order because lab tests may not surface the interactions that real visitors find slow.

Step 1: Find out whether there’s a problem

• CrUX via PageSpeed Insights or Search Console. If your site has enough Chrome traffic to qualify for CrUX, you’ll get an origin-level INP figure and sometimes page-level data. Many small service sites don’t qualify, so a missing value is a normal result, not a failure.
• Real User Monitoring (RUM). Collecting INP from your own visitors, for example with Google’s open-source web-vitals library and its onINP() function, shows which interaction was slow and in which part. That’s the information CrUX doesn’t provide.

Step 2: Reproduce it in the lab

Follow the real flows on a mid-range phone or with CPU throttling: open the menu, expand an FAQ, type into the form, and submit it. Repeat this while the page is still loading, when web.dev notes the main thread is usually busiest. TBT is a reasonable stand-in when you have no field data, but as web.dev puts it, it’s a proxy, not a replacement for INP.

Step 3: Fix the slowest part first

• Paint first, then do the rest. In each handler, run only the code that changes what the visitor sees, then defer analytics, saving, and logging to a later task.
• Yield to the main thread. Break long work with setTimeout(), or with scheduler.yield() where supported. web.dev notes it isn’t supported in all browsers yet, so use a fallback.
• Reduce startup script work. Remove plugins and widgets the page doesn’t need, and defer scripts that aren’t needed for the first interaction.
• Avoid layout thrashing. Don’t change styles and then immediately read layout values in the same task.
• Keep the DOM lean. Rendering work grows with DOM size, so heavy page-builder markup makes every update slower.
• Audit third parties by page. List what loads on the contact and service pages specifically, not only the homepage.
• Re-measure after each change. web.dev describes INP improvement as iterative, and fixing one slow interaction often reveals the next.

---

Practical takeaways for your next website

1. Measure responsiveness on the pages that convert. Check service, pricing, and contact pages, not only the homepage. The Almanac’s mobile data shows inner pages lagging.
2. Show feedback before doing the work. Opening the menu, showing the error message, or displaying the “Sending…” state should come before analytics or network calls.
3. Treat every third-party script as a cost. Each one competes for the same main thread your visitors’ taps use, and many load more scripts behind them.
4. Use native elements where they fit. Buttons, <details>, and standard form controls bring built-in behavior that needs little or no JavaScript.
5. Use field data to choose what to fix. Lab tests help reproduce problems, but real visits show which interactions are slow.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help you build pages that respond the moment visitors tap, type, and send.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].