Rustwright reescreve Playwright em Rust com 70% menos memória

Playwright consolidou-se como referência para automação de browser porque unifica Chromium, Firefox e WebKit sob uma API estável. Porém, em muitos ambientes de produção, cada instância arrasta o custo de manter Node.js ativo como intermediário entre o script e o navegador. Esse modelo funciona, mas escala mal quando centenas de sessões rodam em paralelo em CI, em farms de scraping ou em agentes que precisam abrir páginas sob demanda.

O Rustwright ataca exatamente essa camada. Ao reimplementar o motor em Rust e falar com o CDP de forma nativa, o projeto elimina a necessidade de um processo Node dedicado só para orquestrar o browser. Menos processos significa menos context switching, menos overhead de serialização entre linguagens e menos memória reservada antes mesmo de carregar a primeira aba. Para equipes que medem custo por vCPU e por gigabyte em nuvem, a diferença deixa de ser marginal.

Reescrever uma ferramenta de automação do zero costuma implicar reescrever também toda a suíte de testes. O ponto central do Rustwright é manter compatibilidade com a API do Playwright, de modo que scripts, seletores, waits e fluxos já escritos não precisem ser descartados na primeira tentativa de adoção.

Na prática, isso posiciona o projeto como ponte entre dois mundos, quem já padronizou Playwright em TypeScript ou Python pode avaliar o motor Rust como substituto de runtime sem refatorar a lógica de negócio dos testes. Para startups que constroem produtos de automação, como a própria Skyvern-AI, essa continuidade reduz o risco de fragmentar ecossistemas internos e acelera experimentos em ambientes onde latência e RAM pesam mais que a conveniência de rodar tudo em JavaScript.

Os ganhos citados pela fonte, 2,55 vezes mais velocidade e 70% menos memória, ganham sentido quando o workload não é um único teste local, mas milhares de execuções diárias. Pipelines de integração contínua que disparam dezenas de jobs simultâneos frequentemente limitam paralelismo por memória, não por CPU. Um motor mais enxuto libera slots de execução sem aumentar o tamanho da máquina.

O mesmo vale para agentes que navegam na web de forma autônoma, cada sessão de browser é um recurso caro. Quando o motor consome menos RAM e responde mais rápido, dá para manter mais contextos ativos ou reduzir o bill de infraestrutura sem sacrificar cobertura. O CDP nativo também encurta o caminho entre comando e resposta, o que melhora fluxos que dependem de cliques, preenchimento de formulários e captura de DOM em tempo real.

A aparição do Rustwright no Hacker News reflete uma tendência mais ampla, ferramentas de infraestrutura que nasceram em ecossistemas dinâmicos começam a ganhar versões em linguagens de sistemas quando o problema deixa de ser prototipar e passa a ser operar em escala. Browser automation sempre esteve nessa fronteira. É fácil começar com Playwright em um repositório; é difícil sustentar milhares de sessões estáveis sem otimizar cada camada da pilha.

Para desenvolvedores brasileiros que mantêm suites de teste pesadas, crawlers regulados por SLA ou produtos SaaS com navegação programática, o projeto oferece um sinal claro de que a próxima otimização pode estar no runtime, não apenas no código do teste. Ainda é software em evolução, hospedado em repositório aberto, mas a combinação de API familiar, ganhos explícitos de memória e eliminação do Node como intermediário torna o Rustwright um candidato sério para quem já esbarrou no teto de custo do Playwright em produção.