"Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site is to display content (Reddit, Twitter, pretty much everything else). If I (resentfully) click on a Reddit link on a SERP, I'm going there to read the content, not to flip open menus or whatever.
"Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.
> "Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.
Not necessarily. If you "load" the page but it doesn't do what it should when I click on it, that can be much more frustrating to the human than taking a little longer to load but being fully functional when you do. The assumption that anything that isn't HTML is "bells and whistles" is pretty dubious (as is the converse assumption that everything in the HTML is valuable).
If the purpose of your site is to show content to a human, then anything on the page that isn't the content the human wants to see is bells and whistles. I will die on this hill.
> If the purpose of your site is to show content to a human, then anything on the page that isn't the content the human wants to see is bells and whistles.
Sure, but a) the purpose is rarely just to show content, one of the great strengths of the web is interactivity. b) often a lot of what's in the HTML (and especially the CSS) isn't the content the human wants to see.
> "Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site
They matter for SEO.
> "Time to human satisfaction" should be a number that front-end developers measure and aim to improve.
Satisfaction varies. TTI is a relevant metric. E.g. On our ecommerce it takes less than 10 seconds to load the entire page (sub 5 for most pages), but then the user can literally do nothing till all hydration has happened and executed which is simply not a great experience.
Our users, if using the website through slower connections/devices are looking at 40 seconds + delays before they can do anything meaningful, that's unacceptable.
> E.g. On our ecommerce it takes less than 10 seconds to load the entire page (sub 5 for most pages), but then the user can literally do nothing till all hydration has happened and executed which is simply not a great experience.
I can't tell if you're gloating about this or agreeing that these numbers are unacceptable.
Let's say it's a product page. You should be able to have the product title, description, and images (in the sense of <img> tags) load with the page instantly. If you need to do dynamic stuff like have a T-shirt size and color picker which changes what options are available based on stock or something like that, that functionality can be added to the page after the initial load, but nothing that doesn't have to be dynamic should be dynamic.
"Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.