Por que refazer o site, e as regras que me impus

Site pessoal de programador tem dois destinos comuns. Ou vira um WordPress esquecido, com plugin desatualizado e formulário que ninguém lê. Ou vira o projeto eterno: aquele que ganha um framework novo a cada seis meses e nunca chega ao ar.

Eu já tive os dois. Desta vez comecei diferente: escrevi as restrições antes de escrever a primeira linha de código.

As regras

Zero dependência externa em runtime. Nada de CDN de fonte, nada de script de terceiro, nada de chamada a API para renderizar a página. Se o Google Fonts cair, meu site não pode piscar. Isso vale também para privacidade: sem requisição externa, ninguém rastreia quem me visita.

Zero banco de dados. Publicar um post tem que ser criar um arquivo e dar push. Sem painel, sem migration, sem backup para lembrar de fazer.

Zero JavaScript de framework no cliente. Um portfólio é conteúdo. Mandar 80 KB de runtime para renderizar texto que já existe no HTML é desperdício.

URLs limpas e permanentes. /sobre, não /sobre.html nem /pages/sobre/. Endereço de conteúdo é contrato: se eu mudar depois, quebro link de terceiro.

O conteúdo mora no repositório. Versionado, com histórico, diffável em pull request. Se um dia eu quiser migrar de gerador, o conteúdo vem junto.

O que essas regras eliminaram

Foi mais rápido descartar do que escolher.

WordPress e afins morrem na primeira regra. Banco, PHP em runtime, superfície de ataque e manutenção contínua para servir um texto que nunca muda.

Next.js resolveria, mas com muito peso extra. Eu não preciso de React para renderizar um currículo, e o custo é hidratação e um bundle que só existe para desfazer o que o servidor já fez.

Hugo é rapidíssimo e atenderia quase tudo. Travou na componentização: eu queria componentes de verdade e comportamento pontual — um menu mobile, uma busca — sem carregar framework na página inteira.

Astro ficou porque resolve exatamente essa tensão. Renderiza tudo em HTML estático no build, manda zero JavaScript por padrão, e quando eu preciso de interatividade num ponto específico, mando só aquele pedaço.

O ponto de partida

Eu não comecei do branco. Tinha nove layouts HTML prontos, gerados a partir de um design system que eu já havia definido — paleta, tipografia, espaçamento, sombras. Nove arquivos que funcionavam visualmente e eram péssimos como código:

• O mesmo header repetido nove vezes, com nove variações sutis
• O rodapé em quatro arranjos diferentes
• A configuração inteira do Tailwind duplicada em cada arquivo
• Três dependências externas em runtime: CDN do Tailwind, Google Fonts e a webfont de ícones do Material Symbols
• Imagens apontando para URLs temporárias que iam expirar

O trabalho, então, não era desenhar. Era transformar layout em sistema: achar o que se repetia, extrair, e reconstruir cada página a partir das peças — sem mudar um pixel do resultado.

Como vou medir se deu certo

Coloquei número em tudo que dá, para não terminar com “ficou bom” como critério:

• JavaScript no cliente: meta de 0 KB de framework
• Requisições externas: meta de zero, verificável com grep no build
• Tempo de build: abaixo de 30 segundos, para publicar não dar preguiça
• Publicar um post: um arquivo, um comando

O diário a seguir registra o que aconteceu com cada uma dessas metas — inclusive onde eu errei a estimativa.