Here’s a quick summary of the different ways you can load a website.
SSR (Server Side Rendering): The classic way. Browser makes request to server, server creates an HTML/CSS/JS bundle, sends it to browser.
CSR (Client Side Rendering): The vanilla React way. Browser makes a request to server, server sends back JS code which runs on browser, creating the HTML/CSS and triggering browser to further make requests to load all assets.
SSG (Static Site Generation): The “gotta go fast” way. Server creates an HTML/CSS/JS bundle for web pages at build time. When browser requests a page, the server just sends this pre-built bundle back.
ISG (Incremental Static Generation): The “imma cache stuff” way. Server may create some HTML/CSS/JS bundles for web pages at build time. When the browser requests a page, the server sends this pre-built bundle back. If a pre-built bundle doesn’t exist, it falls back to CSR while it builds the bundle for future requests. The server may auto-rebuild bundles after certain time intervals to support changing content.
ESR (Edge Slice Re-rendering): The “cutting edge, let’s get latency down so low it’s practically in hell” way. Server does SSG and tells the CDN to cache the bundles. Then, it instructs the CDN to update the bundle in the event that page content needs to change.
In order of performance, usually: (SSG = ISG = ESR) > CSR > SSR
In order of SEO: (SSR = SSG = ISG = ESR) > CSR
In order of correctness (will users be shown “stale” information?): (SSR = CSR) > ESR > ISG > SSG
Surely the rendering is client side in all these - there are some servers that did some kind of server side rendering for low-power devices (AvantGo used to do this for palm, I think silk does something similar for Amazon fire) - but usually the serdar just sends instructions (html/css) which the client renders?
It depends what you mean by “rendering”. Of course, the visuals are only shown to users, and that happens on the browser.
But the browser uses HTML/CSS/JS to create the visuals (I’ll call this a “bundle”). There are different strategies for how this bundle is created. The classic way is to just create it on the server on a per-request basis, and send it to the client. These ways I’ve listed are other ways.
In order of performance, usually: (SSG = ISG = ESR) > CSR > SSR
This is vague and misleading. Your 256 core server can probably create an HTML table with 1,000,000 lines faster than my 8 core laptop but DataTables (a client side tool for rendering large tables) can paint faster than a plain html file.
So what did you measure?
If you measure data transferred then SSR usually loses because it has to hydrate the data and then send it, resulting in larger bundles. In a CSR situation your entire app should be cached in a CDN meaning you’ll get the best transfer speeds.
If you measure TTFI or time to first paint you’re still incorrect. See the example I gave above with DataTables. Rendering a plain 1,000,000 row HTML table takes longer than a DataTables table of the equivalent size because the browser is not designed to display 1,000,000 DOM elements.
There are plenty of exceptions to this as well. Like if you included DataTables just to display a 10 row table. Then the time spent downloading and interpreting DataTables would not be offset by the bad table implementation.
But if we can run Doom on a Ti-83 powered by potatoes you can probably generate HTML on your clients device.