[onion2k]

If you need custom data in the page on a per request basis then SSR is usually the fastest method to generate the final HTML but it isn't the fastest method of getting something on the user's screen. Its "time to render" that counts, and that means doing as little work as possible to send something to the user.

Serving the same static, "prerendered" HTML file with no customization to every user is always going to be the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.

[dahfizz]

I hear this often, but I am unconvinced. This just leads to jittery pages that keep moving when I try to do something to them.

Just seeing the skeleton of the web page doesn't make it fast. The page will be unresponsive for longer and will visually stutter while rendering. It's a much worse user experience imo.

[onion2k]

Just seeing the skeleton of the web page doesn't make it fast.

I didn't say it does. Skeleton loading is slower. It feels faster though, and that perceptive improvement is more important than the actual time something takes. If you ask users which they think is faster they usually say the skeleton version regardless of the facts. When your key metric is user satisfaction rather than raw download speed that's important.

The page will be unresponsive for longer and will visually stutter while rendering.

That doesn't have to be the case though. There are plenty of techniques for writing client side code that doesn't block user interaction.