Lesse Studio foi fundado há cinco anos em Bali. Naquela época, éramos uma equipe pequena, descobrindo as coisas à medida que avançávamos, entregando projetos em muitas estruturas diferentes, experimentando diferentes formas de trabalhar e aprendendo pelo menos tanto com nossos fracassos quanto com nossos sucessos. Muita coisa mudou desde então. Mudámo-nos para Itália, aumentámos a equipa e gradualmente desenvolvemos uma compreensão mais clara de como queríamos trabalhar e do que realmente valorizávamos na nossa pilha de tecnologia.
O Desafio
Nosso site anterior se apoiava fortemente no visual experimentação. Foi atmosférico, expressivo e um reflexo de onde o estúdio estava criativamente na época. Nós gostamos. Mas com o tempo, ficou claro que gostar do seu próprio site e fazer com que ele realmente funcione para seus clientes são duas coisas muito diferentes. A navegação era frouxa, informações importantes eram mais difíceis de encontrar do que deveriam e a experiência geral, embora visualmente interessante, nem sempre era confortável para alguém que simplesmente tentava entender o que fazemos e se somos adequados.
O principal desafio do novo site foi encontrar o equilíbrio certo entre criatividade e funcionalidade. Queríamos preservar a essência emocional e artística da marca ao mesmo tempo que construímos algo que guiasse naturalmente as pessoas através da experiência. Esse é um problema mais difícil do que parece, porque a tentação durante um redesenho é jogar pelo seguro e perder a identidade da marca ou dobrar a direção de arte e acabar com os mesmos problemas de usabilidade novamente.
A Solução
Redesenhamos a estrutura com maior foco na clareza e no fluxo do usuário, simplificando a navegação e criando caminhos mais intuitivos em todo o site. Também facilitamos o acesso ao formulário de consulta e a localização de informações sobre nosso processo em vários pontos da jornada, pois um site bonito que dificulta o contato acaba falhando em seu propósito.
Ao mesmo tempo, era importante que o resultado ainda nos agradasse. Através de tipografia refinada, layouts intencionais, interações mínimas e movimentos sutis, preservamos a sensação de atmosfera e energia criativa que define o Lesse Studio. A identidade visual permaneceu intacta. Simplesmente paramos de fazer as pessoas trabalharem para vivenciar isso. Criatividade e funcionalidade não precisam estar em conflito, e esta reconstrução foi a nossa maneira de provar isso a nós mesmos.
O caminho para a otimização
Um dos maiores pontos de virada ocorreu no ano passado, quando decidimos nos afastar totalmente dos provedores de nuvem. Estávamos executando serviços mais pesados na AWS e implantando sites mais simples no Vercel, como a maioria dos estúdios do nosso tamanho. Funcionou, mas estávamos pagando por uma conveniência que não precisávamos totalmente e tínhamos menos controle do que queríamos. Então, mudamos para auto-hospedar tudo em nossos próprios servidores.
Ao seguir esse caminho, você rapidamente se depara com dois caminhos: ou você se cansa de gerenciar a complexidade, a segurança e os pipelines de implantação ou fica completamente viciado nisso. Caímos firmemente no segundo campo. Uma por uma, cada peça de nossa infraestrutura foi movida internamente e, quando a poeira baixou, nossos custos de manutenção caíram em ordens de magnitude.
Mas algo mais aconteceu também. Quando você é responsável por tudo, você começa a pensar de forma diferente. Você se pergunta constantemente se é possível espremer mais uma instância em 16 GB de RAM, se um serviço realmente precisa ser tão pesado e se existe uma maneira mais enxuta de obter o mesmo resultado. Essa mentalidade foi o que deixou nossa equipe obcecada pela otimização.
Ele apareceu primeiro no backend. Reescrevemos alguns de nossos serviços em Go e Rust, e a diferença em comparação com nossas configurações anteriores de Node.js e Django foi impressionante, não ganhos marginais, mas melhorias de eficiência em uma escala completamente diferente. Estávamos correndo mais, gastando menos e dormindo melhor (a ferrugem realmente não quebra).
Mas havia um elefante na sala que estávamos ignorando há muito tempo. Todos os nossos aplicativos front-end ainda foram construídos com Next.js, Vue, Angular ou estruturas virtuais semelhantes baseadas em DOM. Nos nossos próprios servidores, o custo dessa escolha tornou-se impossível de ignorar. Uma única instância Next.js pode consumir 500 MB de RAM, especialmente quando combinada com uma camada Express.js que lida com a funcionalidade básica do CMS. Dez sites de alto tráfego consumindo no mínimo 5 GB entre eles – isso não é uma preocupação de desempenho; é um problema estrutural.
Então começamos a fazer a pergunta que deveríamos ter feito muito antes: o que deveríamos usar em vez disso?
Eu já tinha ouvido falar de Svelte e SolidJS antes. Svelte, em particular, tinha a reputação de ser amado por quase todos que o usavam. Eu sabia que era leve, mas nunca tive tempo para entender completamente o porquê. Então decidi tentar. O que descobri parecia bom demais para ser verdade: uma estrutura que compila JavaScript preciso e eficiente, sem DOM virtual, sem tempo de execução pesado e sem pacotes inchados. Para uma equipe que passou o ano passado obcecada com o uso e a eficiência da RAM, parecia a peça que faltava no quebra-cabeça.
Decidimos usá-lo nos próximos dois projetos que tínhamos planejado, simplesmente para ver como funcionaria na prática. Foi um sucesso imediato. Onde nossas instâncias Next.js tinham cerca de 500 MB de RAM sob carga, Svelte chegou a cerca de 30 MB, e a substituição do Node.js pelo Bun reduziu isso ainda mais, aproximando-o de 20 MB. Os números falavam claramente por si.
Então, quando chegou a hora de reconstruir o site de nossa própria agência, a decisão foi fácil. Escolhemos o SvelteKit e tratamos o projeto como um experimento genuíno, não apenas uma migração, mas uma oportunidade de levar a pilha o mais longe que pudemos. Tudo funciona em uma única instância: um CMS privado integrado diretamente na camada API do SvelteKit para gerenciamento de conteúdo, Drizzle como um ORM leve para armazenamento de dados e todas as animações escritas do zero, sem depender de uma única biblioteca de animações. As imagens são convertidas automaticamente para WebP durante o pipeline de upload e veiculadas por meio do Cloudflare R2. Os tempos de carregamento são rápidos, o espaço ocupado é pequeno e temos controle total sobre todas as camadas do sistema.
A arquitetura em si é deliberadamente mínima. O SvelteKit lida com a lógica do front-end e do lado do servidor em um único processo, o que significa nenhuma camada de API separada, nenhuma latência de rede adicional e um serviço a menos para monitorar. Roteamento, renderização e busca de dados vivem juntos e, como a renderização do lado do servidor do SvelteKit é compilada em JavaScript simples sem sobrecarga de DOM virtual, o HTML que chega ao navegador já está completo. Não há cascatas de hidratação do lado do cliente nem mudanças de layout enquanto o JavaScript acompanha a marcação.
Para o CMS, construímos o nosso próprio. Não é nada particularmente complexo, apenas uma interface de administração simples apoiada por Drizzle ORM em cima de SQLite. Vale ressaltar a escolha do SQLite porque muitas vezes surpreende as pessoas. Mas para um site orientado a conteúdo com padrões de leitura previsíveis e sem necessidade de gravações simultâneas em grande escala, o SQLite é genuinamente a ferramenta certa. Ele é executado em processo, não requer nenhuma sobrecarga de rede para consultas e armazena todo o banco de dados em um único arquivo no disco. O Drizzle mantém a camada de consulta segura sem introduzir o custo de abstração de ORMs mais pesados como o Prisma, que pode ser desnecessariamente pesado para projetos dessa escala.
As imagens foram uma das primeiras áreas que otimizamos. Cada ativo carregado por meio do CMS é automaticamente convertido em WebP antes mesmo de chegar ao armazenamento – sem etapas manuais de exportação e sem inconsistências entre editores. A partir daí, os arquivos são enviados diretamente para o Cloudflare R2 e servidos na borda, sem nunca mais passar pela instância do nosso aplicativo. Após o upload, o servidor nunca toca uma imagem pela segunda vez.
As animações foram outra decisão deliberada. A maioria das equipes recorre ao GSAP ou Framer Motion sem muita discussão. São bibliotecas excelentes, mas têm um custo. Como o Svelte vem com um sistema de transição integrado e as ações use: lidam com gatilhos baseados em rolagem de maneira limpa, optamos por escrever tudo sozinhos. O resultado é um código de animação totalmente agitável em árvore e que não contribui em nada para o pacote, a menos que seja realmente usado em uma página específica.
Sob tráfego real, a instância do servidor fica confortavelmente entre 25 MB e 40 MB de RAM. Nada disso aconteceu por acaso. Surgiu ao tratar cada dependência como um custo e não como um incumprimento, e apenas pagar esse custo quando houvesse uma razão clara para o fazer.
Em última análise, foi isso que um ano de auto-hospedagem nos ensinou. Quando você consegue ver exatamente quanto custa cada processo, você para de pensar no código frontend como algo que simplesmente roda no navegador e começa a pensar nele como uma infraestrutura. E uma vez que essa mudança aconteça, a questão não será mais “Podemos usar isto?” mas sim, “Será que realmente precisamos disso?”
Svelte se encaixa naturalmente nessa mentalidade. Não porque seja a escolha mais moderna ou a estrutura apoiada pela maior empresa, mas porque segue o mesmo princípio que já havíamos construído: envie apenas o que é necessário e faça valer o que você envia.
O navegador se beneficia disso. O servidor se beneficia disso. E, em última análise, o planeta também.
