> but still struggle with rendering html interfaces on the client. This assertion completely ignores the performance problems that are involved in "rendering h

> but still struggle with rendering html interfaces on the client. This assertion completely ignores the performance problems that are involved in "rendering html interfaces on the client". The main difference between rendering "Call of Duty at 60fps" and rendering a SPA in React is where you decided to start counting. While your Call of Duty example presumes the app already in the post-init in-game state, your "rendering html interfaces on the client" only covers the app load and init state. This means you are comparing a state where all data to output the first render is already fetched and available with a state where even the code that builds the app is not fetched yet and therefore at least a sizable HTTP request needs to be completed, followed by other sizable and non-pipelinable HTTP requests which are needed to fetch the data used to build up content and state. Call of Duty does not need to perform and wait for at least two sequential HTTP requests to finish to be able to render a scene. Each HTTP request adds something between 50 to 100ms to the page load time. The topic of this discussion is a technique used to avoid having to wait for subsequent requests after the initial HTML+Javascript requests by simply prefetching and prerendering the content on the server. Consequently this approach avoids the need to make critical HTTP requests in the client-side by simply supplying the HTML and javascript with the client's intended state and content, thus potentially shaving over 50-100ms from a page load time.