Renderização híbrida

O que é renderização híbrida?

É um jeito de dizer que a aplicação mistura estratégias diferentes dependendo da necessidade.

Pensa num restaurante:

• alguns pratos já ficam prontos na vitrine
• alguns são feitos na hora
• alguns ficam prontos, mas são refeitos de tempos em tempos
• alguns o cliente mesmo monta na mesa

No Next.js, é parecido.

Você não precisa escolher um único jeito de renderizar o site inteiro. Pode usar uma estratégia para a home, outra para o blog, outra para um dashboard e outra para um detalhe específico.

Esse é o lado “híbrido”.

A ideia principal

A pergunta mais útil não é:

“qual renderização é a melhor?”

E sim:

“onde faz sentido gerar esse conteúdo?”

As opções mais comuns são:

• no servidor, a cada requisição
• no build, antes de alguém acessar
• no build, mas com atualização automática depois
• no navegador do usuário

SSR (Server-Side Rendering)

SSR é quando o HTML da página é gerado no servidor toda vez que alguém acessa.

Metáfora simples:

é como pedir um café passado na hora.

Demora mais do que pegar algo pronto, mas chega fresco e com mais chance de refletir o estado atual.

Como funciona

1. a pessoa acessa a página
2. o servidor executa o código
3. busca os dados necessários
4. monta o HTML
5. devolve a página pronta

Quando faz sentido

• quando o conteúdo precisa nascer atualizado
• quando a resposta depende muito do contexto da requisição
• quando mostrar dado velho é um problema

Exemplo no App Router

export const dynamic = 'force-dynamic'

export default async function Page() {
  const data = await fetch('https://api.exemplo.com/stats', {
    cache: 'no-store',
  }).then((res) => res.json())

  return <div>{data.total}</div>
}

O ponto de atenção

SSR não é sinônimo de “tem interação”.

Uma página pode ser super interativa e ainda assim ser SSG, ISR ou CSR em partes.

O que faz mais sentido aqui é:

“preciso gerar esse HTML com dados atualizados a cada acesso?”

SSG (Static Site Generation)

SSG é quando a página é gerada antes, normalmente no build.

Metáfora simples:

é como deixar marmitas prontas na geladeira.

Quando alguém precisa, é só entregar.

Como funciona

1. durante o build, o Next gera o HTML
2. esse HTML fica pronto para servir
3. quando alguém acessa, recebe a página rapidamente

Quando faz sentido

• páginas institucionais
• posts de blog
• documentação
• conteúdo que muda pouco

Exemplo no App Router

export default async function Page() {
  const data = await fetch('https://api.exemplo.com/post', {
    cache: 'force-cache',
  }).then((res) => res.json())

  return <article>{data.title}</article>
}

O lado bom

• costuma ser muito rápido
• é ótimo para conteúdo público
• reduz trabalho no servidor

O limite

Se o conteúdo muda toda hora, deixar tudo pronto no build pode virar uma foto antiga.

ISR (Incremental Static Regeneration)

ISR é como um meio-termo entre o estático e o dinâmico.

Metáfora simples:

imagina uma vitrine que já está montada, mas a loja combina de reorganizar tudo a cada 10 minutos.

Quem chega vê algo pronto e rápido. Mas, de tempos em tempos, aquilo é renovado.

Como funciona

1. a página nasce estática
2. o usuário recebe essa versão pronta
3. depois de um tempo configurado, o Next pode regenerar a página
4. a próxima versão atualizada passa a ser servida

Quando faz sentido

• blog que recebe atualização ocasional
• catálogo
• landing page com dados que mudam, mas não em tempo real
• conteúdo público que precisa de frescor sem custo de SSR em toda visita

Exemplo no App Router

export const revalidate = 60

export default async function Page() {
  const data = await fetch('https://api.exemplo.com/posts').then((res) =>
    res.json(),
  )

  return <div>{data.length} posts</div>
}

Aqui, 60 quer dizer que a rota pode ser revalidada a cada 60 segundos.

O jeito simples de pensar

SSG é uma foto.

ISR é uma foto que é tirada de novo de tempos em tempos.

CSR (Client-Side Rendering)

CSR é quando a lógica principal de buscar ou atualizar os dados acontece no navegador.

Metáfora simples:

é como entregar uma mesa com as peças e deixar a pessoa montar ali.

O servidor entrega a base, mas uma parte importante da experiência acontece do lado do cliente.

Como funciona

1. a página carrega
2. o JavaScript roda no navegador
3. os dados podem ser buscados no cliente
4. a interface é atualizada na tela

Quando faz sentido

• filtros interativos
• dashboards muito dependentes do estado do usuário
• dados que mudam o tempo todo no cliente
• interfaces onde a navegação interna é muito viva

Exemplo

'use client'

import { useEffect, useState } from 'react'

export default function Page() {
  const [data, setData] = useState<{ name: string } | null>(null)

  useEffect(() => {
    fetch('/api/data')
      .then((res) => res.json())
      .then(setData)
  }, [])

  return <div>{data ? data.name : 'Carregando...'}</div>
}

O ponto de atenção

CSR não é “errado” nem “menos profissional”.

Só não é o melhor caminho para tudo, principalmente quando o objetivo é entregar conteúdo público rápido e indexável.

Então qual usar?

Um jeito simples de decidir:

• precisa nascer atualizado a cada acesso? SSR
• muda pouco e pode ficar pronto antes? SSG
• pode ficar pronto antes, mas precisa ser renovado de tempos em tempos? ISR
• depende muito de interação no navegador? CSR

E no App Router, se eu não especificar nada?

No App Router, o Next tenta otimizar automaticamente quando consegue.

Ou seja:

• se a rota puder ser tratada como estática, ele tende a aproveitar isso
• se houver sinais de comportamento dinâmico, ele passa a renderizar de forma dinâmica

Esses “sinais” podem ser coisas como:

• cache: 'no-store'
• dynamic = 'force-dynamic'
• uso de APIs como cookies() e headers()

Então o App Router costuma ser mais esperto do que o modelo antigo do Pages Router, mas ainda assim vale entender o que você está pedindo para ele fazer.

E onde entra a renderização híbrida nisso tudo?

Aqui está o ponto central:

renderização híbrida é combinar essas estratégias no mesmo projeto.

Exemplo bem realista:

• home do portfólio: SSG
• post de um blog: ISR
• dashboard logado: SSR
• filtro avançado na tela: CSR

Ou até na mesma página:

• conteúdo principal vindo do servidor
• comentários carregados no cliente
• uma seção cacheada
• outra revalidando a cada certo tempo

É como montar um prato com partes prontas e partes feitas na hora.

Não porque fica “mais chique”, mas porque fica mais adequado ao problema.

Uma observação importante sobre APIs antigas

Se você estudar materiais mais antigos de Next.js, vai ver muito:

• getStaticProps
• getServerSideProps
• getStaticPaths

Essas APIs pertencem ao Pages Router.

No App Router, a ideia moderna costuma ser:

• buscar dados direto no componente assíncrono
• usar generateStaticParams() para rotas dinâmicas estáticas
• controlar cache e revalidação com fetch, revalidate e config de rota

Então o conceito continua parecido, mas a forma de escrever mudou.

Resumindo de forma simples

Se eu tivesse que resumir tudo em uma frase:

renderização híbrida é parar de tratar toda página do mesmo jeito.

Cada parte da aplicação pode ser servida do jeito que faz mais sentido.

Quando você entende isso, deixa de pensar “qual é o modelo certo?” e começa a pensar “qual entrega melhor experiência com menos custo e menos complexidade?”.