Apliquei Mounjaro no meu portfólio e ele perdeu 5 Megabytes.

Eu tinha um site que, visualmente, cumpria o seu papel. Ele rodava em WordPress + Elementor. Era fácil e rápido de editar, afinal, a promessa do page builder é democratizar o design. Mas, por trás da tela bonita, havia um Frankenstein de código bem sujo.

Chegou num ponto em que qualquer necessidade técnica exigia instalar um novo plugin. O site quebrava do nada. O cache dava problema toda hora… Eu não tinha mais controle sobre a minha própria ferramenta; eu era refém do ecossistema dela.

Como Product Designer orientado a dados, fui olhar os números. O diagnóstico do GTmetrix era claro: meu site pesava 5.51MB e disparava 83 requisições a cada carregamento. Era um caminhão de lixo digital sendo descarregado no navegador de quem tentava conhecer meu trabalho (Já até imagino quantas pessoas tentaram acessar e saíram pq o site demorou alguns segundos a mais 🥲).

Decidi jogar tudo fora e recomeçar.

Fui para o extremo oposto: HTML semântico, CSS Vanilla e Eleventy (11ty) como gerador de site estático. Nada de banco de dados. Nada de CMS pesando o servidor. Para essa migração, assumi a arquitetura e deixei o operacional pesado (a codificação massiva) nas mãos do Claude Code.

Os desafios não foram poucos. Tive uma dor de cabeça imensa para configurar a automação de deploy. O GitHub Actions esbarrava no bloqueio de IPs dinâmicos da Hostinger. Foram horas quebrando a cabeça até descobrir que a solução era mais simples: montar o diretório direto no painel da Hostinger e usar um webhook para disparar a implantação automática a cada push. Problema de infraestrutura resolvido. E pra quem tá se perguntando: Por que a Hostinger? Por que não Vercel ou CloudeFlare Pages? A resposta é simples: eu paguei pela hospedagem e agora preciso usar! 🤣

Mas e o resultado final? A matemática da performance responde:

• A nota de performance saltou de B (85%) para A (99%).
• O tempo de bloqueio de renderização (TBT) caiu de 52ms para zero. Literalmente 0ms.
• O tempo que o usuário espera para ver o conteúdo principal (LCP) despencou de 1.7s para 857ms.
• E o peso da página? De impressionantes 5.51MB para cirúrgicos 408KB.

Por que isso importa para o Design? Parece um papo estritamente de desenvolvedor, mas não é. Performance é Experiência do Usuário pura.

Um site de 400KB carrega quase instantaneamente numa rede 3G oscilante. Escrever o HTML na mão (em vez de deixar o Elementor adivinhar) me permitiu colocar intenção real em cada tag <header>, <article> e atributo alt. Acessibilidade deixou de ser um “check” automático e falho de um plugin para se tornar uma decisão consciente de design.

Ferramentas low-code sempre terão seu espaço. Elas são excelentes para páginas menores, como landing pages de campanhas, e entendo perfeitamente por que são o padrão absoluto no ritmo frenético das agências de marketing. A velocidade visual que o “arrastar e soltar” proporciona no curto prazo é inegável.

Mas o jogo está mudando. O principal argumento para não se usar código puro em agências sempre foi o custo e o tempo de desenvolvimento. Com o crescimento brutal das IAs assumindo o trabalho braçal e repetitivo da engenharia de software, esse argumento começa a ruir. Talvez seja o momento de o mercado de marketing começar a entregar projetos com código limpo e alta performance, sem abrir mão da agilidade.

Não me entenda mal: a transição não é mágica. Existe uma curva de aprendizado, e ela não é pequena. Abandonar a conveniência dos page builders para entender lógica de build, CSS raiz e automações de servidor exige dedicação e uma mudança profunda de mentalidade.

A grande diferença é que, hoje, você não precisa fazer isso sozinho. Com a IA atuando como sua parceira técnica e acelerando o processo, o salto para o “básico bem feito” (HTML e CSS puro) está muito mais acessível do que era no passado pré-IA. A barreira técnica não sumiu, mas nunca foi tão transponível, e, no fim do dia, o 3G do seu usuário agradece.💓