# Como avaliar o desempenho de React SSR

Um benchmark SSR útil responde a uma pergunta específica: quanto trabalho correto o aplicativo pode concluir dentro de um orçamento de recursos, com que latência e custo? Um número de solicitações por segundo por si só deixa muita coisa sem explicação.

Este método se aplica a versões, perfis ou tempos de execução React. Ele separa as medições HTTP das jornadas do navegador e inclui um exemplo k6 para se adaptar a uma rota de fixação. O exemplo em si não estabelece nenhum resultado de desempenho.

## Defina uma resposta correta

Escolha uma rota representativa: uma lista dinâmica, um API ou uma página de streaming. Corrija o volume de dados, dependências e condições de autenticação. Uma rota de fixture pode retornar um marcador de solicitação exclusivo para detectar respostas obsoletas ou compartilhadas incorretamente.

Valide o status, o tipo de conteúdo e um valor de corpo esperado. Para SSR dinâmico, verifique se a renderização realmente ocorre. Um arquivo estático armazenado em cache e uma página recém-renderizada são cargas de trabalho diferentes.

## Torne os ambientes comparáveis

Identifique o commit, os artefatos, o Node, o React, o sistema operacional e as opções do compilador. Em uma determinada máquina, mantenha as mesmas dependências de aplicativo e executável do Node. Use compilações de produção e registre configurações de cache e compactação.

Defina orçamentos para todo o grupo, incluindo trabalhadores e qualquer procurador. Explique a topologia: dois processos por trás de um proxy precisam de contexto quando comparados com um servidor direto. Prefira uma máquina geradora de carga separada e monitore se ela satura.

## Crie uma rota de fixação dinâmica

Em um aplicativo de teste do App Router, crie app/bench/page.jsx com este conteúdo. O marcador varia de acordo com a solicitação e a renderização dinâmica é explícita. Este exemplo funciona muito pouco; substitua-o por uma representação representativa ao avaliar um cenário de negócios.

Mantenha a mesma fonte para os tempos de execução que estão sendo comparados. Um marcador por si só não prova o isolamento de todos os dados: adicione sessões separadas e asserções específicas do aplicativo quando os usuários fizerem parte do cenário.

```jsx
export const dynamic = "force-dynamic";

export default async function Benchmark({ searchParams }) {
  const { id = "missing" } = await searchParams;
  return <main>Benchmark marker: {id}</main>;
}
```

## Adicione validação ao gerador de carga

Salve este exemplo como bench.js. Ele espera uma rota de fixture /bench que ecoa o parâmetro de consulta id em seu HTML. Crie essa rota em seu aplicativo de teste; nem Next.js nem PRNext o fornecem automaticamente. BASE_URL tem como alvo uma instância de teste que você controla.

O limite de verificações invalida a execução quando uma resposta falha na validação. Os redirecionamentos são desativados para evitar a medição silenciosa de uma página diferente. Este é um exemplo de simultaneidade fechada: quando o servidor fica lento, cada usuário virtual espera mais tempo. Não simula uma taxa de chegada fixa.

```js
import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 16,
  duration: "60s",
  thresholds: { checks: ["rate==1"], http_req_failed: ["rate==0"] }
};

export default function () {
  const id = `request-${__VU}-${__ITER}`;
  const base = __ENV.BASE_URL || "http://127.0.0.1:3000";
  const response = http.get(`${base}/bench?id=${id}`, { redirects: 0 });
  check(response, {
    "status 200": r => r.status === 200,
    "HTML response": r => String(r.headers["Content-Type"]).includes("text/html"),
    "fresh marker": r => typeof r.body === "string" && r.body.includes(id)
  });
}
```

## Aquecimento separado das janelas medidas

Com o k6 instalado, execute um aquecimento separado e depois várias janelas medidas. Ordem alternativa dos candidatos e mantenha a saída de cada execução. O comando usa a sintaxe do ambiente shell POSIX; adaptar a atribuição BASE_URL no PowerShell.

O gerador possui rede própria e custo CPU. Mantenha os parâmetros idênticos para ambos os candidatos e registre a atividade do servidor concorrente. Janelas repetidas ajudam a descrever a variabilidade, mas não removem o viés da topologia nem tornam representativo um acessório não representativo.

```sh
BASE_URL=http://127.0.0.1:3000 k6 run --duration 10s bench.js
BASE_URL=http://127.0.0.1:3000 k6 run --summary-export result-a.json bench.js
```

## Leia a taxa de transferência, latência, CPU e memória juntos

O p95 é uma duração abaixo da qual 95% das solicitações de amostra são concluídas. Em k6, http_req_duration exclui fases como pesquisa DNS e estabelecimento inicial de conexão. Nomeie a métrica em vez de chamá-la de velocidade.

Calcule o trabalho do grupo CPU por resposta correta separadamente na janela medida: o delta CPU do grupo dividido pelas respostas validadas. HTTP p95 não é consumo de CPU. Grave a memória do grupo e o PSS da árvore de processos com o método indicado. Invalide uma janela com conteúdo incorreto antes de comparar o desempenho.

## Adicione uma jornada de navegador

Um cliente pode receber HTML rapidamente e ainda esperar pela hidratação. Meça a navegação, a navegação de retorno e uma interação comercial separadamente. Verifique se os contadores, as sessões ou o estado do formulário permanecem corretos durante toda a jornada.

Em nossa comparação de VPS, os ganhos do servidor não se traduzem em vitórias em todas as medições do navegador. A publicação dessas diferenças torna a avaliação mais útil. Mantenha o protocolo, a saída bruta e as limitações junto com os gráficos.

[Leia nossa campanha SSR e navegação em duas máquinas VPS](/pt/blog/prnext-vs-nextjs-vps-benchmarks)

## Sources

[k6: built-in metrics](https://grafana.com/docs/k6/latest/using-k6/metrics/reference/)

[k6: checks](https://grafana.com/docs/k6/latest/using-k6/checks/)

[k6: thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/)

[Linux: cgroup v2](https://docs.kernel.org/admin-guide/cgroup-v2.html)

[Node.js: process.memoryUsage()](https://nodejs.org/api/process.html#processmemoryusage)

Publicado: 2026-10-30

Modificado: 2026-10-30

Autor: PRNext

---

Linguagem: pt-BR

Canonical: https://prnext.dev/pt/blog/benchmark-react-ssr

Index: https://prnext.dev/llms.txt