Looking at the blog post, I'd say it was for drawer.init(), contentLoader.init(), breakpoints.init(), alerts.init(), and analytics.init(). The site works fine without javascript, so it doesn't need it - perhaps the author thinks the 50k is worth the drawer, content loading, breakpoint?, and alert features and also wants a bit of user analytics tracking.

Even so, you could backload the drawer etc. placing them at the end of the document and attaching to potentially already rendered page.

Reorder so that your main content loads first.

Author did part of it by deferring the analytics init. Not sure why they used setTimeout though for the initialization instead of requestIdleTimeout like everything else. The page is supposed to work without JS after all.

"I mentioned above that requestIdleCallback() doesn’t come with any guarantees that the callback will ever run."

Not true - there's a timeout argument. It guarantees that the callback will by ran by then.

Regardless of the demonstrated use case, these principles can be applied to improve the performance of web pages that use JavaScript

Thank you. That'd be like someone criticizing a coding example for a new language saying "What's the point of using OOP for implementing Tic-Tac-Toe? It's too simple to necessitate it."

I'm not criticizing the technique from the article. It's useful. I'm just expressing my confusion that the blog, simple as it looks, needs this JavaScript (and analytics are in a separate file from the one I'm referencing, it appears).

That 56K number isn't gzipped, gzipped it's only 18K (plus there's also some inline JS, some webpack boilerplate, and then analytics.js).

The reason for its size is my site is my playground. It's where I get to experiment with all the things I want to experiment with.

I also work on quite a few open source projects, which I usually test on my site before releasing them publicly just to make sure they work in production without errors.

^ exactly; blogs are mostly static. You can improve the responsiveness of e.g. a comments section with a bit of JS, but that's very low priority and doesn't need to be much.

You make that sound like a lot. It's only equivalent to like 20 pages of raw plain text in size.

I poked around a little and it seemed like the majority of it is related to analytics events (googleanalytics/autotrack)

I suppose the author just wants to know a little about how their blog and writing is performing in the wild

Sort of off topic, but it would be interesting if the browser handled these common cases instead and gave the user a way to opt-in/out. I suppose it sort of does by broadcasting those events to the js listeners in the first place.

This blog works fine without javascript.

Which doesn't answer the question.

It shows that the answer is simply "nothing whatsoever".