I understand the reasoning but I don't agree with their implementation, because it essentially favours large sites run by those who can afford the faster infrastructure, while penalising the small ones that may actually have more relevant and detailed content but not very fast servers. Sites which load much faster get a ranking advantage even if they offer only superficial lower-quality content.
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.
Yup. For my company website I made sure that most pages require just a single request to render: CSS is inlined and (small) scripts are loaded at the bottom of the page. This means that even when hosting it on a crappy host, without a CDN, you get stellar page load performance.
That isn't going to catch sites that load reasonably but behave slowly afterwards (eating CPU time so potentially slowing other apps down too).
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.
