Desvendando SSR, CSR, SSG e RSC: Entenda de vez essas siglas do React e Next.js

Quando decidi ir além do react e me aprofundar nos estudos com Next.JS frequentemente me via cercada por essa sopa de letrinhas, SSR, CSR, RSC, quantas siglas ein? Em muitos momentos esses conceitos se relacionam e por terem nomes semelhantes podem ser facilmente confundidos principalmente quando estamos iniciando nos estudos. Esse post tem o objetivo de esclarecer o conceito, diferença e aplicação dos seguintes termos: SSR SSG CSR React Component React Element Diferença iniciais Antes de se aprofundar nos conceitos um por um, é importante esclarecer o que para mim é a chave para diferenciar eles: O SSR (Server Side Rendering), CSR (Client Side Rendering) e SSG (Static Site Generation) se referem a estratégia de renderização em nível de página, já o RSC (React Server Components) se refere a renderização dos componentes que posteriormente formarão a página, ou seja, enquanto o output do SSR e CSR é o HTML, o output de um RSC é uma notação customizada, semelhante a um JSON que descreve como deve ser feita a renderização do componente, se essa última parte ficou um pouco confusa, não se preocupe, iremos nos aprofundar com um exemplo logo adiante mas é importante lembrar das diferença chave: SSR, CSR, SSG: Nível de página RSC: Nível de componente. CSR Conceito O CSR é a estratégia de renderizar o UI no navegador. Logo após fazer a requisição, a resposta que o servidor entregará será ao invés da página pronta, um html vazio e o pacote de javascript que contém todas as instruções para gerar a página completa, ao chegar no navegador esse código é rodado e a página é computada já com interatividade. A vantagem é que quando a página é renderizada pela primeira vez ela já será interativa, a desvantagem é que quando o usuário recebe a resposta da sua requisição, ele ainda precisa esperar o código ser rodado no navegador para gerar de fato a página e enquanto isso ele vai ficar visualizando aquela famosa página em branco. Exemplo na prática Esse é o conceito que temos contato direto ao trabalhar com React, veja um exemplo simples de um App.tsx que renderiza um componente react // app.tsx import Homepage from './pages/Home/Homepage' function App() { return ( ) } export default App // Homepage.tsx const Homepage = () => { console.log("Esse log aparecerá no console do navegador!") return (Esse é o h1 do componente Homepage!) } export default Homepage O output será algo como: Primeiro, note que o console.log aparece no console do navegador, além disso ali temos o nosso h1que foi renderizado dentro da div com o id root. Agora desative o javascript da página no navegador e recarregue a página. Vamos ver o que aparece agora: Uma página em branco que contém apenas a div root, além disso o console.log também não está aparecendo, o que aconteceu? Aqui o servidor fez a parte dele, ele enviou o código react que o navegador precisa rodar para renderizar o UI, mas como desativamos o javascript do navegador ele não conseguiu completar sua missão de renderizar a página. SSR (Server Side Rendering), SSG (Static Site Generation) e RSC (React Server Components) Conceitos Vamos começar com SSR E SSG pois ambos são bastante semelhantes e passam pelo mesmo processo de "hidratação" da página. O SSR é a estratégia de renderizar a página completamente no servidor, assim a renderização acontece no server quando a requisição é feita. Dessa maneira a vantagem é que a resposta da requisição do usuário será a página prontinha, logo o usuário recebe a página rapidamente. A desvantagem é que esse HTML entregue é completamente estático, a interatividade só é possível depois que acontece o processo de hydration que é uma segunda renderização, vamos entender o que é esse conceito e como ele funciona. Além do HTML pronto o servidor também envia o pacote javascript, este será rodado no navegador (lembrando que o conteúdo estático da página já está montado) para montar uma DOM virtual e logo em seguida comparar a DOM virtual com a DOM real para que a real seja atualizada com a interatividade. Esse processo de atualizar a DOM real adicionando interatividade é o que chamados de hydration ou simplesmente hidratação. Agora o SSG (Static Site Generation) é bastante semelhante ao SSR pois a renderização também é feita no lado do servidor, a diferença é que enquanto no SSR ela é feita em tempo de requisição, no SSG a renderização é feita no momento do build da aplicação. Assim no SSG também acontece o método de hydration uma vez que o client recebe o html para que a página tenha interatividade. Diferença entre React Component e React Element Então antes de prosseguir para os exemplos e ver na prática como o Next lida com os SSR, SSG e afins, precisamos entender realmente o que é um React component e como ele se torna de fato um conteúdo HTML. É necessário compreender que um React Component é uma função ou classe que retorna um React E

May 3, 2025 - 19:55
 0
Desvendando SSR, CSR, SSG e RSC: Entenda de vez essas siglas do React e Next.js

Quando decidi ir além do react e me aprofundar nos estudos com Next.JS frequentemente me via cercada por essa sopa de letrinhas, SSR, CSR, RSC, quantas siglas ein?
Em muitos momentos esses conceitos se relacionam e por terem nomes semelhantes podem ser facilmente confundidos principalmente quando estamos iniciando nos estudos.
Esse post tem o objetivo de esclarecer o conceito, diferença e aplicação dos seguintes termos:

  • SSR
  • SSG
  • CSR
  • React Component
  • React Element

Diferença iniciais

Antes de se aprofundar nos conceitos um por um, é importante esclarecer o que para mim é a chave para diferenciar eles:
O SSR (Server Side Rendering), CSR (Client Side Rendering) e SSG (Static Site Generation) se referem a estratégia de renderização em nível de página, já o RSC (React Server Components) se refere a renderização dos componentes que posteriormente formarão a página, ou seja, enquanto o output do SSR e CSR é o HTML, o output de um RSC é uma notação customizada, semelhante a um JSON que descreve como deve ser feita a renderização do componente, se essa última parte ficou um pouco confusa, não se preocupe, iremos nos aprofundar com um exemplo logo adiante mas é importante lembrar das diferença chave:

  • SSR, CSR, SSG: Nível de página
  • RSC: Nível de componente.

CSR

Conceito

O CSR é a estratégia de renderizar o UI no navegador. Logo após fazer a requisição, a resposta que o servidor entregará será ao invés da página pronta, um html vazio e o pacote de javascript que contém todas as instruções para gerar a página completa, ao chegar no navegador esse código é rodado e a página é computada já com interatividade.
A vantagem é que quando a página é renderizada pela primeira vez ela já será interativa, a desvantagem é que quando o usuário recebe a resposta da sua requisição, ele ainda precisa esperar o código ser rodado no navegador para gerar de fato a página e enquanto isso ele vai ficar visualizando aquela famosa página em branco.

Exemplo na prática

Esse é o conceito que temos contato direto ao trabalhar com React, veja um exemplo simples de um App.tsx que renderiza um componente react

// app.tsx
import Homepage from './pages/Home/Homepage'
function App() {
  return (
    
  )
}
export default App
// Homepage.tsx
const Homepage = () => {
    console.log("Esse log aparecerá no console do navegador!")
    return (

Esse é o h1 do componente Homepage!

) } export default Homepage

O output será algo como:

output do código react

Primeiro, note que o console.log aparece no console do navegador, além disso ali temos o nosso h1que foi renderizado dentro da div com o id root. Agora desative o javascript da página no navegador e recarregue a página. Vamos ver o que aparece agora:

output do código como javascript do navegador desativado

Uma página em branco que contém apenas a div root, além disso o console.log também não está aparecendo, o que aconteceu?
Aqui o servidor fez a parte dele, ele enviou o código react que o navegador precisa rodar para renderizar o UI, mas como desativamos o javascript do navegador ele não conseguiu completar sua missão de renderizar a página.

SSR (Server Side Rendering), SSG (Static Site Generation) e RSC (React Server Components)

Conceitos

Vamos começar com SSR E SSG pois ambos são bastante semelhantes e passam pelo mesmo processo de "hidratação" da página.
O SSR é a estratégia de renderizar a página completamente no servidor, assim a renderização acontece no server quando a requisição é feita.
Dessa maneira a vantagem é que a resposta da requisição do usuário será a página prontinha, logo o usuário recebe a página rapidamente.
A desvantagem é que esse HTML entregue é completamente estático, a interatividade só é possível depois que acontece o processo de hydration que é uma segunda renderização, vamos entender o que é esse conceito e como ele funciona.
Além do HTML pronto o servidor também envia o pacote javascript, este será rodado no navegador (lembrando que o conteúdo estático da página já está montado) para montar uma DOM virtual e logo em seguida comparar a DOM virtual com a DOM real para que a real seja atualizada com a interatividade.
Esse processo de atualizar a DOM real adicionando interatividade é o que chamados de hydration ou simplesmente hidratação.

Agora o SSG (Static Site Generation) é bastante semelhante ao SSR pois a renderização também é feita no lado do servidor, a diferença é que enquanto no SSR ela é feita em tempo de requisição, no SSG a renderização é feita no momento do build da aplicação.
Assim no SSG também acontece o método de hydration uma vez que o client recebe o html para que a página tenha interatividade.

Diferença entre React Component e React Element

Então antes de prosseguir para os exemplos e ver na prática como o Next lida com os SSR, SSG e afins, precisamos entender realmente o que é um React component e como ele se torna de fato um conteúdo HTML.
É necessário compreender que um React Component é uma função ou classe que retorna um React Element, pode parecer meio abstrato mas podemos facilmente enxergar isso tanto em uma aplicação React como uma aplicação Next, para isso basta importar um componente react e fazer o console.log dele, vamos entender melhor com um exemplo.
Primeiro vamos criar um React Component que retorna uma div e recebe uma props que vai ser usada para ser o id dessa div:

export default function Container({idContainer} : {idContainer :string}){
    return (
        

Aqui temos um parágrafo simples

) }

Agora vamos importar esse componente em uma página mas além de simplesmente renderizar ele, vamos chamar esse container como uma função em um console.log para ver o output dele:

import Container from "./Container";
export default function Page(){
    console.log(Container({idContainer: 'componenteExemplo'}))
    return (<>
        
    )
}

Agora vamos observar o console.log que colocamos no terminal:

output do console.log

O que estamos vendo aqui é o React Element que o React Component Container retorna, logo assim fica fácil de compreender que o React Element é um plain object que descreve um componente UI como um DOM node, contendo os seus atributos, os atributos do seus componentes filhos e também do seu componente pai, por exemplo nesse caso o nosso componente é do tipo 'div', ele tem um children que é um 'p' com seus próprios atributos e aqui podemos também ver os atributos do elemento pai que é um Page do servidor. Muito massa né?

Já estamos familiarizandos com os React Client Components que vimos logo no começo ao tratar do conceito de CRS, mas no exemplo de agora o que acabamos de ver foi um React Server Component sendo renderizado no Next.js.
O RSC (React Server Component) entra na história como uma maneira de renderizar o componente react no servidor ao invés do navegador, vamos continuar com o nosso exemplo agora focando no Next.JS, vamos criar um componente Counter e colocar ele dentro do nosso componente Container.

Componente Counter:

'use client'
import { useState } from 'react'

export default function Counter(){
    const [counter, setCounter] = useState(0)
    return(<>
        

Valor: {counter} ) }

Note que adicionamos um 'use client' pois por padrão todos os componentes dentro da pasta App no Next.js são Server Components, então para criar um Client Component temos que adicionar esse 'use client' para declarar isso.
Agora atualizando o nosso Container.tsx:

import Counter from "./Counter";
export default function Container({idContainer} : {idContainer :string}){
    return (
        

Aqui temos um parágrafo simples

) }

No navegador temos:
output do código

Ao clicar no botão, o valor da variável counter muda e ao mudar seu valor, o conteúdo html muda também. Agora desative o javascript e recarregue a página, de primeira parece que não muda nada, mas ao clicar no botão o comportamento esperado que é a mudança do valor da variável e a renderização que atualiza o UI, não acontece, o que isso significa?
Esse é um exemplo de SSG, que é o comportamento padrão do Next.JS para renderização no servidor, ele renderizou a página no momento do build, e quando atualizamos a página a requisição é feita ao server que já está guardando a página pronta e apenas à envia, como desativamos o javascript no navegador o processo de hydration não aconteceu portanto não temos interatividade. Existem várias formas de mudar esse comportamento para SSR ao invés de SSG no Nextjs mas esse não é o foco desse post.

Então, na prática, qual a diferença entre um React Server Component e um React Client Component no Next.js e no React?
O React é voltado para componentes que rodam no client, ou seja, ele transforma os React Elements em DOM por meio da renderização no navegador. Já o Next.js, nos permite que os componentes sejam executados tanto no cliente quanto no servidor.

Componentes do client, que são aqueles marcados como "client" em um app Next.js são renderizados duas vezes: primeiro no servidor (para gerar HTML inicial) e depois no cliente, onde ocorre a hidratação.
Enquanto os React Server Components (RSCs) são executados exclusivamente no servidor e enviados ao cliente como HTML ou como payload serializado. Eles não têm interatividade direta nem acesso a APIs do navegador (como useState, useEffect), e por isso não passam por hidratação.

--
Espero que esse conteúdo tenha ajudado a esclarecer as principais diferenças entre essas siglas tão comuns no universo do React e do Next.js. Se você curtiu, compartilhe com quem também está nessa jornada de aprendizado. Até a próxima!