Para um designer em atividade, um site de portfólio ocupa um meio-termo desconfortável. Ele precisa ter um visual impecável, carregar instantaneamente e permanecer atualizado sem consumir horas faturáveis. Minha configuração antiga era no Webflow, que preenchia a lacuna entre construtores de arrastar e soltar e resultados profissionais melhor do que a maioria das ferramentas. Mas quando o aviso de renovação chegou com uma fatura anual de £300, tive que fazer uma pergunta difícil: eu estava pagando pelo valor ou apenas pela conveniência?

Decidi reconstruir tudo do zero. A nova stack é Astro e Sanity. Depois de conviver com ela por um tempo, aqui está exatamente o que funcionou, o que não funcionou e onde ela se posiciona em relação às ferramentas que eu usava antes.

Por que Astro para um portfólio?

A maioria dos frameworks web modernos entrega JavaScript primeiro e faz perguntas depois. O Astro inverte essa lógica. Ele gera HTML estático puro no momento do build e só envia JavaScript para o navegador quando um componente específico realmente precisa dele. Eles chamam isso de arquitetura de ilhas, mas o resultado prático é mais simples: as páginas do meu portfólio quase não pesam nada.

O roteamento é baseado em arquivos, então criar uma nova página é tão fácil quanto soltar um arquivo em uma pasta. Os componentes usam uma sintaxe que parecerá familiar se você já mexeu com React, Vue ou Svelte. Não preciso recorrer a um novo paradigma toda vez que quero adicionar um estudo de caso de projeto.

Dito isso, eu não usaria o Astro para construir uma aplicação web complexa. Se você estiver configurando autenticação, gerenciando estado global ou lidando com dados em tempo real, você lutará contra o framework. No entanto, para sites de marketing, blogs e portfólios, ele não atrapalha. As páginas parecem rápidas porque são rápidas. Não há o overhead de hidratação esperando para renderizar um título ou um parágrafo.

Migrando do WordPress para o Sanity

Antes desta reconstrução, minha alternativa era sempre o WordPress com Advanced Custom Fields. O ACF dá superpoderes ao WordPress, mas você ainda está configurando a casa de outra pessoa. O Sanity funciona de forma inversa. Você escreve um esquema em código que define exatamente como seu modelo de conteúdo se parece, e o Sanity constrói a interface de edição em torno das suas decisões.

Usei esse controle para construir um construtor de páginas simples a partir de blocos reutilizáveis. Defini uma seção hero uma vez. Defini um carrossel de depoimentos uma vez. Defini uma grade de cartões uma vez. Agora posso montar novas páginas empilhando esses blocos em qualquer ordem, sem escrever novo código ou tocar em um template de página.

A diferença de mentalidade importa. Com o WordPress, eu frequentemente sentia que estava lutando contra uma ferramenta que queria ser um blog. Com o Sanity, sinto que estou construindo software. O conteúdo se torna dados estruturados limpos, em vez de HTML estilizado misturado com shortcodes. Minhas descrições de projeto vivem como objetos portáteis que eu poderia enviar para um aplicativo móvel ou uma newsletter, se quisesse.

Um fluxo de implantação que se mantém limpo

Meu antigo fluxo de trabalho no WordPress era uma bagunça de uploads via FTP, subdomínios de staging e atualizações de plugins que sempre pareciam quebrar no pior momento. Eu mantinha uma lista mental de tarefas apenas para publicar a correção de um erro de digitação.

O novo fluxo de trabalho é curto:

  • Faço as alterações localmente e as vejo instantaneamente.
  • Faço o commit no GitHub quando o código parece correto.
  • O Vercel identifica o push e faz o deploy do site automaticamente.

Não há cliente FTP. Não há banco de dados de staging para sincronizar. O repositório é a única fonte de verdade.

O conteúdo funciona da mesma maneira. Quando publico ou atualizo um post dentro do Sanity, um webhook avisa o Vercel para reconstruir o site. As páginas estáticas são regeneradas com conteúdo novo, e o CDN é atualizado sem que eu precise tocar em um servidor. Tudo permanece sincronizado sem cópias manuais, exportações ou orações para que uma migração de banco de dados de um plugin realmente tenha funcionado.

Unindo design e código com tokens

Um dos avanços mais discretos nesta reconstrução foi a configuração de um sistema de tokens adequado. Mantenho um único arquivo JSON que detém cada cor, escala tipográfica e valor de espaçamento no site. Esse arquivo é o chefe.

Uso o Token Studio para puxar esses mesmos valores diretamente para o Figma. Quando meu arquivo de design diz surface-default, ele está apontando para o exato mesmo número que o código usa. Um pequeno script converte o JSON em propriedades customizadas de CSS no momento do build, para que minhas folhas de estilo façam referência a variáveis como --color-surface-default em vez de códigos hexadecimais fixos.

Aqui está o porquê disso importar na prática. Se eu perceber que o vermelho da minha marca está um pouco agressivo demais em telas de celular, eu altero um único valor no arquivo JSON. A biblioteca do Figma é atualizada. O CSS é atualizado. Todas as instâncias em todo o site são atualizadas. Eu não preciso de um grep