Framework JavaScript ou site estático: o que a página faz

Framework não é decisão de velocidade de desenvolvimento. É decisão sobre quanto estado a página precisa carregar no navegador. Uma página que só apresenta conteúdo paga o preço do framework e não usa o que ele entrega. Decida pelo estado que a página precisa, não pela ferramenta que você prefere.

O que a página precisa fazer além de apresentar conteúdo

Apresentar conteúdo é HTML e CSS. O navegador pinta o texto e as imagens, e o trabalho acaba ali. Não há nada que precise continuar ali depois de um clique.

Estado é todo o resto. Um filtro que mantém a seleção, um carrinho que lembra um item, um formulário que valida enquanto você digita, uma lista que atualiza sem recarregar. Estado significa que a página sabe algo, lembra disso e muda o que mostra sem um documento novo.

Uma pergunta simples separa os dois caminhos. No clique, a página precisa decidir algo no aparelho, ou só precisa carregar outro documento?

Quando a resposta é outro documento, o navegador já sabe fazer isso. Ele faz desde antes de qualquer framework existir.

O que o visitante baixa em cada caminho

Num site estático, o visitante baixa o documento, a folha de estilo e as fontes. O JavaScript que entra é a parte que realmente precisa do aparelho, como uma busca ou um botão de tema.

Numa página de framework, o download inclui o runtime do framework e o código dos componentes de toda a rota. A página Rendering on the Web, do Google, descreve o motivo. Para o script do cliente assumir onde o servidor parou, a maioria das soluções com renderização no servidor serializa em tags de script os dados que montaram a interface.

O documento passa a carregar o HTML, os dados de origem e uma cópia completa da interface. A expressão que o próprio Google usa é um app pelo preço de dois.

A página do Google sobre Core Web Vitals define onde esse peso cai. O Largest Contentful Paint mede carregamento e deve ocorrer em até 2,5 segundos. O Interaction to Next Paint mede interatividade e deve ficar em 200 milissegundos ou menos. O Cumulative Layout Shift mede estabilidade visual e deve ficar em 0,1 ou menos. O Google lê os três no percentil 75 dos carregamentos, separando celular e desktop.

A mesma página registra que o Interaction to Next Paint substituiu o First Input Delay como Core Web Vital estável em 2024. O conjunto de métricas se move, então o número que você otimiza hoje tem data de aposentadoria documentada.

Onde os limites de tempo de resposta divergem da métrica

O Nielsen Norman Group (em inglês) fixa três limites de tempo de resposta. Atraso de 0,1 segundo é lido como instantâneo, 1 segundo mantém o fluxo de pensamento e 10 segundos mantêm a atenção na tarefa.

Um segundo artigo do NN/g (em inglês) repete os mesmos três limites e acrescenta o resultado. Atraso de 10 segundos muitas vezes faz a pessoa sair do site na hora.

Um terceiro artigo (em inglês) transforma os limites em regra de interface. Ação acima de cerca de 1 segundo pede indicador de progresso, em laço entre 2 e 10 segundos e em porcentagem acima de 10 segundos.

Esses limites descrevem a espera percebida por interação. O Core Web Vitals descreve dado de campo por carregamento, no percentil 75.

Os dois referenciais divergem na escala. O Interaction to Next Paint em 200 milissegundos é o dobro do limite do NN/g para retorno instantâneo e metade do limite de fluxo de 1 segundo (Core Web Vitals, NN/g (em inglês)).

O Largest Contentful Paint em 2,5 segundos fica acima do limite de fluxo de 1 segundo e abaixo do limite de atenção de 10 segundos. Uma página pode passar na métrica e ainda parecer lenta (Core Web Vitals, NN/g (em inglês)).

Divergem também no que passar significa. O Google lê um número sobre todos os acessos no percentil 75, então um quarto das visitas pode estar pior. O NN/g descreve o atraso único que a pessoa percebe.

A terceira diferença é o retorno. O NN/g tolera a espera quando a interface mostra progresso. Nenhum Core Web Vital mede esse sinal, e o Cumulative Layout Shift não tem equivalente no NN/g, porque mede estabilidade e não tempo.

Vale olhar os dois. A métrica diz como a página se comporta no campo. Os limites dizem o que o visitante tolera enquanto espera.

O que o servidor faz em cada caminho

Um site estático faz o trabalho uma vez, no build. O Google descreve a renderização estática como produzir um arquivo HTML separado para cada URL antes do acesso. Depois o host devolve um arquivo, e um CDN pode servir da borda.

A mesma página lista o resultado. A renderização estática entrega um First Contentful Paint rápido e um Total Blocking Time e Interaction to Next Paint menores, desde que a página limite o JavaScript do cliente. Ela também garante um Time to First Byte consistentemente rápido, porque o HTML existe antes do pedido chegar.

Uma página de framework com renderização no servidor faz esse trabalho a cada navegação. O servidor renderiza a interface em HTML, embute o JavaScript e os dados, e o cliente renderiza de novo. O Google observa que muitas soluções de renderização no servidor atrasam o Time to First Byte ou enviam os dados duas vezes, uma no markup e outra no script.

Esse é o preço da personalização. Uma página que se monta por visitante precisa de um servidor que a monte.

O que acontece na navegação seguinte

Num site estático, o próximo clique é um documento novo. O navegador interpreta o HTML e pinta. O Google observa que o visitante tem menos chance de esperar por JavaScript pesado de CPU antes de usar o site.

O custo é recarregar a página. O estado da página se perde, e uma animação ou um painel aberto somem, a menos que o site guarde isso.

Numa aplicação de página única, o roteador intercepta o clique, busca os dados e renderiza no lugar. O estado sobrevive, e depois do primeiro carregamento a transição pode parecer imediata.

Quem pagou por isso foi o primeiro carregamento. Ele também tem um modo de falha que aparece nas métricas. A página do Google afirma que uma página renderizada no servidor pode parecer carregada e interativa enquanto não responde a entrada, até o script executar e o handler se ligar. A mesma página diz que, no celular, isso pode levar minutos.

Quem clica dentro dessa janela não recebe nada. A página parecia pronta.

Quando o framework se paga

O framework é a escolha certa quando a página carrega estado que pertence ao aparelho. Quatro casos em que isso é claramente verdade.

Painel autenticado, onde a tela monta dados de vários endpoints e a pessoa filtra, ordena e edita sem sair.
Edição em tempo real ou colaboração, onde a mudança de outra pessoa precisa aparecer sem recarregar.
Fluxo com muitas interações encadeadas, onde cada passo depende da resposta anterior e a validação acontece enquanto se digita.
Produto em que um estado alimenta várias telas, como um construtor ou um editor com pré-visualização.

O roteamento no cliente também compensa quando a aplicação tem dezenas de telas e circular entre elas é o produto. Cada navegação passa a custar uma busca de dados em vez de um documento.

Esses casos, porém, são a exceção, e não o padrão. Uma página que só apresenta conteúdo não ganha nada com o framework.

O meio do caminho: site estático com ilhas de interação

A maioria das comparações para em duas opções. A terceira entrega HTML estático e hidrata só as partes que precisam.

A documentação do Astro define ilha como um componente de interface aprimorado dentro de uma página de HTML estática. A mesma página afirma que a maioria dos frameworks baseados em JavaScript hidrata e renderiza o site inteiro como uma aplicação grande.

O Astro inverte o padrão. A documentação diz que o framework hidrata exatamente o que está marcado e deixa o resto como HTML estático. Um componente vira interativo por uma diretiva de cliente, e a diretiva também define o momento.

client:load hidrata o componente assim que a página carrega.
client:idle espera o navegador ficar ocioso.
client:visible espera o componente entrar na área visível, e um componente que o visitante nunca vê nunca carrega.

Para um site de conteúdo, isso cobre os casos reais. Uma busca, um alternador de preço, um botão de tema e um formulário de newsletter entram como um pacote pequeno cada, e o texto em volta continua HTML.

Tem um custo nisso. Você passa a decidir, componente por componente, onde a página estática termina e a parte interativa começa. Errar para um lado entrega JavaScript que ninguém precisa. Errar para o outro deixa um controle morto até o pacote chegar.

A própria documentação do Astro afirma que um site pode carregar 40 por cento mais rápido com 90 por cento menos JavaScript. A comparação é com o mesmo site feito no framework React mais popular. A mesma página vende o padrão como zero JS. Os dois números vêm do fornecedor, na página do fornecedor, e nenhum é medição neutra.

Como decidir pelo estado que a página carrega

Responda isto antes de escolher a ferramenta.

Liste cada pedaço de estado que precisa sobreviver a um clique. Zero item aponta para site estático.
Conte as interações que se encadeiam. Um passo é um componente, e cinco passos dependentes são uma aplicação.
Pergunte quem é dono do dado em cada passo, o servidor ou o aparelho. Dono servidor favorece documento.
Conte as URLs. Poucas páginas com conteúdo profundo favorecem o estático, e dezenas de telas com estado compartilhado favorecem o framework.
Pergunte o que a pessoa faz na segunda visita. Ler de novo é documento, e voltar para uma sessão de trabalho é estado.
Olhe o time. Um framework que você não consegue operar é uma troca pior que HTML que você consegue.

O que decide é o estado, não a ferramenta. O mesmo time pode escolher respostas diferentes para o site institucional e para o produto, e as duas podem estar certas.

Teste antes de fechar a escolha

Meça os bytes de JavaScript por rota, não o tamanho do pacote no repositório.
Leia o Interaction to Next Paint no percentil 75, num perfil de celular com rede limitada.
Carregue a página com o JavaScript desligado. O Google oferece esse teste para separar renderização estática de pré-renderização, porque a página pré-renderizada parece inerte sem script.
Clique na navegação seguinte numa conexão lenta e note se a página responde ou só parece pronta.
Conte as rotas que renderizam no cliente e confira se cada uma tem motivo.
Refaça a conta depois de um trimestre. A versão do framework e o requisito se movem.

A resposta depende do estado que a página carrega, os bytes que o visitante paga por ele e o ponto em que um documento bastava.