Hacker News new | ask | show | jobs
by epolanski 1370 days ago
I don't think it necessarily is. You do get better LCP and FCP but other metrics suffer (time to interactive, TTFB and several other metrics are primary examples).

It's a compromise, and hydration is a huge performance hit. (I work on performance of a SSR ecommerce)
2 comments
Cyberdog 1370 days ago
"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.

link
lmm 1370 days ago
> "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).

link
Cyberdog 1370 days ago
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.
link
lmm 1370 days ago
> 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.

link
epolanski 1369 days ago
> "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.

link
Cyberdog 1369 days ago
> 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.

Do you disagree with this?

link
acdha 1369 days ago
> other metrics suffer (time to interactive, TTFB and several other metrics are primary examples).

This is only true for a fraction of sites - the ones I work on are content heavy and use progressive enhancement so TTFB is how long it takes a CDN cache hit to transfer, and since you’re using so much less JavaScript in the critical path they’re less affected by network latency and device performance. Obviously that hits a different trade off than an app which has to have dynamic functionality to meaningfully load and lots of user-specific features are going to lower cache effectiveness.

As always, you get what you measure: pick metrics which matter for your business and get as much as possible get your data from real users so you don’t waste time chasing something people don’t care about. It’s too easy to focus on, say, making your search page as fast as you can when you should be asking whether you have what they’re looking for and surfacing it for them.

link