Maybe if they didn't look at server response time, and only counted things like JS execution time, it would be a fairer ranking to those looking for substantive content. I'm quite willing to wait a lot longer, if it means I will spend more time reading a lengthy page once it loads, than to find a fast-loading page with little content.

That article was written 5 years ago, and while speed might not have been a huge factor back then, they could've changed it since --- certainly there is no evidence to suggest otherwise, and my experience with how Google's results have changed over time agree.

I'd hedge that 95-99% of alexa top 1000 sites could be delivered under 30kb -- just content+ css. (assuming ajax/video/fonts are asyncronous in google's algo and not counted towards load time).

In which case it's easy even for the cheapest AWS server to host and server instantaneously. I think the bigger sites have a distinct disadvantage -- they have so many tracking and ad resources, that it kills their load time.

Software architecture has a lot more to do with app speed these days than expensive infrastructure does.

Cost is only part of the equation. What about those who don't want to use a CDN for, among other things, privacy reasons?

"Do as I say, not as I do".

There are a couple of sites I visit that do this. If I leave a few tabs of imgur open in Chrome they'll consume a pile of CPU time (this doesn't always happen, so perhaps it depends which ads are on the page?). IFLS pages eat CPU and memory too (again, almost certainly due to the ad content). In both cases it can be noticeable on a powerful desktop machine, so it must be a significant drain on low powered laptops and such.