WebAssembly en 2026: rendimiento, casos de uso y límites

WebAssembly (Wasm) es un formato binario compacto que los navegadores y los runtimes independientes ejecutan a una velocidad cercana a la nativa. Es una gran ventaja para trabajo limitado por CPU — códecs, procesamiento de imagen y vídeo, 3D, parsing, bases de datos en el navegador — y para reutilizar bibliotecas existentes en C, C++ o Rust. No es un acelerador universal: en UIs cargadas de DOM y en la lógica de aplicación habitual, un JavaScript bien optimizado es igual de rápido o más, y cada llamada que cruza la frontera JS↔Wasm tiene un coste. Esta guía cubre dónde compensa Wasm, cómo se compara con JavaScript, qué toolchain elegir y cómo decidir.

En qué es bueno WebAssembly, y en qué es malo

Wasm es un conjunto de instrucciones de bajo nivel con tipado estático. Los motores validan y compilan un módulo por adelantado o por niveles, así que la ejecución es predecible: sin optimización especulativa que se desoptimiza a mitad de bucle, sin cambios de hidden classes, sin pausas de GC dentro de un kernel numérico (salvo que compiles desde un lenguaje con GC). Esa previsibilidad suele valer más que la velocidad pico.

Dónde gana Wasm

• Bucles numéricos ajustados sobre buffers grandes: operaciones por píxel, DSP de audio, álgebra de matrices, compresión, hashing, cifrado.
• Cargas que se benefician de SIMD (las instrucciones vectoriales de 128 bits ya son estándar en los principales navegadores).
• Parsers y transformaciones de entradas grandes: renderizado de PDF, motores de hojas de cálculo, motores de consulta, tokenizadores.
• Reutilización de código nativo maduro sin reescritura: un kernel de geometría en C++ o un parser en Rust ya existentes llegan al navegador con el mismo comportamiento y los mismos tests.
• Control del layout de memoria: la memoria lineal con structs y typed arrays evita la sobrecarga del grafo de objetos que impone JavaScript.

Dónde pierde Wasm o es neutral

• DOM y APIs del navegador. Wasm no puede tocar el DOM, fetch, Canvas ni WebGL directamente; cada llamada pasa por imports de JavaScript. Un framework de UI compilado a Wasm sigue haciendo una llamada JavaScript por cada elemento que crea.
• Cruces de frontera. Pasar números es barato; pasar strings y objetos implica copiar y codificar en la memoria lineal. El código que llama a Wasm miles de veces por frame con payloads pequeños suele acabar más lento que JavaScript puro. Agrupa el trabajo y pasa buffers, no valores individuales.
• Arranque. El binario tiene que descargarse y compilarse. La compilación en streaming ayuda, pero un módulo de varios megabytes con runtime incluido perjudica la primera carga. Wasm por sí solo no hace nada por el Largest Contentful Paint ni por el Interaction to Next Paint; consulta Core Web Vitals y SEO técnico para ver qué sí lo hace.
• Lógica de negocio corta y con muchas asignaciones. Los JIT modernos de JavaScript son excelentes en el tipo de código que ejecutan la mayoría de las web apps. Reescribir un validador de formularios en Rust no lo hará más rápido.

El resumen honesto: Wasm hace que la parte de cómputo sea rápida y predecible. No hace que la parte web sea rápida.

WebAssembly vs JavaScript: cómo plantear la comparación

La comparación que la gente busca es engañosa, porque los dos no compiten por el mismo trabajo. Un planteamiento más justo:

Criterio	JavaScript	WebAssembly
Velocidad pico en código numérico	Buena tras el calentamiento del JIT; puede desoptimizarse	Cercana a la nativa, estable desde la primera llamada
Acceso al DOM / Web APIs	Directo	Solo mediante imports JS
Coste de arranque	Parseo + compilación, incremental	Descarga + compilación del módulo completo
Modelo de memoria	Heap de objetos con garbage collection	Memoria lineal (manual o runtime del lenguaje); tipos GC disponibles para lenguajes con GC
SIMD	No (salvo mediante shaders WebGPU/WebGL)	Sí, SIMD de 128 bits
Threads	Web Workers con paso de mensajes	Workers + memoria compartida + atomics (requiere aislamiento cross-origin)
Depuración	Excelente	Buena con DWARF en DevTools de Chrome/Firefox, pero más débil que en JS
Habilidades del equipo	Cualquier equipo web	Requiere experiencia en Rust/C++/Go
Ideal para	UI, lógica de aplicación, orquestación de I/O	Hot paths, bibliotecas portadas, motores

Una regla práctica: si un profiler muestra una función consumiendo la mayor parte del tiempo de CPU, y opera sobre buffers en lugar de nodos del DOM, es candidata a Wasm. Si el perfil está repartido entre renderizado, layout y manejadores de eventos, Wasm no ayudará. Para la mitad de JavaScript, consulta TypeScript vs JavaScript.

Casos de uso reales de WebAssembly que están en producción

Estas son las categorías en las que Wasm ya está probado, no en fase experimental:

Procesamiento de imagen, vídeo y audio. Redimensionado en el cliente, filtros, eliminación de fondo y códecs (decodificadores AV1, Opus, JPEG XL) compilados desde C. FFmpeg compilado a Wasm transcodifica por completo en el navegador, así que el archivo del usuario nunca sale de su máquina.

CAD, 3D y geometría. Los kernels de geometría, las operaciones booleanas sobre mallas, la física y los parsers de archivos CAD son bases de código clásicas en C++. Compilan a Wasm y alimentan un renderizador WebGL o WebGPU. Nuestra guía sobre WebGL y Three.js para aplicaciones web 3D cubre la parte del renderizado; Wasm es lo que hace viable la matemática pesada que hay detrás.

Editores de diseño y documentos. Figma es el ejemplo conocido: un núcleo en C++ compilado a Wasm, UI en JavaScript, renderizado en la GPU. La misma arquitectura encaja en motores de hojas de cálculo, editores de PDF y herramientas de diagramas que necesitan un modelo de documento rápido y determinista.

Juegos y emuladores. Unity y Godot exportan a la web mediante Wasm; los emuladores y los ports de juegos están entre las cargas más antiguas de Wasm.

Ejecución de bibliotecas existentes en C/C++/Rust. SQLite, OpenCV, Tesseract OCR, zstd, libgit2 y muchas bibliotecas criptográficas tienen builds en Wasm. Suele ser el caso de negocio más sólido: sin reescritura, misma suite de tests, mismo comportamiento en todas partes.

Bases de datos y analítica en el navegador. SQLite compilado a Wasm (el build oficial, persistido mediante OPFS) da a las web apps una base de datos relacional real sin conexión. DuckDB-Wasm ejecuta SQL analítico sobre Parquet y CSV dentro de la pestaña, convirtiendo "sube tus datos para que nuestro servidor los grafique" en "grafícalos localmente".

Lenguajes y toolchains para WebAssembly

El lenguaje decide el tamaño del binario, la ergonomía de la interoperabilidad y cuánta plataforma puedes usar. Resumen a fecha de 2026:

Lenguaje / toolchain	Madurez	Tamaño típico del binario	Garbage collector	Ergonomía de interop con JS	Ideal para
Rust + wasm-bindgen / wasm-pack	Muy alta; el estándar de facto	Pequeño (decenas a cientos de KB)	Ninguno; modelo de ownership	Excelente: bindings tipados, web-sys/js-sys cubren las Web APIs	Módulos nuevos, bibliotecas críticas en rendimiento, herramientas
C / C++ + Emscripten	Muy alta; la toolchain más antigua	Pequeño a medio; crece con el uso de libc	Ninguno (manual)	Buena: embind, código de enlace generado, sistema de archivos virtual	Portar bibliotecas nativas existentes, códecs, motores
Go (compilador estándar)	Media; funciona, GC y runtime incluidos	Grande (varios MB)	Sí, incluido en el binario	Básica mediante syscall/js; llamadas más lentas	Reutilizar lógica de negocio en Go; no para hot paths
TinyGo	Media	Pequeño	GC mínimo	Básica	Módulos Go pequeños, plugins, targets WASI
C# / Blazor WebAssembly	Alta dentro del ecosistema .NET	Grande; el runtime se descarga (el trimming AOT ayuda)	Sí, GC de .NET	Gestionada por el framework; framework de UI completo	Equipos estandarizados en .NET que quieren SPA sin frameworks JS
AssemblyScript	Media; sintaxis similar a TypeScript	Pequeño	GC simple integrado	Simple pero limitada; no es un superconjunto de TypeScript	Equipos JS que escriben módulos de cálculo pequeños sin aprender Rust
Kotlin/Wasm	En crecimiento; depende de la propuesta Wasm GC	Medio; necesita navegadores con soporte de GC	Sí, usa el GC del navegador mediante Wasm GC	Mejorando; Compose Multiplatform lo tiene como target	Equipos Kotlin Multiplatform que comparten código con la web

Notas que importan al elegir:

• Rust es la opción más segura para código nuevo. wasm-bindgen genera bindings JavaScript tipados, wasm-pack produce un paquete listo para npm, y el ecosistema (serde para serialización, wasm-opt para reducir tamaño) es maduro. El coste es la curva de aprendizaje.
• Emscripten es la herramienta cuando el código ya existe en C o C++. Emula suficiente POSIX (archivos, pthreads, SDL, OpenGL mediante WebGL) como para que muchos proyectos compilen con pocos parches.
• Lenguajes con GC (Go, C#, Kotlin, Dart) históricamente incluían su propio garbage collector dentro del módulo, lo que infla el tamaño y duplica trabajo que el navegador ya hace. La propuesta Wasm GC cambia eso: los lenguajes ahora pueden asignar objetos gestionados por el recolector del motor. Kotlin/Wasm y Dart ya se apoyan en ella; es de esperar que otros la sigan. Si hoy necesitas un binario pequeño, Rust o C siguen siendo el camino.
• AssemblyScript se parece a TypeScript, pero no es TypeScript: sin any, sin union types, sin closures sobre el heap de JS.

WebAssembly fuera del navegador: WASI, edge, plugins

La segunda vida de Wasm es como formato ejecutable portable y aislado. Los ingredientes:

• WASI (WebAssembly System Interface) estandariza cómo un módulo accede a archivos, relojes, números aleatorios, variables de entorno y sockets. Se basa en capacidades: un módulo solo ve lo que el host le concede. Entre los runtimes están Wasmtime, Wasmer, WasmEdge y los integrados en plataformas cloud.
• Runtimes de edge. Cloudflare Workers, Fastly Compute y plataformas similares ejecutan módulos Wasm con cold starts medidos en milisegundos, y no en los segundos típicos de las funciones basadas en contenedores. El aislamiento es por módulo, no por VM, así que la densidad es mucho mayor. Es el mismo argumento que impulsa la computación serverless, con una unidad de despliegue más ligera.
• Plugins y puntos de extensión. Los productos que necesitan código aportado por el usuario — sistemas de CI, proxies como Envoy, bases de datos, funciones de "lógica personalizada" en SaaS — cargan cada vez más plugins en Wasm. El host obtiene un sandbox con capacidades explícitas y una ABI independiente del lenguaje; el autor puede usar Rust, Go, C o AssemblyScript. Frameworks como Extism empaquetan este patrón.
• Shells de escritorio. Algunas apps de escritorio integran un runtime Wasm para extensiones no confiables; si estás sopesando opciones de escritorio, consulta Electron vs Tauri vs nativo.

El component model y la propuesta de GC: dónde están las cosas en 2026

Dos propuestas marcan la siguiente fase. Ambas están en uso activo; ninguna está "terminada" en el sentido de que todos los runtimes y toolchains coincidan en cada detalle.

Wasm GC. Ya disponible en los principales motores de navegador. Añade structs y arrays tipados gestionados por el garbage collector del motor. El efecto es que los lenguajes con GC ya no necesitan incluir su propio recolector, lo que reduce los binarios y mejora la interoperabilidad con objetos JavaScript. Kotlin/Wasm, Dart/Flutter web y las iniciativas Java-a-Wasm dependen de ello. Rust y C no lo usan y no lo necesitan.

Component model y las versiones preview de WASI. El component model define cómo los módulos Wasm exponen y consumen interfaces tipadas (descritas en el lenguaje de interfaces WIT), de modo que un componente en Rust pueda llamar a un componente en Go sin código de enlace escrito a mano. Las versiones más recientes de WASI se construyen sobre él. Las herramientas (wasm-tools, cargo component, wit-bindgen) son utilizables y van mejorando; los navegadores todavía no ejecutan componentes de forma nativa, así que en el navegador sigues empaquetando mediante un polyfill del lado de JavaScript o te quedas en los módulos core con wasm-bindgen.

Consejo: en el navegador, construye hoy sobre Wasm core más wasm-bindgen o Emscripten. En el servidor y para plugins, apuesta por el component model, pero fija las versiones de runtime y herramientas, porque las interfaces todavía cambian entre releases.

Metodología de rendimiento: mide antes y después

La mayoría de los proyectos Wasm decepcionantes se saltaron esto.

1. Perfila primero. Usa el panel Performance del navegador o un sampling profiler para encontrar la función caliente real. Si ninguna función domina, para: Wasm no es la solución.
2. Aísla el kernel. Extrae el hot path a una función pura que recibe buffers y devuelve buffers. Esa es la función que vas a portar. Mantén la UI y el I/O en JavaScript.
3. Diseña la frontera. Pasa vistas Float32Array/Uint8Array sobre la memoria lineal, no arrays de objetos. Llama una vez por frame o por lote, no una vez por elemento. Las strings cuestan una codificación/decodificación en cada sentido; evítalas en bucles calientes.
4. Activa SIMD. Rust: RUSTFLAGS="-C target-feature=+simd128" y los intrínsecos de std::arch::wasm32 o autovectorización. Emscripten: -msimd128. Verifica que la salida compilada realmente se vectorizó; la autovectorización no está garantizada.
5. Threads cuando los datos son grandes. Los threads en Wasm usan Web Workers sobre memoria compartida y atomics. Requieren cabeceras de aislamiento cross-origin (Cross-Origin-Opener-Policy y Cross-Origin-Embedder-Policy), que pueden romper embeds de terceros. Confirma que tu despliegue puede establecer esas cabeceras antes de diseñar en torno a threads.
6. Gestiona la memoria explícitamente. La memoria lineal crece, pero no se reduce. Reutiliza buffers, usa asignadores de arena para el trabajo por frame y limita el crecimiento. Un módulo Wasm con fugas de memoria en una pestaña de larga duración es una sorpresa habitual en producción.
7. Optimiza el binario. Ejecuta wasm-opt -O3 (o -Oz para tamaño) de Binaryen, elimina la información de depuración en producción, sirve con Brotli y carga con WebAssembly.instantiateStreaming para que la compilación se solape con la descarga.
8. Compara con JavaScript optimizado. Compara con una implementación en JS calentada y basada en typed arrays. Si la ganancia es inferior a aproximadamente 2x, cuestiona si la toolchain adicional merece la pena.
9. Mide en campo. Publica detrás de una feature flag con fallback en JavaScript y compara tiempos y tasas de error de usuarios reales.

Un ejemplo mínimo de Rust a Wasm

Instala el target y wasm-pack (la guía oficial de wasm-bindgen en rustwasm.github.io tiene los detalles) y después:

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

Cargo.toml necesita el crate type cdylib:

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

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

La biblioteca opera in-place sobre un buffer RGBA, lo que evita copiar píxeles a través de la frontera:

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;
    }
}

Compila y llama desde 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);           // una llamada, el buffer completo
ctx.putImageData(image, 0, 0);

Lo que hace esto rápido: un cruce de frontera por frame, un typed array de entrada y de salida, sin strings, sin objetos. Llamada por píxel desde JavaScript, la misma función perdería frente a un bucle JS simple.

Checklist de decisión: ¿esta carga de trabajo debería usar WebAssembly?

Responde sí a la mayoría de estos puntos antes de comprometerte:

• Un profiler muestra una o pocas funciones limitadas por CPU dominando la carga.
• Esas funciones operan sobre buffers, números o texto grande, no sobre nodos del DOM.
• El trabajo puede agruparse en lotes para que la frontera JS↔Wasm se cruce rara vez.
• Tienes una biblioteca existente en C/C++/Rust para reutilizar, o un equipo cómodo con Rust o C++.
• El tamaño del binario es aceptable para tus usuarios tras wasm-opt y Brotli, y el módulo puede cargarse bajo demanda fuera de la ruta crítica.
• El trabajo se beneficia de SIMD o multihilo, y puedes establecer cabeceras de aislamiento cross-origin si necesitas threads.
• Puedes mantener un fallback en JavaScript o una feature flag durante el rollout.
• La depuración con DWARF en DevTools es aceptable, y el CI cubre el módulo en Node y en un navegador headless.

Elige JavaScript puro (o TypeScript) cuando:

• El cuello de botella es el renderizado, el layout, la red o la gestión de estado.
• La lógica es corta, con muchas asignaciones o ligada al DOM.
• El equipo no tiene experiencia con lenguajes de sistemas y la ganancia sería marginal.

Elige Wasm fuera del navegador (WASI, edge, plugins) cuando:

• Necesitas ejecutar código no confiable o de terceros con capacidades granulares.
• El tiempo de cold start y la densidad importan más que el throughput pico bruto.
• Quieres un único artefacto que se ejecute de forma idéntica en Linux, macOS, Windows y hosts de edge.

Recomendación

Trata WebAssembly como una herramienta de precisión, no como una migración de plataforma. Mantén la UI, el enrutamiento y la obtención de datos en JavaScript. Pon Wasm donde apunte el profiler: códecs, geometría, parsing, analítica y bibliotecas nativas existentes que de otro modo reescribirías. Usa Rust con wasm-bindgen para módulos nuevos y Emscripten para código C/C++ portado; evita las toolchains de lenguajes con GC en hot paths hasta que el soporte de Wasm GC sea algo verificado en tus navegadores objetivo. Diseña la frontera en torno a buffers y lotes, activa SIMD, ejecuta wasm-opt y compara con JavaScript optimizado antes de publicar. En el servidor y en el edge, WASI y el component model merecen adoptarse para plugins y funciones aisladas, con versiones fijadas mientras los estándares se asientan. En Arvucore solemos recomendar empezar con un único kernel aislado detrás de una feature flag, medir el impacto en usuarios reales durante dos ciclos de release y ampliar solo cuando los números justifiquen la toolchain adicional.