What this doesn't account for is html rendering time on the server.
The reason websites use local javascript to render html is so they don't have to do it on their server while you have to wait for the result. This way you have the perception of a page load while the html renders. It's actually a better experience for the user.
This entire analysis assumes that the server renders the html instantly. Unless it is static content that is highly cacheable, chances are the render time on your machine isn't much slower than the server, but the website can use a lot less compute resource to make the webpage for you since your computer is doing part of the work.
Also, chances are they have to transmit less data to you, which cuts down on network latency as well.
Citation needed. Whether the server is serving HTML or JSON it still needs to serialise the data, so I don't think serialising JSON is going to be significantly faster than serialising HTML. Plus then the client needs to deserialise that JSON before it can render HTML, so all of that work related to (de)serialising JSON is work which doesn't even need to happen if the server is rendering HTML. Not to mention the work on the client to parse and evaluate the JS which needs to happen before it can even start rendering HTML.
As for data across the wire, GZIP is a thing so again I would want to see real world performance numbers to back your claims.
While it does leave out server rendering time, that could not possibly account for several seconds of difference. TTFB could maybe be increased by 300-500ms… 1/10th of what gains are happening here
I'm not OP, but I don't think the argument is even about rendering. The whole point of SPA, if I understand correctly, is to send the javascript/data and then dynamically create the web page client side (with minimal updates when data changes). Javascript is fast, but a server can dynamically generate HTML in any language. Most server side languages and/or frameworks will be written in faster languages than Javascript. Additionally, you don't need to wait for the browser to deserialize the JS before it can start generating the HTML.
So the benefits of server side generation is no need to deserialize the code that generates the page and locality to the data. I'm guessing these two things are the biggest contributors to the speed ups.
I guess "server side rendering" is a bit of a misnomer, since you're not getting a rendered image, but rather a functional web page. It's possible I've misunderstood the whole SPA vs server side rendering arguments as well and my entire argument is invalid ¯\_(ツ)_/¯
In the Stack Overflow survey it looks like the top 8 frameworks are all JS, C#,and Java. Flask, Django, Laravel and RoR start coming in after all these frameworks. So it looks like most server side apps are either JS or something faster like C# or Java.
Also this is if you check professionals. It's pretty similar for all respondents, but Flask and Django rise above spring and ASP.NET, although ASP.NET Core is still above those.
But most of the desktops, notebooks, phones and tablets doesn't have 3GHz, 50Mb L2 processors coupled with Gb/Tbs of RAM and local (compared to the client requesting the page) storage.
The reason websites use local javascript to render html is so they don't have to do it on their server while you have to wait for the result. This way you have the perception of a page load while the html renders. It's actually a better experience for the user.
This entire analysis assumes that the server renders the html instantly. Unless it is static content that is highly cacheable, chances are the render time on your machine isn't much slower than the server, but the website can use a lot less compute resource to make the webpage for you since your computer is doing part of the work.
Also, chances are they have to transmit less data to you, which cuts down on network latency as well.