O que significa que algo "se compile no cliente"

Publicado em 2026-09-12 por frfrand

La diferencia entre armar el HTML en el servidor y armarlo en el navegador, qué cambia para el usuario, para el buscador y para tu factura de servidor, y por qué hoy casi todo es una mezcla.

Quando alguém diz que um aplicativo "é compilado no cliente" ou "renderiza do lado do cliente", está descrevendo quem monta o HTML final.

É uma decisão de arquitetura com consequências muito concretas, e vale a pena entendê-la antes de escolher a ferramenta.

As duas formas

No servidor. Chega a requisição, o servidor consulta o banco de dados, monta o HTML completo com os dados dentro e envia. O navegador recebe um documento pronto e o desenha. Assim funcionou a web inteira durante vinte anos, e assim funcionam hoje WordPress, Django ou Rails sem nada em cima.

No navegador. O servidor envia um HTML quase vazio e um arquivo de JavaScript. O navegador executa esse JavaScript, que solicita os dados a uma API e constrói a página no momento. É o que fazem React, Vue ou Angular em sua forma mais simples.

A palavra "compilar" é um pouco enganosa: não se compila no sentido clássico. O que acontece é que o código é transformado antes (de JSX ou TypeScript para JavaScript que o navegador entende) e esse resultado é executado no cliente para produzir o HTML.

O que muda para o usuário

Com renderização no servidor: a primeira tela aparece rápido, porque o que chega já é a página. Mas cada navegação posterior solicita outra página completa.

Com renderização no navegador: o primeiro carregamento é mais lento, porque é preciso baixar e executar o JavaScript antes de ver qualquer coisa. Em troca, uma vez carregado, navegar pelo aplicativo é quase instantâneo: são solicitados apenas os dados, não a página inteira.

A troca, resumida: você paga no início para que depois seja rápido, ou não paga no início e cada passo custa um pouco.

Os dois custos que são subestimados

Os buscadores e os pré-visualizadores. Um rastreador que não executa JavaScript vê o HTML vazio. O Google hoje executa JavaScript, mas nem todos o fazem, e demora mais para indexar. E quando alguém compartilha seu link em um chat, quem gera a pré-visualização quase nunca executa scripts: se o título e a descrição são colocados pelo JavaScript, a pré-visualização fica vazia.

Os telefones que não são o seu. Executar JavaScript custa processador. Em um telefone de médio porte de quatro anos atrás, um pacote grande pode significar vários segundos de tela em branco. É um problema que quase nunca é visto a partir de um laptop de desenvolvimento com boa conexão.

Por que hoje quase tudo é uma mistura

A indústria percebeu que a troca não precisava ser aceita inteira. Os frameworks modernos fazem as duas coisas:

O servidor gera o HTML da primeira tela, para que apareça imediatamente e seja legível por qualquer pessoa. Esse HTML chega com o JavaScript ao lado, que ao ser executado "assume o controle" da página já desenhada e cuida das interações seguintes.

Isso se chama hidratação, e é o modelo do Next.js, Nuxt, SvelteKit e dos demais.

E uma terceira via que se usa pouco

Se o conteúdo não muda por usuário, há uma opção melhor que as duas: gerá-lo uma única vez ao publicar e servir arquivos estáticos.

Um blog, uma documentação ou um site institucional não precisam que ninguém monte nada a cada visita. Um arquivo HTML em disco, servido pelo nginx, é o mais rápido e o mais barato que existe, e não cai.

No ArduMaker isso é literalmente um tipo de implantação: o site é compilado no servidor ao fazer push e fica servido como estático, com seu domínio e seu certificado. Para sites de conteúdo é difícil de superar.