reply on: SN release: server-side rendering \ stacker news ~meta

pull down to refresh

2 sats \ 1 reply \ @k00b OP 30 Sep 2021 \ parent \ on: SN release: server-side rendering meta

Thanks for the analysis! How are you measuring performance?

You could change the view as soon as you fire the data fetch request (currently it's waiting for the response), this would like improve the perceived speed a lot.

This is how it worked before, but there were loading skeletons and had someone complain about it. Maybe that was a red herring.

Essentially the page needs to react 100ms within me clicking

That'll be the target. I'll probably have to incrementally statically generate them.

Edit: I'm also occasionally getting a full page reload on navigation which shouldn't happen (it should all be one page routed with react). So something is amiss.

2 sats \ 0 replies \ @nout 30 Sep 2021

I just use DevTools performance tab and record interactions there. But the performance is already pretty good, so no need to go crazy here :)

To get under 100ms the UI can't make request and wait for response. It's not possible to realistically do that under 100ms, so yeah, you will need some trick with either prefetching, caching older state or something like that. For simple page like this it's not clear to me that server-side rendering will have a notable benefit (I'd expect it will take React 20ms to render DOM and then browser will take another 50-100ms to do Layout either way).