Por que escolhemos Astro para o novo Korbi Studio

Segundo o Think with Google, a chance de um visitante abandonar uma página mobile sobe 32% quando o tempo de carregamento passa de 1 para 3 segundos. Em site institucional isso significa visita perdida. Em site que gera lead ou venda, significa dinheiro saindo pela porta antes mesmo do visitante ler a primeira frase.

Quando começamos a desenhar o novo site da Korbi Studio, essa estatística pesou mais do que qualquer tendência visual. A maioria dos sites profissionais no Brasil ainda roda em stacks que tratam performance como ajuste de última hora: WordPress com dezenas de plugins, ou aplicações React/Next inteiras carregadas no navegador do usuário antes de qualquer conteúdo aparecer. O resultado é sempre o mesmo — site bonito no Figma, lento na mão do cliente.

Este post explica a decisão técnica por trás do site da própria Korbi: por que escolhemos Astro, o que é a arquitetura de ilhas e como isso se conecta com o stack completo (Astro + Sanity + Vercel) que hoje sustenta nosso site e o de clientes reais. A mesma lógica técnica se aplica em todo projeto que sai daqui.

O problema real: performance ruim é decisão de arquitetura, não acidente

Site lento não acontece por azar. Acontece porque a stack escolhida no dia zero carrega, por padrão, mais coisa do que a página precisa pra existir.

WordPress tradicional é o exemplo mais comum. Cada plugin adiciona CSS, JavaScript e chamadas ao banco de dados que rodam em toda página, mesmo quando aquele plugin específico não é usado ali. Um site institucional com 15 plugins ativos facilmente carrega 2-3MB de recursos só pra mostrar um menu e um formulário de contato. Isso significa dezenas de requisições HTTP antes da primeira palavra aparecer na tela. Cada requisição extra soma latência real, principalmente em conexão móvel fora de wi-fi.

O outro extremo também erra, só que por caminho oposto. Single Page Applications (SPAs) construídas em React ou Vue puro mandam o pacote inteiro da aplicação pro navegador antes de renderizar qualquer pixel. O usuário espera o JavaScript baixar, depois espera ele "hidratar" a página pra só então ver conteúdo. Pra um blog institucional ou site de captação, isso é overhead desnecessário: a maior parte do conteúdo é estático, não precisa de interatividade nenhuma.

Os dois caminhos têm a mesma raiz: tratam toda a página como se ela precisasse do máximo de poder computacional o tempo todo. Na prática, raramente precisa.

O que é Astro e a arquitetura de ilhas

Astro parte de uma premissa simples: a página começa como HTML puro, sem JavaScript nenhum. Cada componente só ganha JavaScript se explicitamente precisar de interatividade — um carrossel, um formulário com validação, um menu mobile animado. Esse modelo chama-se arquitetura de ilhas (islands architecture).

Na prática, funciona assim:

1. O framework renderiza toda a página no servidor (ou em build time) como HTML e CSS estático
2. Componentes que precisam de interatividade são marcados manualmente como "ilhas"
3. Só o JavaScript daquela ilha específica é enviado ao navegador, e só quando necessário
4. O resto da página permanece HTML puro, sem custo de hidratação

O efeito prático: uma página institucional com texto, imagens e um formulário de contato pode carregar com zero KB de JavaScript de framework. Se existir um componente interativo — um slider de projetos, por exemplo — só esse pedaço carrega JS, isolado do resto.

Isso é diferente de "otimizar depois". É a arquitetura já nascer magra. Não existe JavaScript sobrando pra remover porque ele nunca foi enviado.

Por que isso importa pra Core Web Vitals e SEO

Google usa Core Web Vitals como sinal direto de ranqueamento desde 2021 e como fator declarado de experiência de página desde então. As três métricas centrais avaliam exatamente o que a arquitetura de ilhas ataca:

• LCP (Largest Contentful Paint): tempo até o maior elemento visível carregar. Site sem JavaScript bloqueando o parser tende a exibir conteúdo quase instantaneamente
• INP (Interaction to Next Paint): tempo de resposta a cliques e toques. Menos JavaScript rodando na thread principal significa menos competição por processamento quando o usuário interage
• CLS (Cumulative Layout Shift): estabilidade visual durante o carregamento. HTML estático renderizado de uma vez evita aquele "pulo" de layout comum em SPAs que montam a página em etapas

Site institucional que carrega em menos de 1 segundo carrega vantagem competitiva mensurável: aparece melhor posicionado em buscas relacionadas ao negócio e retém o visitante que veio da busca orgânica em vez de perdê-lo pro concorrente com site mais rápido. Detalhamos essa métrica ponto a ponto em Core Web Vitals: o que são e por que importam.

Decisões técnicas do stack da Korbi: Astro + Sanity + Vercel

Escolher Astro resolve a camada de renderização. Mas um site institucional completo — com blog, projetos e conteúdo que muda com frequência — precisa de mais três peças: onde o conteúdo mora, onde o código roda e como as duas partes conversam.

Camada	Ferramenta	Por que essa escolha
Renderização	Astro	HTML estático por padrão, JS só onde é interatividade real
Conteúdo	Sanity (headless CMS)	Edição de posts e projetos sem depender de deploy manual, com API rápida
Hospedagem	Vercel	Edge network global, build incremental, deploy automático a cada mudança
Estilo	CSS utilitário + design tokens	Consistência visual sem CSS morto acumulando por página

A combinação Astro + Sanity resolve um problema comum em sites institucionais: geralmente ou o site é rápido e rígido (HTML estático puro, sem CMS, qualquer alteração exige um desenvolvedor), ou é flexível e lento (WordPress com editor visual, mas pesado). Com Sanity como fonte de conteúdo e Astro buscando esses dados em build time, o site final continua sendo HTML estático — mas o conteúdo pode ser atualizado por qualquer pessoa do time, sem tocar em código.

Vercel entra como camada de distribuição. Cada página é servida da região mais próxima do visitante. Cada mudança de conteúdo gera um novo build automaticamente. Não existe intervalo entre "editor publicou" e "site atualizado" maior que alguns segundos.

Resultado prático: números que importam pro negócio

Depois de migrar pra esse stack, o site da Korbi roda com nota 95+ no Lighthouse em performance, mobile incluído. O LCP fica consistente abaixo de 1.2 segundos em conexão 4G simulada. Esse número reflete o que qualquer visitante real experimenta ao abrir o site pelo celular, fora do ambiente controlado de teste.

Antes da migração, versões anteriores do site rodavam em stack mais tradicional, com nota de performance mobile na faixa dos 60-70 no Lighthouse — típico de projeto que prioriza flexibilidade de edição em detrimento de velocidade de entrega. A diferença entre as duas fases não está em "polir" o código antigo. Está em partir de uma base que já nasce sem excesso pra remover.

Na prática isso significa:

1. Menos abandono na primeira tela — o visitante vê conteúdo antes de decidir sair
2. Melhor posicionamento orgânico em buscas relacionadas a design e web design em Porto Alegre
3. Formulário de contato carregando junto com o resto da página, sem atraso perceptível de hidratação

Esse ganho de velocidade tem impacto direto em conversão, não só em métrica técnica isolada. Já cobrimos a relação entre tempo de carregamento e taxa de conversão com mais profundidade em velocidade de site e impacto nas conversões — vale a leitura se você quer entender o tamanho financeiro desse tipo de decisão técnica.

O que essa escolha significa pro site que a Korbi entrega pra você

A pergunta que interessa pra quem está lendo isso pensando em contratar um site novo é direta: essa arquitetura só serve pro site da própria Korbi, ou também vale pro meu projeto?

Vale, com adaptação ao escopo. Astro é a base padrão que usamos em projetos institucionais, landing pages e sites de captação — os cenários onde a maior parte do conteúdo é estático e a prioridade é velocidade de carregamento. Projetos com necessidade real de aplicação complexa (dashboard de cliente, área logada com muita interação) pedem outra arquitetura, e nesses casos avaliamos caso a caso.

Pra site institucional, de serviço ou de captação de leads — a maioria dos projetos que fazemos — a régua é sempre a mesma: HTML estático como padrão, JavaScript só onde existe interatividade de verdade, CMS separado do código pra facilitar atualização, hospedagem em edge network. É o mesmo princípio de design responsivo mobile-first que aplicamos em design responsivo e abordagem mobile-first: a base tem que funcionar bem no cenário mais restrito antes de adicionar camadas.

Sinais de que o site atual do seu negócio está pagando esse preço de arquitetura errada:

• Lighthouse mobile abaixo de 70 em performance
• Tempo de LCP acima de 2.5 segundos
• Cada atualização de conteúdo depende de abrir código ou pedir pra um desenvolvedor
• Menu ou formulário demoram perceptivelmente pra responder ao primeiro toque

Se dois ou mais desses sinais soam familiares, a arquitetura do site — não só o design — provavelmente está custando conversão.

Performance técnica é a base, não o produto final

Vale um ponto de honestidade técnica: arquitetura rápida sozinha não fecha cliente. Ela remove o atrito que impede o design bom de fazer o trabalho dele. Um site com LCP de 0.9 segundos e hierarquia visual confusa converte pior do que um site levemente mais lento com copy certeira e CTA no lugar certo.

É por isso que Astro entra como decisão de infraestrutura, não como argumento de venda isolado. A conversa sobre performance técnica só faz sentido combinada com posicionamento de marca, hierarquia visual e texto que fala a língua de quem compra. Documentamos como essas peças se conectam em o que faz um site converter visitantes em clientes.

O padrão técnico existe pra sustentar decisões de negócio, nunca o contrário.

Se o site do seu negócio ainda carrega como se fosse 2015 — plugins acumulados, JavaScript sobrando, atualização de conteúdo dependendo de terceiro — vale rodar um diagnóstico rápido antes de decidir entre reforma ou site novo. A pergunta que decide isso: seu site entrega conteúdo antes que o visitante desista de esperar?

Comece medindo o Lighthouse mobile do site atual e o tempo de LCP em conexão real, não em wi-fi de escritório. Esses dois números, sozinhos, já mostram se o problema é estético ou estrutural — e é a partir dessa resposta que decidimos, com cada cliente, se o caminho é ajuste pontual ou reconstrução completa na stack que descrevemos aqui.