Skip to content

Latest commit

 

History

History
84 lines (51 loc) · 5.19 KB

csr-ssr-ssg.md

File metadata and controls

84 lines (51 loc) · 5.19 KB
Raw

Client-side rendering (CSR) and server-side rendering (SSR) are two different approaches to rendering web pages, each with its own advantages and disadvantages.

Client-Side Rendering (CSR)

In CSR, the server sends an initial HTML file with the JavaScript files to the browser. The JavaScript then takes over and renders the entire webpage in the browser. This is the approach used in Single Page Applications (SPAs).

Pros:

  1. Rich Interactions: CSR is great for web applications that require rich interactions and smooth transitions, as the entire application is loaded in the client's browser.
  2. Reduced Server Load: Since the server only serves the initial page and the rest is handled by the client, the server load is reduced.

Cons:

  1. Slow Initial Load: The initial load might be slow because the browser has to download, parse, and execute the entire JavaScript before it can start rendering the page.
  2. SEO Challenges: CSR can have issues with SEO because some web crawlers may not execute JavaScript, and thus, may not see the fully rendered page.

Server-Side Rendering (SSR)

In SSR, the server processes the request, renders the full HTML for the page, and sends it to the client. The client's browser can start rendering the HTML from the server without having to wait for all the JavaScript to be downloaded and executed.

Pros:

  1. Fast Initial Load: SSR can result in a faster "first paint" because the browser can start rendering the HTML from the server without having to wait for all the JavaScript to be downloaded and executed.
  2. SEO Friendly: SSR is great for SEO. The server sends a fully rendered page to the client, and the client's web crawler doesn't need to run JavaScript to index the page.

Cons:

  1. Server Load: SSR can put a heavier load on your server, because the server has to render a new page on every request.
  2. Full Page Reloads: In a traditional SSR approach, navigating between pages can result in a full page reload, which might not be as smooth as CSR.

In modern web development, there are also hybrid approaches like Next.js which allow you to choose between CSR, SSR, and Static Site Generation (SSG) on a per-page basis, giving you the benefits of each where they make the most sense.

Static Site Generation (SSG)

In SSG, all pages are generated at build time. This means that the server sends a static HTML file to the client and no additional rendering is needed by the server at runtime.

Pros:

  1. Performance: SSG can result in very fast load times, because the HTML is pre-generated and can be served directly from a CDN.
  2. SEO: Like SSR, SSG is great for SEO because the server sends a fully rendered page to the client.
  3. Scalability: SSG sites can be easily scaled up by simply serving more static files, without any additional load on a server.

Cons:

  1. Stale Content: Since the content is generated at build time, updates to the content require a rebuild of the site.
  2. Build Times: For very large sites, build times can become long because every page needs to be rendered at build time.

In summary, SSR is great for dynamic content that changes often, while SSG is great for static content that doesn't change as frequently. Modern frameworks like Next.js allow you to mix and match SSR, SSG, and CSR depending on the needs of each page in your application.

What's happening under the hood with CSR, SSR and SSG

Client-Side Rendering (CSR)

In CSR, when a user requests a webpage:

  1. The server sends a minimal HTML document with links to CSS and JavaScript files.
  2. The browser downloads the JavaScript and CSS files.
  3. The JavaScript, typically a framework like React or Vue, takes over and generates the HTML content in the browser.
  4. Any subsequent navigation or data changes are handled by the JavaScript, which updates the HTML on the client side.

This means that the server's job is minimal, and most of the work happens in the client's browser.

Server-Side Rendering (SSR)

In SSR, when a user requests a webpage:

  1. The server receives the request and runs the necessary JavaScript to create the HTML for the page.
  2. The server sends this fully rendered HTML along with the CSS to the browser.
  3. The browser can start rendering the page as soon as it receives the HTML.
  4. The browser downloads the JavaScript and takes over for any subsequent dynamic changes.

This means that the server does most of the heavy lifting, and the client's browser gets a fully rendered page.

Static Site Generation (SSG)

In SSG, when a user requests a webpage:

  1. At build time, the server runs the necessary JavaScript to generate the HTML for every possible page in the application.
  2. These HTML pages are saved and served whenever a user requests a page.
  3. The server sends the pre-generated HTML and CSS to the browser.
  4. The browser can start rendering the page as soon as it receives the HTML.
  5. The browser downloads the JavaScript and takes over for any subsequent dynamic changes.

This means that the server does all the work at build time, and the client's browser gets a pre-rendered page. This approach is great for sites where the content doesn't change often, as the server doesn't have to do any work at runtime.