[philipwalton]

Article author here. Yep, not hiding that fact (I could have easily used a trace with minified code, but I didn't to point this out).

Two things though:

1. I used to work on Google Analytics, and I've created a lot of open source libraries around Google Analytics, which I use on my own site because I like to test my own libraries (and feel any pain they may be causing). The way most people use Google Analytics does not block for nearly this long.

2. I've updated my Google Analytics libraries to take advantage of this strategy [1], and I'm working with some of my old teams internally to see if they can bake it in to GA's core analytics.js library, because I strongly believe that analytics code should never degrade the user experience.

[1] https://github.com/googleanalytics/autotrack/pull/235

[sequoia]

> Yep, not hiding that fact (I could have easily used a trace with minified code, but I didn't to point this out).

Kudos to you for your honesty here! I was a bit confused by your question "So what’s taking so long to run?" when it seemed pretty clear what was taking so long to run. If the goal were simply "speed up the pageload/FID", removing browser analytics (in favor of server e.g.) would seem to be at least an _option_ to immediately achieve that end.

Thanks for the article.

[philipwalton]

Right, when I said "what's taking so long to run?", in my mind I was thinking there'd be one obviously slow thing that I could just remove or refactor, but it turned out that it wasn't any one single slow function/API causing the problem.

And yes, clearly removing the analytics code would have also solved the problem for me, and in many cases, removing code is the best solution.

In this particular case I couldn't remove any code because I was refactoring an open source library that a lot of people use. I wanted to try to make it better for input responsiveness in general, so people who use the library (and maybe don't know much about performance) will benefit for free.

Also, I wanted to help educate people about how tasks run on the browser's main thread, and how certain coding styles can lead to higher than expected input latency.

Anyway, glad you enjoyed the post!

[jschwartzi]

If I had a nickel for every timea page load was blocked connecting to an analytics platform I would be able to retire.

[philipwalton]

It's likely not "blocked" by analytics since pretty much all analytics libraries get loaded async.

However, scripts loaded before the `load` event do delay the load event, and analytics script are typically loaded with the lowest priority, so they're usually last and thus the ones you notice in the bottom-left corner of your window.

But the only way they'd be "blocking" anything is if the site was waiting for the load event to initialize any critical functionality (which it shouldn't be).

[nathancahill]

Shouldn't, but this is absolutely common in the wild. Another one I get often (which makes me need to disable my ad blocker) is UI actions that first log the action in X analytics library and then execute the function. When X library is blocked, the code path never reaches the function. Off the top of my head, flight/hotel reservation websites are particularly bad about this.