Performance is often treated as a final polish step, but learning how to improve INP for SaaS can be the difference between a promising landing page and a product that feels broken before a visitor reaches the signup flow. A recent founder post about cutting a reported interaction delay from 9,856ms to under one second offers an encouraging performance win—and an even better lesson in how founders should measure what happens next.

The original post, shared in r/SaaS by the builder of sidetracked.site, described launching a solo-built product in three weeks, reaching #56 on Product Hunt, landing a first customer in its first week, and attracting a Reddit post with roughly 170,000 views. The founder noticed that Microsoft Clarity was reporting a 9,856ms INP, then applied bundle splitting, lazy loading for authenticated routes, and preconnect hints before reporting a sub-one-second result. The planned next step was paid acquisition and a follow-up on conversion numbers. (reddit.com)

That sequence contains two important stories. First, a landing page with awful responsiveness can still earn attention if the positioning, problem, and product resonate. Second, a large technical improvement is not automatically a clean conversion experiment—especially when traffic source, device mix, visitor familiarity, and campaign creative are changing at the same time.

The SaaS performance story behind the headline

The striking part of the founder’s account is not merely the size of the reported improvement. It is the mismatch between engagement and responsiveness. The post said visitors reached 90% scroll depth despite the very poor interaction metric, suggesting people were willing to keep reading because the offering had enough relevance to overcome the friction. (reddit.com)

For an early-stage SaaS business, that is a valuable signal. Founders often see weak conversion and immediately rewrite the headline, redesign the pricing section, add social proof, or change the onboarding. Those can all be worthwhile moves. But if users are clicking a CTA, opening navigation, switching tabs, entering an email, or opening a demo only to wait several seconds for visual feedback, the site is creating friction below the level of copy and design.

The lesson is not that every startup should chase perfect Lighthouse scores before launch. The lesson is that severe interaction delays are product experience bugs. They can suppress conversion, distort user-research feedback, and make otherwise interested visitors think the product itself will be unreliable.

Attention is not the same as a usable experience

High scroll depth is encouraging, but it does not prove that the page is healthy. People may read a long page while postponing interaction because scrolling works well enough, then abandon when a button, form, or navigation component becomes unresponsive. Scroll depth should therefore be read alongside CTA clicks, rage clicks, form starts, form completion, and the time between a click and the next visible state change.

Microsoft Clarity is built around this kind of behavioral analysis: session recordings reconstruct page visits and user actions such as scrolling, clicks, and taps, allowing teams to investigate how visitors actually experience a site. (learn.microsoft.com) A founder who sees deep reading plus poor responsiveness has a clear investigation path: review the recordings around the first meaningful interaction, then compare the behavior across devices and traffic sources.

A ten-second interaction delay is not merely “slow”

INP stands for Interaction to Next Paint. It measures how long it takes from a user interaction to the next frame the browser can render, giving the visitor visual feedback that their click, tap, or key press was registered. It is not a measure of the entire back-end request or every asynchronous update that follows; it focuses on the period before the browser can visibly respond. (web.dev)

That distinction matters. A button can launch a lengthy server task without necessarily producing a bad INP if the interface immediately acknowledges the click with a spinner, disabled state, progress message, or optimistic update. Conversely, a UI can have a fast API but poor INP if the browser’s main thread is busy parsing JavaScript, calculating layout, or rendering a heavy component.

Google’s current guidance classifies an INP of 200ms or less as good, 200ms to 500ms as needing improvement, and more than 500ms as poor. The recommended assessment is the 75th percentile of page loads, with mobile and desktop considered separately. (web.dev) Against those thresholds, 9,856ms is not a marginal optimization opportunity. It is an urgent usability issue.

What INP actually measures—and what it does not

A common analytics mistake is calling every delay after a click “response time.” That phrasing is understandable, but technically imprecise. Server response time, time to first byte, API latency, JavaScript execution time, and INP can all affect a visitor’s perception of speed, yet they describe different parts of the system.

INP includes three broad phases of an interaction:

  1. Input delay: the user interacts, but the browser cannot start handling the event because the main thread is occupied.
  2. Processing duration: the event handler runs, including JavaScript triggered by the interaction.
  3. Presentation delay: the browser finishes the event work but still needs to calculate styles, layout, paint, or composite the next frame.

A poor score can come from one phase or a combination. Long-running scripts commonly create input delay. Overly expensive click handlers create processing time. Large DOM updates, forced reflows, animations, or expensive rendering create presentation delay. The browser guidance on INP emphasizes that the goal is quick visual feedback, not necessarily completion of all downstream asynchronous work. (web.dev)

Why this distinction changes the remediation plan

If a CTA pauses because a third-party script is monopolizing the main thread, reducing API latency will not solve the primary problem. If the page opens a modal quickly but then waits six seconds for a pricing quote API, code splitting alone will not make checkout feel complete. The first job is identifying which phase is responsible for the slowest interactions.

That is why a founder should not treat a single aggregate INP number as a diagnosis. It is an alarm bell. The operational question is: which interaction, on which route, for which segment, is slow—and why?

Why bundle splitting and lazy routes were plausible fixes

The original founder named three changes: bundle splitting, lazy loading authenticated routes, and preconnect tags. Each can be useful, but they work through different mechanisms. The two JavaScript changes are especially plausible explanations for a dramatic improvement if the previous site was shipping application code that anonymous landing-page visitors never needed. (reddit.com)

Bundle splitting reduces startup work

Code splitting divides a JavaScript application into smaller chunks rather than shipping one large bundle at initial load. A visitor only needs code required for the page and action in front of them; they do not need the dashboard editor, account-management UI, billing components, internal charts, or authenticated route logic just to read a homepage.

The benefit is not solely reduced transfer size. Less JavaScript delivered at startup generally means less parsing, compilation, and execution competing for the browser’s main thread. That can improve input responsiveness during the period when a visitor is most likely to click a navigation item, dismiss a banner, open a modal, or start a form. Official web performance guidance specifically notes that deferred modules can reduce main-thread contention and make interactions more responsive during startup. (web.dev)

Lazy-loading authenticated routes protects the marketing path

Authenticated routes are a frequent source of avoidable payload bloat. SaaS apps naturally accumulate complex components: rich text editors, data tables, analytics charts, export tools, modals, state management, validation libraries, and integrations. Most first-time landing-page visitors will not use any of that code.

Separating the public marketing experience from the logged-in application is therefore both a performance and architecture decision. The public route can be designed around fast content rendering and lightweight interactions. The product application can then load its specialized dependencies after a user has demonstrated intent by signing in or entering the app.

This does not mean developers should indiscriminately lazy-load everything. Excessive fragmentation can create network waterfalls or make later navigations feel slow. The correct standard is route- and interaction-aware loading: load what the user needs now, preload what they are highly likely to need next, and avoid fetching code that is irrelevant to their current journey.

Preconnect is useful, but it is not an INP cure-all

A preconnect resource hint tells the browser to establish early connections to an important third-party origin or cross-origin service. It can reduce connection setup costs for resources that the browser will need soon, such as fonts, a critical API, or a CDN origin.

However, preconnect primarily addresses network setup and resource loading. INP is often governed by main-thread availability at the moment of interaction. Therefore, preconnect may contribute to a snappier overall experience, but it should not automatically be credited as the root-cause fix for a terrible INP score. Web performance guidance distinguishes resource-loading work from the CPU and rendering work that blocks interaction responsiveness. (web.dev)

The community’s caution was correct: do not over-credit one number

The r/SaaS discussion around the post raised the issue many performance retrospectives miss: attribution. One commenter warned that the post’s large Reddit exposure would skew recent traffic toward new visitors, while another noted that a first paid campaign would introduce traffic with a different level of intent than organic social visitors. (reddit.com)

That caution is methodologically sound. A performance deployment can coincide with changes in audience composition, campaign targeting, mobile share, browser mix, day of week, pricing, offer, social proof, or even a temporary spike in curiosity traffic. If conversion improves after all of those variables move, the honest conclusion is not “INP caused a conversion lift.” It is “conversion improved after a bundle of changes, including a material performance fix.”

Why new and returning visitors should be separated

New visitors are evaluating the promise. Returning visitors have already shown some degree of interest and may arrive to compare pricing, finish a signup, revisit a shared link, or check whether the product has improved. Their conversion rate is naturally likely to differ.

A viral Reddit post can also create an unusually broad audience. Some visitors may be founders interested in the build story rather than potential customers. Others may be curious about a Product Hunt launch, a design trend, or a claim in the post. Treating all sessions as equally qualified can make a traffic spike look like a conversion problem when it is actually an intent-mix problem.

At minimum, report conversions separately for:

  • first-time versus returning visitors;
  • organic, referral, direct, email, and paid sessions;
  • mobile versus desktop;
  • landing page route and campaign landing page;
  • countries or regions if campaign targeting varies;
  • visitors who reached a CTA versus visitors who did not.

Why mobile deserves special attention

Desktop computers can mask JavaScript problems because they often have stronger CPUs, more memory, and faster connections than the phones used by many prospective customers. A page that feels merely sluggish on a modern laptop can feel unusable on a mid-range mobile device when startup scripts, analytics tags, layout work, and interaction handlers compete for limited resources.

Google recommends assessing INP at the 75th percentile and segmenting mobile and desktop because a blended average can hide the experience of a meaningful group of users. (web.dev) For a self-serve SaaS landing page, mobile is not a secondary QA environment; it is a separate acquisition surface with its own interaction constraints.

A better method to validate the performance fix

The founder’s reported improvement may be real and highly valuable. The practical issue is how to verify it in a way that supports decisions about engineering priorities and paid acquisition. A robust validation plan combines field data, session evidence, controlled comparisons where feasible, and conversion tracking.

Step 1: create a deployment timeline

Write down the precise date and time for every relevant event:

  • performance code deployed;
  • cache invalidation or CDN rollout completed;
  • analytics configuration changed;
  • new campaign launched;
  • ad creative or targeting changed;
  • pricing, offer, or landing-page copy changed;
  • major referral post or press mention occurred.

This prevents a familiar startup problem: interpreting an uplift from a chart without remembering what else changed during that period. A simple annotated timeline is often more useful than a sophisticated dashboard with no change log.

Step 2: measure the right technical before-and-after slices

Do not compare one global number from an arbitrary day with another global number from a different traffic mix. Compare the same route, device class, browser family where possible, and acquisition channel. Use a meaningful date window long enough to reduce random noise, particularly if the site has low traffic.

Microsoft Clarity’s performance widget aligns with Core Web Vitals and moved from FID to INP in January 2025, making it useful for monitoring real-user performance trends. (learn.microsoft.com) But use it with a clear understanding of the reporting window and segment definitions. Real-user metrics are excellent for understanding actual visitor experience; they are not a replacement for controlled lab testing or event-level funnel analysis.

Step 3: inspect bad sessions, not just the average

Use recordings and filters to find sessions with slow interactions. Watch for repeated taps, rapid multiple clicks, abandoned forms, delayed modal openings, frozen menus, and CTA clicks followed by exits. These patterns reveal whether the score maps to a visible user problem.

Clarity supports filters across dashboard, recordings, and heatmaps, which can help isolate sessions by traffic, performance, path, and user behavior. (learn.microsoft.com) In practical terms, that means a founder can examine “mobile paid visitors on the homepage with poor responsiveness” instead of trying to infer the cause from one sitewide metric.

Step 4: instrument funnel events with timestamps

Track not only whether someone converts, but the intermediate steps:

  1. landing-page view;
  2. CTA seen or scrolled into view;
  3. CTA click;
  4. signup form opened;
  5. form started;
  6. validation error shown, if any;
  7. signup completed;
  8. activation event completed;
  9. payment or subscription completed.

If the performance fix works, an early improvement may show up first as fewer repeated clicks, more form starts, or a shorter interval between CTA click and form interaction. Revenue conversion can lag because it depends on product fit, pricing, onboarding, and sales friction too.

Step 5: use a holdout or phased rollout when practical

For an established product with sufficient traffic, an A/B test is the cleanest method: send a randomized portion of comparable traffic to the old implementation and the rest to the optimized version, then compare both performance and funnel outcomes. For a young SaaS with very little traffic, that may be too slow or impractical.

An alternative is a phased campaign launch. Keep paid targeting, landing-page copy, offer, and analytics stable for an initial measurement period. Avoid stacking a redesign, new testimonial, pricing adjustment, and performance release into the same week. You will not get laboratory-level causal certainty, but you will produce evidence that is far more decision-useful.

A practical INP audit for SaaS founders

Not every founder needs to become a browser-performance specialist. But every founder can adopt a repeatable audit that turns “the site feels slow” into a prioritized engineering queue.

Start with the interactions that make or lose money

Audit the moments closest to conversion before optimizing decorative interactions. On a SaaS site, that normally means:

  • opening the primary CTA or signup flow;
  • typing into email and password fields;
  • validating a form;
  • toggling monthly and annual pricing;
  • opening product screenshots, demos, or videos;
  • logging in;
  • completing onboarding;
  • initiating checkout or billing.

For each interaction, test on a real phone and a throttled development environment. Does the UI acknowledge the action immediately? Is there a loading state? Can users keep scrolling or navigate away? Does a click trigger a long blank pause before anything changes?

Look for the usual JavaScript offenders

The cause is often not one giant mistake. It is a set of individually reasonable dependencies that collectively create too much work during startup. Common candidates include large client-side state libraries, broad icon imports, animation frameworks, full-featured editors, unoptimized charts, support widgets, A/B testing tools, ad pixels, replay analytics, and tag-manager scripts.

Code splitting is especially effective when the issue is unnecessary startup JavaScript. Official guidance recommends sending only the code needed initially rather than loading the entire application upfront. (web.dev) The next question is not “can this dependency be lazy-loaded?” but “does the first-time visitor need it before their first meaningful interaction?”

Find and break up long tasks

Long tasks keep the main thread busy long enough that it cannot promptly react to user input. They may result from script evaluation, expensive loops, hydration work, large JSON processing, rendering complex lists, or synchronous third-party code.

Web.dev’s guidance on long tasks recommends identifying and reducing main-thread blocking work rather than assuming a single universal fix. (web.dev) Depending on the application, that can mean deferring noncritical initialization, chunking a large computation, moving suitable work to a web worker, virtualizing a list, reducing DOM size, or delaying a third-party integration until user intent makes it worthwhile.

Treat third-party scripts as product dependencies

Marketing teams frequently add scripts one at a time: ad measurement, heatmaps, chat, cookie consent, affiliate attribution, social embeds, scheduling widgets, feature flags, and personalization. Each may be defensible in isolation. Together, they can become a startup tax paid by every visitor.

This does not mean analytics is the enemy. It means the business should evaluate third parties like any other vendor: what conversion or operational value does this script create, what is its performance cost, when does it load, and can it be delayed until consent or clear intent? A fast marketing site often comes from enforcing that discipline more consistently than competitors do.

Performance changes should improve feedback, not just scores

The most useful mental model is not “make every request finish instantly.” It is “make every user action feel acknowledged instantly.” An interaction can still involve a network request, validation, or asynchronous calculation, but the page should visibly respond at once.

For example, when a visitor clicks “Start free trial,” the button can change state immediately, the form can appear or route transition can begin, and an accessible status message can announce progress. If the final account-creation request takes longer, the visitor has context and evidence that the app received the command.

This is also why INP is more closely tied to perceived responsiveness than a bare server-latency metric. The browser documentation explains that delayed visual feedback can make users think a page is not working, even when the eventual result arrives. (web.dev) For conversion-focused SaaS teams, perceived reliability is a commercial feature.

What a credible conversion follow-up would look like

A useful follow-up to a performance story would not need to claim that a speed fix alone created a precise percentage lift. It would explain the context, show the segmentation, and distinguish confidence from correlation.

A high-quality report could include:

  • the date of the technical release and the period compared;
  • INP at p75 for mobile and desktop, broken down by landing-page route;
  • the volume and source mix of visitors in each period;
  • first-time and returning visitor conversion rates;
  • CTA click-through rate, signup-start rate, signup-completion rate, and paid conversion rate;
  • screenshots or recordings showing the formerly slow interaction;
  • any concurrent changes to campaign spend, targeting, creative, pricing, or copy;
  • the founder’s best explanation of which code change delivered the biggest impact.

This format is useful even if the result is inconclusive. Suppose INP improves dramatically, CTA engagement improves, but paid conversion remains flat. That is still a productive finding: the site is no longer preventing visitors from acting, and the next constraint may be message-market fit, offer quality, onboarding, or price.

There is evidence that responsiveness improvements can coincide with substantial business gains in larger settings, but those cases should not be blindly generalized to a tiny SaaS launch. In one web.dev case study, QuintoAndar reported an 80% INP reduction alongside a 36% conversion increase after a broader set of changes that included removing third-party pixels and rendering optimizations. (web.dev) The important word is alongside: performance is powerful, but results come from a system of changes, not a magic metric.

The bigger lesson for builders: launch early, then remove friction fast

The original sidetracked.site post is encouraging because it shows an early founder doing the right high-level thing: launch, observe actual behavior, notice a serious mismatch, fix it, and prepare to measure the business outcome. That loop is healthier than spending months polishing an untested product or ignoring real-user evidence because the product has already gained attention. (reddit.com)

The community pushback is equally valuable. It reminds builders that an impressive technical before-and-after does not absolve them from experimental rigor. If a site receives viral organic interest and then starts paid acquisition, the traffic population has changed. If a new campaign runs after a performance release, the campaign may change the denominator. If mobile responsiveness improves more than desktop, a blended number may miss the most meaningful insight.

The best operating principle is simple: fix obvious user pain immediately, then measure the business impact with humility. That gives you the benefits of fast execution without turning every dashboard movement into a misleading success story.

Conclusion: improve INP, then improve the quality of your evidence

To improve INP for SaaS, start with real interactions on the routes that matter most. Reduce unnecessary JavaScript, defer application code that anonymous visitors do not need, investigate long tasks and third-party scripts, and make every high-intent action produce immediate visual feedback.

But do not stop at the score. Segment the field data, watch slow sessions, separate new from returning visitors, isolate mobile performance, and avoid changing traffic strategy at the same moment you expect to measure a technical lift. A faster site is a meaningful product improvement. A careful measurement plan is what turns that improvement into a repeatable growth decision.

FAQ

What is a good INP score for a SaaS landing page?

A good INP is 200ms or less at the 75th percentile of page loads. Scores from 200ms to 500ms need improvement, while scores above 500ms are classified as poor. Review mobile and desktop separately rather than relying only on a blended score. (web.dev)

Can code splitting improve INP?

Yes, particularly when a page loads more JavaScript than a first-time visitor needs. Code splitting can reduce download, parsing, compilation, and main-thread work during startup, leaving the browser more available to react to early clicks and taps. (web.dev)

Does preconnect improve Interaction to Next Paint?

It can help resource loading by starting connections earlier, but it is not usually the direct solution to main-thread blocking. Investigate long tasks, event handlers, rendering work, and unnecessary JavaScript when INP is poor. (web.dev)

How do I know whether a performance fix increased conversions?

Compare similar visitor segments before and after the release, separating device type, traffic source, route, and new versus returning visitors. Track intermediate events such as CTA clicks and signup starts, document concurrent changes, and use an A/B test or phased rollout when traffic volume allows.

Why can a landing page have high scroll depth but poor conversion?

Visitors may be interested enough to read but encounter friction when they try to interact. Slow CTAs, delayed forms, broken-feeling navigation, unclear offers, pricing concerns, or onboarding friction can all prevent deep engagement from becoming a signup or purchase.