From F&B to fintech, clinics to law firms, startups to enterprise. If your customers search on Google, we make sure they find you first, not your competitors.
One specialist team, focused only on the organic rankings that put you in front of ready-to-buy Singapore customers.
A clear, sequenced path from audit to rankings. You always know what we’re doing and why it matters for your leads.
Quick answer: INP (Interaction to Next Paint) measures how quickly a page responds when someone clicks, taps, or types. It replaced First Input Delay as an official Core Web Vital in March 2024. Google’s threshold is 200 milliseconds. Singapore sites usually fail this because of heavy JavaScript, third-party scripts, and unoptimised event handlers slowing down the browser’s main thread.
Interaction to Next Paint is the newest of Google’s three Core Web Vitals, and it is the one causing the most confusion among Singapore business owners right now, mostly because it quietly replaced a different metric that many site owners had only just gotten comfortable with. INP measures responsiveness: how long a page takes to visually respond after a visitor interacts with it, clicking a button, tapping a menu, typing into a search box. If that response feels laggy or delayed, INP flags it, even if the page loaded quickly to begin with.
In our experience, INP is the Core Web Vital most closely tied to how “cheap” or bloated a site’s JavaScript is, and it is the metric where we see the biggest gap between sites built on lightweight, well-maintained code and sites that have accumulated years of plugins, trackers, and third-party widgets without anyone ever auditing what is actually running in the background. This guide explains what changed, why it matters, and exactly how to fix INP issues on a Singapore business website.
Until March 2024, Google’s responsiveness metric was First Input Delay (FID), which measured only the delay before the browser started processing a user’s first interaction with a page. FID had a known limitation: it only captured the very first interaction and only measured the delay before processing began, not how long the actual response took to render.
INP is more comprehensive. It observes all interactions during a visitor’s time on the page, click, tap, and keyboard interactions, and measures the full time from interaction to the next visual update on screen, not just the initial delay. Google then reports (roughly) the worst interaction latency a typical visitor experiences, giving a far more realistic picture of whether a site actually feels responsive throughout the entire visit, not just on the first click.
| INP Score | Rating | User Experience |
|---|---|---|
| 0 to 200ms | Good | Interactions feel instant and responsive |
| 200 to 500ms | Needs Improvement | Noticeable lag between action and response |
| Above 500ms | Poor | Site feels sluggish, frustrating, or broken |
This shift matters more for interactive Singapore sites, such as ecommerce stores with filters and cart interactions, booking platforms, and any site with menus, accordions, or forms, than it does for a simple static brochure site with minimal interactivity.
Heavy, unoptimised JavaScript is the leading cause. Every script running on a page competes for the browser’s main thread, and if a large JavaScript bundle is still executing when a visitor clicks something, that click has to wait in a queue before the browser can even begin processing it.
Excessive third-party scripts compound this heavily. Chat widgets, analytics suites, marketing pixels, A/B testing tools, and heatmap trackers each add their own JavaScript execution overhead, and Singapore businesses running multiple marketing and analytics tools simultaneously (which is common, and often necessary) frequently stack up enough third-party code to noticeably degrade interaction responsiveness.
Unoptimised event handlers are the more technical culprit, where a single click or tap triggers a long-running JavaScript function, re-rendering large portions of the page, running expensive calculations, or triggering multiple downstream events, all before the browser can paint the visual response the user expected.
Large DOM size also plays a role. Pages with thousands of DOM elements (common on product listing pages with dozens of products, each with multiple nested elements) take longer for the browser to process any interaction that touches or affects the page’s layout, because more elements mean more computation.
Google PageSpeed Insights now reports INP directly (for URLs with sufficient field data) rather than FID, and its Diagnostics section highlights JavaScript execution time and main-thread work as contributing factors. Search Console’s Core Web Vitals report shows INP trends across your site, grouped by URL, using real visitor interaction data collected over the past 28 days, which is the most reliable source since INP genuinely depends on how real users interact with your specific pages.
For a hands-on diagnosis, Chrome DevTools’ Performance panel lets you record actual interactions, clicking a button, opening a menu, and see exactly which JavaScript function was still running when you clicked, and how long the browser took to respond. This is where we typically find the specific culprit script, rather than a general symptom.
1. Break up long JavaScript tasks. Any function that takes longer than 50 milliseconds to execute should be split into smaller chunks so the browser can process user interactions in between, rather than blocking on one long task.
2. Defer and lazy-load non-critical JavaScript. Scripts that are not needed for the initial interactive experience, below-the-fold widgets, secondary marketing tools, should load after the main content is interactive, not competing with it during initial load.
3. Audit and reduce third-party scripts. Go through every script tag on your site and ask whether it is still needed. In our experience working with Singapore ecommerce and service businesses, it is common to find two or three tracking scripts left over from campaigns that ended months earlier, quietly still executing on every page load.
4. Debounce or throttle expensive event handlers, particularly for scroll, resize, and input events that fire repeatedly and can trigger unnecessary recalculation if not properly managed.
5. Reduce DOM size where practical. For product listing or category pages, consider pagination or virtualised rendering (only rendering visible items) rather than loading hundreds of product cards into the DOM simultaneously.
6. Use code-splitting for JavaScript frameworks. If your site is built on React, Vue, or a similar framework, ensure code-splitting is configured so visitors only download the JavaScript needed for the page they are on, rather than the entire application bundle upfront.
Not every site type is equally at risk here. Static brochure sites with minimal interactivity, common among smaller local service businesses, rarely have serious INP problems, because there simply is not much JavaScript running to begin with. But we consistently see INP issues on ecommerce stores with dynamic filtering, real estate portals with interactive map search, and booking or reservation systems where every interaction triggers a chain of JavaScript events.
If your business relies on visitors filling in forms, applying filters, or using interactive search tools, particularly on mobile devices where processing power is more limited than desktop, INP deserves closer attention than LCP or CLS, because a laggy interaction at the exact moment someone is trying to convert (adding to cart, submitting an enquiry) has an outsized impact on both user experience and, ultimately, revenue.
Filter-heavy category pages are where INP problems most often show up on ecommerce sites, and the diagnosis follows a consistent order. Start with a Chrome DevTools Performance recording while you click a filter checkbox on a mid-range phone profile, and look for long tasks that run between the click and the next paint. The usual culprit is filter logic that re-renders the entire product grid on every change instead of updating only the affected product cards. Rewriting that logic to touch only the elements that change, deferring marketing and analytics scripts that do not need to block interaction, and splitting the JavaScript bundle so filter code loads only where it is used will normally bring the biggest improvement. Then re-test against field data in Search Console rather than relying on a single lab run.
Filters carry an SEO cost too: in our ecommerce case study, 14 faceted navigation parameter combinations had been generating duplicate content until we blocked them in robots.txt.
A lot of common advice suggests that INP is purely a “developer problem” that marketing teams and business owners cannot influence. That is not accurate. Every third-party script a marketing team adds, another chat plugin, another tracking pixel, another popup tool, directly contributes to INP, and reducing the number of tools running on a site is often within a business owner’s control without needing a developer at all.
Another myth is that a site which “feels fast” to the owner on their office WiFi and a fast laptop must have good INP. Interaction responsiveness depends heavily on the visitor’s device processing power, and INP problems are consistently worse on mid-range mobile phones, which represent a significant share of Singapore’s mobile browsing traffic, than on the high-end devices most site owners test with themselves.
Like the other Core Web Vitals, INP tends to drift back into “needs improvement” territory as new scripts get added over time. We recommend auditing third-party scripts at least quarterly, and specifically any time a new marketing tool, tracking pixel, or embedded widget is added to the site. This is a core part of the ongoing technical work we do for clients under technical SEO retainers, since INP regressions are easy to introduce and easy to miss until Search Console flags them weeks later.
INP problems are frequently a symptom of a wider issue: too much third-party code accumulated over years without anyone auditing what is actually still needed. This is exactly the kind of structural cleanup we handle as part of a full technical SEO engagement, since fixing INP in isolation, without looking at why the JavaScript bloat accumulated in the first place, tends to produce a temporary improvement that drifts back within a few months as new tools get added.
If your business runs an active marketing programme with multiple tools, retargeting pixels, A/B testing platforms, heatmap trackers, live chat, it is worth having a technical specialist review the full stack periodically rather than leaving it to accumulate indefinitely. Our broader SEO services cover this kind of ongoing technical health work, and you can see more about how we structure these engagements on our about page, with cost details on our pricing page.
INP problems concentrate most heavily on sites with genuinely interactive features rather than static brochure pages, and in our experience this makes it a particularly important metric for ecommerce stores with filtering and search, and for professional services firms running interactive calculators, quote tools, or multi-step enquiry forms. A law firm’s case assessment tool or a financial advisory’s calculator, both increasingly common on Singapore professional services sites, can suffer serious INP problems if the underlying logic recalculates too much on every keystroke or click.
We worked through related performance issues as part of the broader technical improvements reflected in our law firm SEO results case study, where render-blocking JavaScript deferral, image compression and font loading fixes lifted mobile Lighthouse from 52 to 81 alongside the more typical content and authority-building work most people associate with law firm SEO.
Because INP is newer than LCP and CLS as an official Core Web Vital, many Singapore businesses have not yet had it flagged in Search Console simply because they have not checked recently, or their previous audit predates the March 2024 change. If your last technical review happened before that date, it is worth treating INP as an unknown rather than assuming it passes by default, since a site that was perfectly fine under the old FID metric can still fail INP if it has heavy interactive JavaScript that FID’s narrower measurement never caught. We recommend a fresh Core Web Vitals check specifically for INP if your last audit is more than a year old.
The technical foundation of most INP problems comes down to what browser engineers call “long tasks,” any single piece of JavaScript execution that blocks the browser’s main thread for more than 50 milliseconds without yielding. While that task is running, the browser cannot respond to any user interaction, a click just sits queued until the task finishes, which is exactly what INP is measuring. Understanding this threshold helps explain why breaking up JavaScript work matters so much more than simply “writing less code”: a single 300 millisecond task is far more damaging to INP than five separate 60 millisecond tasks, even though the total execution time is similar, because the browser gets opportunities to respond to interactions between the smaller tasks.
Modern JavaScript includes APIs specifically designed to help with this, isInputPending() and the newer scheduler.yield(), which let developers write code that voluntarily pauses and checks whether the browser needs to handle a pending interaction before continuing. For Singapore businesses running custom-built web applications rather than off-the-shelf WordPress or Shopify sites, asking your development team whether these APIs are being used in performance-critical code paths is a reasonable, specific question that goes beyond generic advice.
Because marketing teams, not developers, are usually the ones adding new tracking pixels, chat widgets, and campaign tools, INP governance benefits enormously from a simple internal process: any new third-party script needs sign-off from whoever owns site performance before it goes live, not after. We recommend Singapore businesses maintain a simple running list of every third-party script currently active on their site, what it does, who requested it, and when it was added, reviewed at minimum quarterly. This single practice prevents the slow, invisible accumulation of scripts that is the single most common root cause of INP failure we encounter during audits.
When we run this kind of review for clients, it is common to find scripts tied to campaigns that ended a year or more ago, tools trialled once and never removed, or duplicate analytics platforms added by different team members unaware the other already existed. None of this requires deep technical expertise to catch, just a disciplined, periodic audit, which is something we build into ongoing technical SEO retainers specifically because it needs to happen repeatedly, not once.
While this guide has focused specifically on INP, it is worth remembering that Google evaluates LCP, CLS, and INP together as your overall Core Web Vitals assessment, a page needs to pass all three to be considered fully healthy in Search Console’s reporting. A site that has excellent LCP and CLS but fails INP will still show as an overall failure, which is why we always recommend checking all three together rather than fixating on just the one that happens to be flagged most visibly. In our experience, sites that fail INP specifically often pass the other two comfortably, since the underlying causes, JavaScript execution and third-party scripts, are fairly distinct from image weight and layout stability issues.
One detail worth flagging is that INP genuinely cannot be measured accurately in a quick, artificial lab test the way LCP and CLS can, because it depends on actual human interaction patterns rather than a fixed page load sequence. This is why Chrome DevTools’ Performance panel, where you manually click and interact with the page while recording, tends to be more revealing than any automated single-run test. We generally ask a few different team members to interact with a page naturally, clicking through a filter, opening a menu, submitting a form, while recording, since different people interact with a page slightly differently and this variation often surfaces INP issues a single scripted test would miss entirely.
Interaction responsiveness shapes how trustworthy and competent a business feels to a visitor, often more than visitors consciously realise. A form that submits instantly, a filter that updates without delay, a menu that opens the moment it is tapped, these small moments accumulate into an overall impression of quality that extends well beyond the website itself, into how a visitor perceives the business behind it. For Singapore businesses competing in crowded categories, ecommerce, professional services, hospitality, where visitors routinely compare multiple options within the same browsing session, this kind of subtle, cumulative impression can be a genuine differentiator even when it is never explicitly mentioned in a review or a piece of feedback.
Field notes: In our law firm case study, render-blocking JavaScript deferral was one of three fixes, alongside image compression and font loading optimisation, that lifted the firm’s mobile Lighthouse score from 52 to 81 in Month 1. Scripts that block the main thread hurt loading and interaction alike, so deferring anything that does not need to run immediately is often the cheapest responsiveness win available.
INP (Interaction to Next Paint) measures how quickly a page responds to user interactions like clicks and taps. It officially replaced First Input Delay (FID) as one of Google’s three Core Web Vitals in March 2024.
Google considers an INP of 200 milliseconds or under to be “good.” Between 200 and 500 milliseconds is rated “needs improvement,” and above 500 milliseconds is rated “poor.”
FID only measured the delay before the browser started processing the very first interaction on a page. INP measures the full response time, from interaction to visual update, across all interactions during a visit, giving a more complete picture of responsiveness.
Ecommerce sites typically have more interactive elements, filters, cart updates, dynamic product grids, each requiring JavaScript execution. If that JavaScript is unoptimised or heavy, every interaction can trigger a delay, which is why filter and category pages are common INP trouble spots.
Yes, often significantly. Each third-party script, chat widgets, tracking pixels, popups, adds JavaScript execution overhead that competes with user interactions for the browser’s processing time. Removing unused or redundant scripts is one of the fastest ways to improve INP.
Generally yes, because mobile devices, particularly mid-range phones common among Singapore users, have less processing power than desktop computers, making JavaScript execution delays more noticeable and more likely to push INP into a poor rating.
Google PageSpeed Insights reports INP directly for pages with sufficient real-user data, and Search Console’s Core Web Vitals report shows INP trends across your whole site. Chrome DevTools’ Performance panel lets you diagnose specific slow interactions in detail.
Simple fixes, like removing unused third-party scripts, can show improvement within days. More involved fixes, such as rewriting inefficient JavaScript or restructuring how a page renders, typically take 3 to 6 weeks depending on the complexity of the site.
If your site’s buttons, filters, or forms feel sluggish to use, it is worth finding out exactly which scripts are responsible before it affects your rankings or your conversions. Request a free consultation and we will show you precisely what is slowing your interactions down.
Natalie leads SEO strategy at Singapore SEO Agency, helping local and regional businesses build organic search programmes that drive qualified leads. She specialises in technical SEO and content-led authority building for Singapore SMEs.
Get a free SEO audit for your Singapore website — we'll show you exactly where you stand, what's holding you back, and what it would take to rank on page 1.
Get Your Free SEO Audit →
Which free keyword research tool should a Singapore clinic, firm, contractor or tutor use? Combine five free tools to find your first 30-50 keywords. See how.
SEO vs SEM is usually the wrong question. Learn what the terms really mean and how to use ads and Search Console data to decide which searches to earn or buy.
Google Search Console login problems usually start with verification and ownership. Learn how to get in, fix access errors and offboard agencies safely.
The click through rate formula is clicks divided by impressions. Learn what each platform counts, the averaging trap and how to set it up in Google Sheets.
A click through rate means nothing on its own. Learn to compare CTR by position, query type and SERP features, and see what low CTR is really telling you.
What a google analytics certification proves, what it misses, how to verify one and the practical questions to ask before you hire a marketer or freelancer.
Fast, no obligation. We reply within 24 hrs.
Singapore’s specialist SEO agency for SMEs. We rank your business on Google — and only Google. No distractions, just results.
© 2026 Singapore SEO Agency. All rights reserved.