This is the first part of this series, where we will learn how to prevent analytics code from slowing down user interactions, which in turn can help improve user experience (UX) and boost sales.

We all know that feeling - we're trying to book something online, but the website is taking forever to load. It's frustrating, right? Slow websites can really kill the mood and make people just give up and go somewhere else. That's why website speed is so important, not just for keeping visitors happy and sales coming in, but also for achieving good Core Web Vitals (CWV) scores that helps with more visibility!

Interaction to Next Paint (INP), which measures how quickly your website responds to user interactions like clicks, is a newly added metric to Core Web Vitals (CWV) that can impact your SEO rankings.

Why Speed Matters?
Did you know that by removing just 100 milliseconds of latency Amazon pulled up sales by 1%? That's a big deal especially looking at the scale they operate at!

Slow websites definitely hurt your bottom line and it's not only about load times - it's about keeping things snappy when people are actually using your site too. If clicks and scrolls feel sluggish, that's a major turn-off.

The Analytics Code Dilemma:

Analytics code execution comes up as one of the main culprit for bad responsiveness to user interactions.

You might be thinking "But I need things like analytics to track how people use my site!" And you're absolutely right. The tricky thing is, all that analytics code can actually be what's slowing your site down in the first place.

The problem lies in the fact that the browser has a single main thread to handle all tasks. This includes rendering the UI, running JavaScript, and executing analytics code. When the analytics code runs on the main thread, it can block other important tasks like responding to user interactions such as clicks and scrolls. This creates a bottleneck, leading to a sluggish and unresponsive experience for your visitors.

The idle until urgent solution:
That's where [idlefy](https://www.npmjs.com/package/idlefy) comes in. It's a typescript library that helps speed up your site by running analytics code at smart times, when the browser isn't busy with other important tasks. Instead of jamming up the works, idlefy lets your site stay smooth and zippy for visitors.

import {IdleQueue} from 'idlefy';

const queue = new IdleQueue({ ensureTasksRun: true }); 
//ensureTaskRun makes sure the tasks run on visibilitychange event

queue.pushTask(() => {
  // Some expensive function that can be deferred
});

queue.pushTask(() => ga('send', 'pageview'));
queue.pushTask(() => {
   ga('send', 'event', {
      eventCategory: 'Signup Button',
      eventAction: 'click',
   });
});

In the above image it is evident, for the same interaction the code is executed after important stuff is done i.e. responding to user.

It works on the proven idle-until-urgent pattern which under the hood uses requestIdleCallback and it also brings additional goodies out of box such as:

• Guaranteed execution of analytics code, even if someone leaves the page
• Built with modern TypeScript for safety and better IntelliSense support
• Works perfectly with server-side rendering
• Tiny file size so it doesn't drag your site down(<2KB gzipped)
• Tunable to fit your exact needs

Results:

At Redbus, we used idlefy for more than 2 months and saw amazing results. Our website INP scores improved by almost 50%, from 351 to 179!

That's the kind of speed boost that helped our sales as it kept customers clicking and converting.

If you're ready to zip up your website's performance, give [idlefy](https://www.npmjs.com/package/idlefy) a shot. It's easy to add to your codebase and the payoff in better UX and higher conversions is totally worth it. Your visitors (and your sales numbers!) will thank you.

Follow me for more such web-performance related stuff and stay tuned for the part 2 of this series where we will offload third-party scripts to web-worker which in return helps us improves load times of our websites.

If you want to read a more detailed version of this blog, visit redbus-blog.