Flutter Web con WebAssembly en 2026: qué cambia con skwasm (y cuándo NO conviene)
Desde 2026, cuando compilas una app Flutter para web con flutter build web --wasm, el motor de render por defecto pasa a ser skwasm (Skia compilado a WebAssembly con WasmGC), con fallback automático a CanvasKit/JavaScript en los navegadores que no lo soportan. En la práctica esto significa arranque más rápido, render multihilo y un rendimiento gráfico 2-3× superior al objetivo JavaScript. Pero no es gratis: hay requisitos de cabeceras HTTP, incompatibilidades de navegador y migraciones de dependencias que conviene entender antes de decidir.
En Dribba llevamos desde 2011 construyendo apps con Flutter —somos Flutter Partner oficial de Google desde 2017, la única agencia española en el directorio— y este artículo resume lo que de verdad cambia para tu proyecto, sin hype.
Qué es skwasm y por qué importa
skwasm es el renderizador de Flutter Web basado en WebAssembly. A diferencia de CanvasKit (que ejecuta Skia compilado a Wasm pero orquestado desde JavaScript), skwasm compila tu código Dart a WebAssembly mediante dart2wasm y aprovecha WasmGC (la extensión de recolección de basura de WebAssembly). El resultado:
- Arranque más rápido: no hay que interpretar ni compilar JIT el bundle JS.
- Render fuera del hilo principal: skwasm puede pintar en workers dedicados, repartiendo el trabajo entre varios núcleos y reduciendo el jank en animaciones e interacciones pesadas.
- Tamaño contenido: skwasm embebe una versión más compacta de Skia (~1,1 MB) frente a los ~1,5 MB de CanvasKit.
La clave es el modelo de ejecución: skwasm acerca el rendimiento de Flutter Web al de una app nativa, especialmente en interfaces con mucho movimiento, canvas, gráficos o listas complejas.
CanvasKit vs skwasm: tabla comparativa
| Criterio | CanvasKit (JS) | skwasm (Wasm) |
|---|---|---|
| Compilación de Dart | a JavaScript | a WebAssembly (dart2wasm + WasmGC) |
| Rendimiento gráfico | base | 2-3× sobre JS |
| Render multihilo | limitado | sí, con workers (requiere COOP/COEP) |
| Tamaño extra del motor | ~1,5 MB | ~1,1 MB |
| Soporte de navegadores | universal | requiere WasmGC |
Interop JS legado (dart:html) | compatible | incompatible (usa package:web) |
| Navegadores iOS | sí | no (WebKit sin WasmGC operativo) |
No es una elección binaria: al construir con --wasm, Flutter genera ambos objetivos y sirve skwasm donde se soporta y CanvasKit/JS donde no. El fallback es transparente para el usuario final.
Requisitos reales antes de activarlo
1. Cabeceras HTTP para multihilo
El render multihilo de skwasm necesita un contexto cross-origin isolated. Tu servidor (o CDN) debe enviar:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp (o credentialless)
Sin estas cabeceras, la app funciona, pero en modo monohilo: pierdes buena parte de la ventaja de rendimiento. Y require-corp obliga a que todos los recursos de terceros (fuentes, imágenes, iframes, analítica) lleguen con CORS correcto o un encabezado CORP, lo que en webs con muchos embeds externos no es trivial.
2. Migración de dependencias
Wasm rompe con las APIs antiguas de interop con JavaScript. Si tu código o tus paquetes usan:
dart:html→ migra apackage:webpackage:jsodart:js→ migra adart:js_interop
El bloqueante habitual no es tu código, sino una dependencia transitiva que aún no se ha actualizado. Auditar el árbol de paquetes es el primer paso real de cualquier migración a Wasm.
3. Detección en tiempo de ejecución
Si necesitas ramificar lógica según el motor:
const bool isWasm = bool.fromEnvironment('dart.tool.dart2wasm');
if (isWasm) {
// ruta optimizada para Wasm
}
El estado del soporte de navegadores en 2026
Este es el matiz más importante y el que más confusión genera. A mediados de 2026, más del 90% del uso global de navegadores ya soporta WasmGC, pero el detalle fino sigue importando:
- Chrome / Edge (Chromium 119+): soporte completo y estable. Es el escenario ideal para skwasm.
- Firefox: ya implementa WasmGC de forma estable, aunque Flutter aún documenta limitaciones puntuales con el renderizador Wasm. Conviene probar tu app concreta, no asumir.
- Safari (18+, macOS Sequoia): incorporó WasmGC, pero ha arrastrado incompatibilidades con el renderizador de Flutter similares a las de Firefox. Verifica en tu versión objetivo.
- iOS (cualquier navegador): no soportado. Todos los navegadores en iOS están obligados a usar WebKit, así que Chrome o Firefox en iPhone tampoco ejecutan el objetivo Wasm. Aquí siempre cae al fallback JS.
La buena noticia: gracias al fallback automático, ningún usuario se queda fuera. La mala: si tu audiencia es mayoritariamente iOS o Safari, la inversión en migrar a Wasm rinde mucho menos de lo que sugieren los benchmarks.
Cuándo NO usar Wasm (todavía)
Ser honestos sobre los límites es parte de cómo trabajamos. Hoy no recomendamos priorizar skwasm si:
- Tu tráfico es mayoritariamente iOS/Safari: la mayoría de usuarios recibirá el objetivo JS de todas formas, así que el coste de migración no se traduce en rendimiento percibido.
- Dependes de paquetes con
dart:html/package:jssin actualizar: el esfuerzo de migración o sustitución puede superar el beneficio a corto plazo. - No controlas las cabeceras del servidor/CDN: sin COOP/COEP no hay multihilo, y entonces la ventaja se diluye.
- Integras muchos recursos de terceros sin CORP/CORS:
require-corppuede romper embeds, fuentes externas o widgets de analítica. - Tu web es de contenido y poco interactiva: si no hay animaciones pesadas ni canvas, el render JS ya es suficiente y la migración no compensa.
Donde sí brilla: dashboards interactivos, editores visuales, herramientas internas en entornos Chromium controlados, y apps con gráficos o animación intensiva donde puedes garantizar las cabeceras.
Cómo lo abordamos en un proyecto real
Nuestro flujo cuando un cliente plantea Wasm:
- Auditoría de dependencias: ¿todo el árbol es compatible con
package:webydart:js_interop? - Análisis de audiencia: % de tráfico Chromium vs iOS/Safari a partir de datos reales de analítica.
- Infraestructura: ¿podemos servir COOP/COEP en el CDN sin romper terceros?
- Build dual y medición:
flutter build web --wasm, y comparamos métricas reales (Web Vitals, tiempo a interactivo, jank) entre objetivos antes de decidir. - Decisión basada en datos, no en la moda del framework.
Este enfoque conecta con cómo medimos rendimiento en móvil —ver nuestra guía de observabilidad en apps móviles— y con la misma filosofía de arquitectura limpia que aplicamos en mobile.
Conclusión
WebAssembly convierte a Flutter Web en una opción seria para aplicaciones web interactivas y exigentes en 2026: 2-3× de rendimiento, render multihilo y fallback transparente. Pero no es un interruptor mágico. El soporte de navegadores fuera de Chromium aún tiene matices, iOS queda fuera del objetivo Wasm, y necesitas controlar cabeceras y dependencias. La decisión correcta nace de tus datos de audiencia e infraestructura, no del titular.
Si estás valorando llevar tu producto Flutter a web —o decidir entre Wasm, CanvasKit o un enfoque híbrido— en Dribba llevamos más de 300 proyectos ayudando a equipos a tomar estas decisiones con criterio técnico y sin humo. Hablamos.
