3 ms·
> This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Well, it's different in dif
by lhorie 6y ago
> This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though.
Well, it's different in different ways, depending on which goalpost you're standing on. If by that you mean do SSR, then run React on top, then you've just incurred the same TTFP as plain HTML, plus the cost of React hydration, plus potentially a second repaint (or even third and fourth repaints, depending on how your data trickles in). In the wild, this pattern gets particularly egregious when people decide that it's ok to have loading icons and widgets pushing each other down as data comes in.
If you mean to compare to client-side rendering without SSR, then you're still looking at the cost of at least two repaints (the initial TTFP repaint, plus any repaints from data fetching after that).
- deleted 6y ago[deleted]
- nawgz 6y ago>Well, it's different in different ways You misunderstand - I mean that literally. Arriving to the same initial application state from any means, surely the HTML painter isn't going to be slower or faster. Other parts of the stack will of course be, but I really didn't understand how the painter would induce latency. I personally see extremely limited value in SSR, I prefer to let the client machine deal with assembling related data objects into a nice UI, so you won't catch me out here arguing for it. I load an HTML page that displays an animated spinner inside #root, and then once my bundle loads it lays the application out.