Por que escolhemos Astro para o novo Korbi Studio

Quando decidimos reconstruir o site da Korbi Studio do zero, a premissa era simples: performance absoluta sem sacrificar o design high-end.

Isso descartou rapidamente as opções óbvias — Framer é lindo mas pesa, WordPress é flexível mas cheio de overhead. Queríamos controle total sobre o output e um resultado que chegasse perto de 100/100 no PageSpeed sem gambiarra.

A resposta foi Astro.

O que é Astro e por que importa

Astro é um framework de geração de sites estáticos que parte de um princípio diferente: zero JavaScript por padrão. Enquanto frameworks como Next.js enviam um bundle de JS pra cada página e hidratam tudo no cliente, o Astro entrega HTML puro. JavaScript só entra quando você explicitamente precisar — e só onde precisar.

Isso é chamado de arquitetura de ilhas (islands architecture). Cada componente interativo é uma ilha isolada. O resto da página é HTML estático, sem peso.

Para um site institucional como o da Korbi, onde 90% do conteúdo não precisa de interatividade, isso é ideal. Mas o impacto vai além da teoria: na prática, significa que cada página carrega em menos de 1 segundo — mesmo com imagens em alta resolução.

Por que performance é parte do produto

Antes de entrar nos detalhes técnicos, é importante entender por que essa escolha importa para o cliente final.

Um site lento não é apenas uma experiência ruim — é uma ferramenta de captação que não funciona. O Google usa a velocidade de carregamento como fator de ranqueamento orgânico desde 2021. Páginas que demoram mais de 3 segundos para carregar perdem, em média, 53% dos visitantes antes mesmo de mostrar o conteúdo.

Para PMEs que dependem do site para gerar contatos e oportunidades, cada segundo de atraso tem um custo mensurável. É por isso que quando desenvolvemos sites para clientes, performance é tratada como parte do design, não como um detalhe técnico deixado para o final.

Faz sentido que o nosso próprio site seja um exemplo vivo disso.

Tailwind v4 — o CSS que não atrapalha

Junto com Astro, usamos Tailwind v4. A versão 4 trouxe mudanças significativas em relação à anterior:

• Configuração via CSS em vez de tailwind.config.js — tudo fica no lugar certo
• Performance de build dramaticamente mais rápida — hot reload em milissegundos
• CSS nativo com @theme — variáveis de design system sem camadas de abstração

O resultado prático: o CSS final do site tem menos de 20kb. Sem purge complexo, sem configuração excessiva, sem sobrecarga.

A diferença em relação a soluções como Bootstrap ou frameworks CSS tradicionais é que o Tailwind v4 não adiciona o que você não usa. Cada classe no stylesheet final tem um motivo de existir.

A stack completa

Ferramenta	Função
Astro v6	Framework principal (SSG)
Tailwind v4	Estilos com design tokens nativos
Sanity CMS	Conteúdo do blog
Lenis	Smooth scroll com performance nativa
Vercel	Deploy, CDN e analytics

Nada de CMS headless para o conteúdo estático — projetos, serviços e textos institucionais vivem em arquivos TypeScript com tipagem completa. O blog usa Sanity porque posts de conteúdo precisam de edição frequente e agendamento.

A decisão pelo SSG (Static Site Generation)

Existem basicamente três abordagens para sites modernos: SSR (renderização no servidor em tempo real), SSG (páginas pré-geradas em build time) e CSR (renderização no cliente). Cada uma tem seu caso de uso.

Para um site institucional, o SSG é a escolha óbvia:

• Sem servidor pra manter: as páginas são arquivos HTML estáticos hospedados em CDN
• Custo operacional zero: não há instância rodando 24/7
• Velocidade máxima: o HTML já está pronto quando o usuário chega
• Segurança: sem banco de dados exposto, sem superfície de ataque

O único trade-off é que atualizações de conteúdo exigem um rebuild. No nosso caso, isso é resolvido automaticamente — qualquer push no GitHub dispara um deploy novo no Vercel em menos de 2 minutos. Para o blog, o Sanity tem um webhook que aciona o rebuild quando um post é publicado.

O que isso muda na prática para projetos de clientes

A escolha de stack não é apenas uma preferência técnica — ela define o que é possível entregar em termos de qualidade, velocidade e custo de manutenção.

Quando indicamos Astro para um projeto, estamos indicando:

• Um site que provavelmente vai ranquear melhor no Google do que um WordPress com página builder
• Um produto que o cliente não vai precisar atualizar plugins toda semana
• Uma base que pode escalar sem reescrever tudo

Se o cliente precisa de e-commerce robusto, Astro não é a escolha certa — plataformas como Shopify fazem isso melhor. Se o cliente precisa de um app complexo com autenticação e dados em tempo real, faz mais sentido considerar Next.js ou outro framework SSR.

Mas para sites institucionais, landing pages, portfólios e blogs — onde o objetivo é converter visitantes em contatos — Astro com deploy estático é difícil de superar. É o que usamos, e é o que recomendamos.

O resultado em números

Depois do lançamento do novo site Korbi Studio em Astro:

• PageSpeed Desktop: 99/100
• PageSpeed Mobile: 94/100
• LCP (Largest Contentful Paint): < 1.2s
• CLS (Cumulative Layout Shift): 0
• CSS total: < 20kb

Esses números não são apenas vaidade de desenvolvedor. Eles têm impacto direto no ranqueamento orgânico e na experiência do usuário. Um site com LCP abaixo de 2.5 segundos atende ao critério "bom" do Google — algo que a maioria dos sites WordPress com builders não consegue sem configuração extensiva.

Se você está considerando construir ou reformular seu site e quer entender qual tecnologia faz sentido para o seu caso, essa é uma conversa que gostamos de ter.

Se você está considerando Astro

A curva de aprendizado é baixa se você já conhece HTML, CSS e um pouco de JavaScript. A documentação oficial (docs.astro.build) é excelente — um dos melhores exemplos de como documentar um framework de forma acessível.

Para projetos em equipe com designers que vão mexer no conteúdo, o Sanity como CMS headless complementa bem o Astro. Para conteúdo que não muda com frequência, arquivos Markdown ou TypeScript são suficientes.

O ganho de performance é real desde o primeiro deploy. E numa era em que o Google cada vez mais usa a experiência da página como critério de ranking, começar com uma base técnica sólida não é opcional — é vantagem competitiva.