Thought this might interest the general programming community as well! If you’ve ever been interested in the different types of ways websites can render themselves…

cross-posted from: https://programming.dev/post/223726

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

  • dtb@sh.itjust.worksEnglish
    4·
    1 year ago

    Something worth considering with client side rendering, is the idea that the user may not be able to tell the difference between “still rendering” and “done”, making me want that final “order of correctness” flow to have a branch for client side rendering that includes a “maybe?” in case there’s a server connection somewhere that’s slow or broken.

    I’m sure I’m getting too pedantic because this post isn’t about best practices for implementing it, and I’m currently bitter about a tool I have to use that does it poorly, having no difference between “fetching information” (aka, still rendering), “no information to fetch” (aka, done rendering), and “connection broken, please refresh” (aka, reboot the server, AGAIN).

    • o_oOPEnglish
      3·
      1 year ago

      Agreed! I think this is generalizable to say that CSR is when you need to show “loading indicators” which is kind of annoying because… I had to send the loading indicator from server -> browser… so it was loading just to load some more.