In my experience of building consumer web applications, they all start fast.
Then someone says “We need to track every interaction in mixpanel. What’s even the point if we don’t know it happened”.
Then the sales team says “We need to track in Salesforce, nobody on our team looks at mixpanel”
Then the marketing team goes “We must consolidate in google analytics, nothing else fits our usecase”
Then the other product team says “We need Amplitude”
Then the re-engagement marketing team goes “Braze for us please, we must know when customers do a thing so we can trigger campaigns”
Then the product growth hacker marketing team says “Our recommendation engine needs to use the custom in-house framework so we can train our models”
Then someone goes “Hey it looks like we’re losing events sometimes, you have to make sure users don’t leave the screen until all events are submitted”
Then someone has a cool idea: “Wow it would be great if we could see where users are looking with something like Hotjar”
And now you have an app where every interaction triggers 20 different trackers, waits for all of them to settle, then reacts to your action. Just look at the AWS homepage one day – I once counted 70 requests blocked by Brave’s built-in blockers before I even moved my mouse. It’s slightly better after login – only a dozen or so tracker requests iirc.
case in point, AWS homepage is miles ahead any smart tv menu and I doubt they write it in rust.
Anything CPU-bound blocks the JS-based UI thread on web, but not necessarily the browser’s native UI thread. However you would have to do pretty egregious things for this to be a noticeable problem, you almost certainly won’t get there with tracking scripts.
The issue is I/O-bound work. This doesn’t block the UI, but you aren’t guaranteed that the user will stick around for you to make those requests. So you generally want to flush them immediately, or in critical cases even wait for them to complete.
As soon as you’re waiting for API requests to complete before updating the UI, you add 10s to 100s milliseconds of lag to every interaction. But this doesn’t block natively rendered interactions (like form inputs), just the parts you control via JavaScript (like what’s on the page).
Ah but you could just not render things with JavaScript and let the browser handle it! Yes. Except now you are almost guaranteed to lose tracking events because you trigger page-level navigation before even firing your asynchronous events. The browser bails on all requests the page was making as soon as you leave the page.
But once you build up enough of those background waiting tasks, you can actually cause enough CPU-bound work to be noticeable. Kinda like a garbage collection cycle. On top of that you’re limited to how many concurrent API requests (10 I think) the browser can make so if you’re sending requests to 10 different services, now the requests your user cares about are waiting in line.
tldr: on the web a user may hard close your app at any point, so people make things feel slow in an effort to work around this. There are also some hard limits you may run into if not careful
