This is "bounce before document.ready()?" How does it compare to "bounce before ad networks/API calls finish" and "bounce before end of autoplay video?"
I'm thinking that with all the other API goo in many mainstream/mass-media sites, "initial app load time" is something users are probably pretty tolerant of, unless "load time" includes stuff beyond the page becoming interactive.
Since we're talking about SSR which happens before anything else, latency is going to push out all load-time metrics equally.
> I'm thinking that with all the other API goo in many mainstream/mass-media sites, "initial app load time" is something users are probably pretty tolerant of
It's all relative. Presumably you're competing on some level with those mainstream/mass-media sites, so users will punish/reward you if your site takes more/less time to load than average.
Isn’t that the whole point?
https://css-tricks.com/building-skeleton-screens-css-custom-...
That's a big, important, if.
For example: I work at Bleacher Report and our non-logged-in users get data customized for them. That can be as simple as GeoIP data or can be us knowing (and inferring) what articles or content they’ve seen.
The permutations are quite large.
Now some blog, or a very simple app won’t do something like that (hell, they might not have the depth of content to be able to) but it’s reasonbly common to have that requirement on large sites outside of v.limited pages (like login/signup etc)
Also, if you start getting requests faster than you can do the initial render, each subsequent user has to wait in line longer than the one before. Your server-side framework won't even show you how long people waited for a TCP connection.
Of course then you get into the fun of cache management and invalidation.
See http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io... for explanation.