[tjoff]

>Every additional millisecond of load time will reduce engagement

This is something people believed in the 90s. None of the megacorps give a damn about that as is evident by their behavior. If it doesn't matter for them it doesn't make sense for you to optimize that on their behalf.

It is a non-issue for this usecase.

But please do care about it for the rest of your stack.

[qwery]

In the 90s, there was no "engagement" and "content" just meant the content of the thing you were talking about, but I digress...

> None of the megacorps give a damn about that as is evident by their behavior.

The rumour (and extrapolation) the discussion is based on is that Youtube prefers their bloated player to an unknown alternative because it makes the videos play faster, which drives "engagement". That is, in this case, the "megacorp" literally does care about that.

> it doesn't make sense for you to optimize that on their behalf

This is certainly true, but I don't think that's what the parent comment was suggesting.

[froggit]

> In the 90s, there was no "engagement" and "content" just meant the content of the thing you were talking about, but I digress...

Sometimes i think back at this idea from the 80s when i need some perspective:

"Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other."

https://lawsofux.com/doherty-threshold/

[qwery]

That website/page is a bit weird. It seems to be based on a TV show[basedon]?

What I assume is the actual IBM report[0] might interest you.

[0] https://www.computerhistory.org/collections/catalog/10275139...

[basedon] https://daverupert.com/2015/06/doherty-threshold/

[IX-103]

Heh. I'm doing work for a "MegaCorp" right now trying to shave a few milliseconds off of ad render times. We have metrics that show milliseconds do matter. Especially since a few milliseconds on desktop can translate to hundreds of milliseconds on mobile.

[tjoff]

I'm sure they do care, but they seems to care more about everything else. Or just are victims of decades of bloat. Or too many teams, where one team obliterated the tuning a hundred other teams did.

Because the end result is typically something that takes orders of magnitude more than you'd imagine physically possible on todays hardware.

1.3 MB on every embed? Is that the best the brightest engineers can come up with?

Or maybe the goal is to slow down the entire internet so that their own sites don't seem so slow in comparison?

I know it's easy for me to talk shit, but have you actually used the web lately? It is a miserable experience.

I'm probably misremembering the details because I can't find it but didn't Netflix have an absolutely enormous favicon or something that went unnoticed for a really long time. Feels like there are a few of those in any big codebase. Question is whether the codebase really needs to be big.