WebAssembly em 2026: desempenho, casos de uso e limites

WebAssembly (Wasm) é um formato binário compacto que navegadores e runtimes independentes executam em velocidade próxima da nativa. É um grande ganho para trabalho limitado por CPU — codecs, processamento de imagem e vídeo, 3D, parsing, bancos de dados no navegador — e para reaproveitar bibliotecas existentes em C, C++ ou Rust. Não é um acelerador universal: em UIs pesadas de DOM e na lógica comum de aplicação, JavaScript bem otimizado é igualmente rápido ou mais, e cada chamada que cruza a fronteira JS↔Wasm tem custo. Este guia mostra onde o Wasm compensa, como ele se compara ao JavaScript, qual toolchain escolher e como decidir.

No que o WebAssembly é bom, e no que é ruim

Wasm é um conjunto de instruções de baixo nível, com tipagem estática. As engines validam e compilam um módulo antecipadamente ou em camadas, então a execução é previsível: sem otimização especulativa que desotimiza no meio do loop, sem troca de hidden classes, sem pausas de GC dentro de um kernel numérico (a menos que você compile a partir de uma linguagem com GC). Essa previsibilidade muitas vezes vale mais do que a velocidade de pico.

Onde o Wasm ganha

• Loops numéricos apertados sobre buffers grandes: operações por pixel, DSP de áudio, álgebra de matrizes, compressão, hashing, criptografia.
• Cargas que se beneficiam de SIMD (instruções vetoriais de 128 bits já são padrão nos principais navegadores).
• Parsers e transformações de entradas grandes: renderização de PDF, engines de planilha, engines de consulta, tokenizadores.
• Reaproveitamento de código nativo maduro sem reescrita: um kernel de geometria em C++ ou um parser em Rust já existente vai para o navegador com o mesmo comportamento e os mesmos testes.
• Controle do layout de memória: memória linear com structs e typed arrays evita o overhead do grafo de objetos que o JavaScript impõe.

Onde o Wasm perde ou é neutro

• DOM e APIs do navegador. O Wasm não toca o DOM, o fetch, o Canvas nem o WebGL diretamente; toda chamada passa por imports em JavaScript. Um framework de UI compilado para Wasm continua fazendo uma chamada JavaScript para cada elemento que cria.
• Cruzamentos de fronteira. Passar números é barato; passar strings e objetos significa copiar e codificar na memória linear. Código que chama o Wasm milhares de vezes por frame com payloads pequenos costuma acabar mais lento que JavaScript puro. Agrupe o trabalho e passe buffers, não valores individuais.
• Inicialização. O binário precisa ser baixado e compilado. A compilação em streaming ajuda, mas um módulo de vários megabytes com runtime embutido prejudica o primeiro carregamento. Sozinho, o Wasm não faz nada pelo Largest Contentful Paint nem pelo Interaction to Next Paint; veja Core Web Vitals e SEO técnico para o que faz.
• Lógica de negócio curta e cheia de alocações. Os JITs modernos de JavaScript são excelentes no tipo de código que a maioria dos web apps executa. Reescrever um validador de formulário em Rust não vai deixá-lo mais rápido.

O resumo honesto: o Wasm deixa a parte de computação rápida e previsível. Ele não deixa a parte web rápida.

WebAssembly vs JavaScript: como pensar a comparação

A comparação que as pessoas pesquisam é enganosa, porque os dois não competem pelo mesmo trabalho. Um enquadramento mais justo:

Critério	JavaScript	WebAssembly
Velocidade de pico em código numérico	Boa após aquecimento do JIT; pode desotimizar	Próxima da nativa, estável desde a primeira chamada
Acesso ao DOM / Web APIs	Direto	Só via imports JS
Custo de inicialização	Parse + compilação, incremental	Download + compilação do módulo inteiro
Modelo de memória	Heap de objetos com garbage collection	Memória linear (manual ou runtime da linguagem); tipos GC disponíveis para linguagens com GC
SIMD	Não (exceto via shaders WebGPU/WebGL)	Sim, SIMD de 128 bits
Threads	Web Workers com troca de mensagens	Workers + memória compartilhada + atomics (exige isolamento cross-origin)
Depuração	Excelente	Boa com DWARF no DevTools do Chrome/Firefox, mas mais fraca que em JS
Habilidades da equipe	Toda equipe web	Exige expertise em Rust/C++/Go
Melhor para	UI, lógica da aplicação, orquestração de I/O	Hot paths, bibliotecas portadas, engines

Uma regra prática: se um profiler mostra uma função consumindo a maior parte do tempo de CPU, e ela opera sobre buffers em vez de nós do DOM, é candidata a Wasm. Se o perfil está espalhado entre renderização, layout e handlers de evento, o Wasm não vai ajudar. Para a metade JavaScript, veja TypeScript vs JavaScript.

Casos de uso reais de WebAssembly que estão em produção

Estas são as categorias em que o Wasm já se provou, sem ser experimental:

Processamento de imagem, vídeo e áudio. Redimensionamento no cliente, filtros, remoção de fundo e codecs (decodificadores AV1, Opus, JPEG XL) compilados a partir de C. O FFmpeg compilado para Wasm transcodifica inteiramente no navegador, então o arquivo do usuário nunca sai da máquina.

CAD, 3D e geometria. Kernels de geometria, operações booleanas em malhas, física e parsers de arquivos CAD são bases de código clássicas em C++. Elas compilam para Wasm e alimentam um renderizador WebGL ou WebGPU. Nosso guia sobre WebGL e Three.js para aplicações web 3D cobre o lado da renderização; o Wasm é o que torna viável a matemática pesada por trás dela.

Editores de design e documentos. O Figma é o exemplo conhecido: um núcleo em C++ compilado para Wasm, UI em JavaScript, renderização na GPU. A mesma arquitetura serve para engines de planilha, editores de PDF e ferramentas de diagramação que precisam de um modelo de documento rápido e determinístico.

Jogos e emuladores. Unity e Godot exportam para a web via Wasm; emuladores e ports de jogos estão entre as cargas mais antigas do Wasm.

Execução de bibliotecas existentes em C/C++/Rust. SQLite, OpenCV, Tesseract OCR, zstd, libgit2 e muitas bibliotecas de criptografia têm builds em Wasm. Esse costuma ser o caso de negócio mais forte: sem reescrita, mesma suíte de testes, mesmo comportamento em todo lugar.

Bancos de dados e analytics no navegador. O SQLite compilado para Wasm (o build oficial, persistido via OPFS) dá aos web apps um banco relacional de verdade, offline. O DuckDB-Wasm roda SQL analítico sobre Parquet e CSV dentro da aba, transformando "envie seus dados para o nosso servidor gerar o gráfico" em "gere o gráfico localmente".

Linguagens e toolchains para WebAssembly

A linguagem determina o tamanho do binário, a ergonomia da interoperabilidade e quanto da plataforma você consegue usar. Resumo em 2026:

Linguagem / toolchain	Maturidade	Tamanho típico do binário	Garbage collector	Ergonomia de interop com JS	Melhor para
Rust + wasm-bindgen / wasm-pack	Muito alta; o padrão de fato	Pequeno (dezenas a centenas de KB)	Nenhum; modelo de ownership	Excelente: bindings tipados, web-sys/js-sys cobrem as Web APIs	Módulos novos, bibliotecas críticas em desempenho, ferramentas
C / C++ + Emscripten	Muito alta; toolchain mais antiga	Pequeno a médio; cresce com o uso de libc	Nenhum (manual)	Boa: embind, cola gerada, sistema de arquivos virtual	Portar bibliotecas nativas existentes, codecs, engines
Go (compilador padrão)	Média; funciona, GC e runtime embutidos	Grande (vários MB)	Sim, embarcado no binário	Básica via syscall/js; chamadas mais lentas	Reaproveitar lógica de negócio em Go; não para hot paths
TinyGo	Média	Pequeno	GC mínimo	Básica	Módulos Go pequenos, plugins, alvos WASI
C# / Blazor WebAssembly	Alta dentro do ecossistema .NET	Grande; o runtime é baixado (trimming AOT ajuda)	Sim, GC do .NET	Gerenciada pelo framework; framework de UI completo	Equipes padronizadas em .NET que querem SPA sem frameworks JS
AssemblyScript	Média; sintaxe parecida com TypeScript	Pequeno	GC simples embutido	Simples, mas limitada; não é um superconjunto de TypeScript	Equipes JS escrevendo módulos de cálculo pequenos sem aprender Rust
Kotlin/Wasm	Em crescimento; depende da proposta Wasm GC	Médio; precisa de navegadores com suporte a GC	Sim, usa o GC do navegador via Wasm GC	Melhorando; o Compose Multiplatform mira nele	Equipes Kotlin Multiplatform compartilhando código com a web

Observações que importam na escolha:

• Rust é a escolha mais segura para código novo. O wasm-bindgen gera bindings JavaScript tipados, o wasm-pack produz um pacote pronto para o npm, e o ecossistema (serde para serialização, wasm-opt para reduzir tamanho) é maduro. O custo é a curva de aprendizado.
• Emscripten é a ferramenta quando o código já existe em C ou C++. Ele emula POSIX o suficiente (arquivos, pthreads, SDL, OpenGL via WebGL) para que muitos projetos compilem com poucos ajustes.
• Linguagens com GC (Go, C#, Kotlin, Dart) historicamente embutiam o próprio garbage collector no módulo, o que infla o tamanho e duplica trabalho que o navegador já faz. A proposta Wasm GC muda isso: as linguagens agora podem alocar objetos gerenciados pelo coletor da engine. Kotlin/Wasm e Dart já se apoiam nela; espere que outras sigam. Se você precisa de um binário pequeno hoje, Rust ou C continuam sendo o caminho.
• AssemblyScript parece TypeScript, mas não é TypeScript: sem any, sem union types, sem closures sobre o heap do JS.

WebAssembly fora do navegador: WASI, edge, plugins

A segunda vida do Wasm é como formato executável portátil e isolado. Os ingredientes:

• WASI (WebAssembly System Interface) padroniza como um módulo acessa arquivos, relógios, números aleatórios, variáveis de ambiente e sockets. É baseado em capacidades: um módulo só enxerga o que o host concede. Entre os runtimes estão Wasmtime, Wasmer, WasmEdge e os embutidos em plataformas de nuvem.
• Runtimes de edge. Cloudflare Workers, Fastly Compute e plataformas semelhantes executam módulos Wasm com cold starts medidos em milissegundos, e não nos segundos típicos de funções baseadas em contêiner. O isolamento é por módulo, não por VM, então a densidade é muito maior. É o mesmo argumento que impulsiona a computação serverless, com uma unidade de deploy mais leve.
• Plugins e pontos de extensão. Produtos que precisam de código fornecido pelo usuário — sistemas de CI, proxies como o Envoy, bancos de dados, recursos de "lógica customizada" em SaaS — carregam cada vez mais plugins em Wasm. O host ganha um sandbox com capacidades explícitas e uma ABI independente de linguagem; o autor pode usar Rust, Go, C ou AssemblyScript. Frameworks como o Extism empacotam esse padrão.
• Shells desktop. Alguns apps desktop embutem um runtime Wasm para extensões não confiáveis; se você está avaliando opções desktop, veja Electron vs Tauri vs nativo.

O component model e a proposta de GC: onde as coisas estão em 2026

Duas propostas moldam a próxima fase. Ambas estão em uso ativo; nenhuma está "concluída" no sentido de que todo runtime e toolchain concordam em cada detalhe.

Wasm GC. Já disponível nas principais engines de navegador. Adiciona structs e arrays tipados gerenciados pelo garbage collector da engine. O efeito é que linguagens com GC não precisam mais embutir o próprio coletor, o que reduz binários e melhora a interoperabilidade com objetos JavaScript. Kotlin/Wasm, Dart/Flutter web e as iniciativas Java-para-Wasm dependem disso. Rust e C não usam e não precisam.

Component model e as versões preview do WASI. O component model define como módulos Wasm expõem e consomem interfaces tipadas (descritas na linguagem de interface WIT), para que um componente em Rust chame um componente em Go sem cola escrita à mão. As versões mais novas do WASI são construídas sobre ele. As ferramentas (wasm-tools, cargo component, wit-bindgen) são utilizáveis e vêm melhorando; os navegadores ainda não executam componentes nativamente, então no navegador você ainda empacota via polyfill do lado JavaScript ou fica nos módulos core com wasm-bindgen.

Conselho: no navegador, construa hoje sobre Wasm core mais wasm-bindgen ou Emscripten. No servidor e em plugins, aposte no component model, mas fixe as versões de runtime e ferramentas, porque as interfaces ainda mudam entre releases.

Metodologia de desempenho: meça antes e depois

A maioria dos projetos Wasm decepcionantes pulou esta etapa.

1. Faça profiling primeiro. Use o painel Performance do navegador ou um sampling profiler para encontrar a função quente de verdade. Se nenhuma função domina, pare: Wasm não é a solução.
2. Isole o kernel. Extraia o hot path para uma função pura que recebe buffers e devolve buffers. É essa função que você vai portar. Mantenha UI e I/O em JavaScript.
3. Projete a fronteira. Passe views Float32Array/Uint8Array sobre a memória linear, não arrays de objetos. Chame uma vez por frame ou por lote, não uma vez por item. Strings custam uma codificação/decodificação em cada direção; evite-as em loops quentes.
4. Ligue o SIMD. Rust: RUSTFLAGS="-C target-feature=+simd128" e os intrínsecos de std::arch::wasm32 ou autovetorização. Emscripten: -msimd128. Verifique se a saída compilada de fato vetorizou; a autovetorização não é garantida.
5. Threads quando os dados são grandes. Threads em Wasm usam Web Workers sobre memória compartilhada e atomics. Elas exigem headers de isolamento cross-origin (Cross-Origin-Opener-Policy e Cross-Origin-Embedder-Policy), que podem quebrar embeds de terceiros. Confirme que seu deploy consegue definir esses headers antes de projetar em torno de threads.
6. Gerencie a memória explicitamente. A memória linear cresce, mas não encolhe. Reutilize buffers, use alocadores de arena para trabalho por frame e limite o crescimento. Um módulo Wasm vazando memória em uma aba de longa duração é uma surpresa comum em produção.
7. Otimize o binário. Rode wasm-opt -O3 (ou -Oz para tamanho) do Binaryen, remova as informações de depuração em produção, sirva com Brotli e carregue com WebAssembly.instantiateStreaming, para que a compilação se sobreponha ao download.
8. Compare com JavaScript otimizado. Compare com uma implementação em JS aquecida, baseada em typed arrays. Se o ganho for inferior a cerca de 2x, questione se a toolchain adicional vale a pena.
9. Meça em campo. Publique atrás de uma feature flag com fallback em JavaScript e compare tempos e taxas de erro de usuários reais.

Um exemplo mínimo de Rust para Wasm

Instale o target e o wasm-pack (o guia oficial do wasm-bindgen em rustwasm.github.io traz os detalhes) e depois:

cargo new --lib grayscale
cd grayscale
rustup target add wasm32-unknown-unknown
cargo add wasm-bindgen

O Cargo.toml precisa do crate type cdylib:

[lib]
crate-type = ["cdylib"]

[profile.release]
opt-level = 3
lto = true

A biblioteca opera in-place sobre um buffer RGBA, o que evita copiar pixels através da fronteira:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn grayscale(pixels: &mut [u8]) {
    for px in pixels.chunks_exact_mut(4) {
        let l = (0.299 * px[0] as f32
               + 0.587 * px[1] as f32
               + 0.114 * px[2] as f32) as u8;
        px[0] = l;
        px[1] = l;
        px[2] = l;
    }
}

Compile e chame a partir do JavaScript:

wasm-pack build --target web --release

import init, { grayscale } from "./pkg/grayscale.js";

await init();
const ctx = canvas.getContext("2d");
const image = ctx.getImageData(0, 0, canvas.width, canvas.height);
grayscale(image.data);           // uma chamada, o buffer inteiro
ctx.putImageData(image, 0, 0);

O que torna isso rápido: um cruzamento de fronteira por frame, um typed array entrando e saindo, sem strings, sem objetos. Chamada por pixel a partir do JavaScript, a mesma função perderia para um loop JS simples.

Checklist de decisão: esta carga de trabalho deve usar WebAssembly?

Responda sim à maioria destes pontos antes de se comprometer:

• Um profiler mostra uma ou poucas funções limitadas por CPU dominando a carga.
• Essas funções operam sobre buffers, números ou textos grandes, não sobre nós do DOM.
• O trabalho pode ser agrupado em lotes, de modo que a fronteira JS↔Wasm seja cruzada raramente.
• Você tem uma biblioteca existente em C/C++/Rust para reaproveitar, ou uma equipe confortável com Rust ou C++.
• O tamanho do binário é aceitável para seus usuários depois de wasm-opt e Brotli, e o módulo pode ser carregado sob demanda fora do caminho crítico.
• O trabalho se beneficia de SIMD ou multithreading, e você consegue definir headers de isolamento cross-origin se precisar de threads.
• Você consegue manter um fallback em JavaScript ou uma feature flag durante o rollout.
• Depuração com DWARF no DevTools é aceitável, e o CI cobre o módulo no Node e em um navegador headless.

Prefira JavaScript puro (ou TypeScript) quando:

• O gargalo é renderização, layout, rede ou gerenciamento de estado.
• A lógica é curta, cheia de alocações ou presa ao DOM.
• A equipe não tem experiência com linguagens de sistema e o ganho seria marginal.

Prefira Wasm fora do navegador (WASI, edge, plugins) quando:

• Você precisa executar código não confiável ou de terceiros com capacidades granulares.
• Tempo de cold start e densidade importam mais do que o throughput bruto de pico.
• Você quer um único artefato que rode de forma idêntica em Linux, macOS, Windows e hosts de edge.

Recomendação

Trate o WebAssembly como uma ferramenta de precisão, não como uma migração de plataforma. Mantenha UI, roteamento e busca de dados em JavaScript. Coloque Wasm onde o profiler aponta: codecs, geometria, parsing, analytics e bibliotecas nativas existentes que você reescreveria de outra forma. Use Rust com wasm-bindgen para módulos novos e Emscripten para código C/C++ portado; evite toolchains de linguagens com GC em hot paths até que o suporte a Wasm GC seja algo verificado nos seus navegadores-alvo. Projete a fronteira em torno de buffers e lotes, habilite SIMD, rode wasm-opt e compare com JavaScript otimizado antes de publicar. No servidor e no edge, WASI e o component model valem a adoção para plugins e funções isoladas, com versões fixadas enquanto os padrões se estabilizam. Na Arvucore, costumamos recomendar começar com um único kernel isolado atrás de uma feature flag, medir o impacto em usuários reais por dois ciclos de release e expandir só quando os números justificarem a toolchain extra.