I wouldn't hold either of those up as good counter examples: 1) Single Page Apps vs. mostly static HTML 2) Not great exemplars of quickly loading pages 3) Your bandwidth might be bad- I was able to load youtube.com in <2s.
And yet they're some of the most popular web sites on the internet, so does that not indicate that they do so despite the performance and therefore users find their performance at least acceptable?
> 3) Your bandwidth might be bad- I was able to load youtube.com in
Good for you? I'm on a 2GBit/s fiber connection with 3ms ping to youtube.com . I am however, likely located further away from their actual servers doing the processing (while ping measures the response from their edge servers).
You're right, they don't. The user experience is that they're front-loading their wait time loading the app, and aren't doing a whole request/response cycle for every action they want to take. The end result is the net wait for their active session being lower.
>so does that not indicate that they do so despite the performance
It indicates they're trying to maximize features, rather than minimize load time.
>I'm on a 2GBit/s fiber connection with 3ms ping to youtube.com
Cool maybe your computer is slow then. Sample size of 1, anecdata, etc.
Users don't care about tech choice.
> 2) Not great exemplars of quickly loading pages
And yet they're some of the most popular web sites on the internet, so does that not indicate that they do so despite the performance and therefore users find their performance at least acceptable?
> 3) Your bandwidth might be bad- I was able to load youtube.com in
Good for you? I'm on a 2GBit/s fiber connection with 3ms ping to youtube.com . I am however, likely located further away from their actual servers doing the processing (while ping measures the response from their edge servers).