JetStream 3: El Benchmark de Rendimiento Web 2026
JetStream 3 es el nuevo estándar de benchmarking web lanzado por Google, Apple y Mozilla en marzo 2026, después de 6 años sin actualizaciones desde JetStream 2. El benchmark duplica el enfoque en WebAssembly, introduce 12 nuevos workloads y soporta 5 nuevas toolchains (J2CL, Dart2wasm, Kotlin/Wasm, Rust, .NET), permitiendo a desarrolladores medir rendimiento en aplicaciones web de computación intensiva con mayor precisión que nunca.
En 30 segundos
- JetStream 3 expande WebAssembly de 7% a 15-20% del test, midiendo criptografía, ML y operaciones de base de datos en Wasm
- Nuevo modelo de governance consensuado entre Google, Apple y Mozilla para evitar sesgos de navegadores individuales
- 12 nuevos workloads y soporte para 5 toolchains modernos reflejan cómo se escribe código real en 2026
- Accesible en browserbench.org, con versión preview en webkit-jetstream-preview.netlify.app y código abierto en GitHub
- Enfocado en rendimiento computacional intensivo, complementa Speedometer 3 (que mide UI rendering)
Qué es JetStream 3: el nuevo estándar de benchmarking web
JetStream 3 es el benchmark de referencia para medir rendimiento en aplicaciones web modernas con alta demanda computacional. Creado colaborativamente por Google, Apple y Mozilla, representa la primera actualización mayor en seis años desde JetStream 2.
La razón del lanzamiento ahora es obvia: el desarrollo web cambió. En 2020, cuando salió JetStream 2, WebAssembly era algo experimental. Hoy, Wasm es fundamental para aplicaciones reales: bases de datos en el navegador, procesamiento de criptografía, machine learning en el cliente. JetStream 3 refleja esa realidad (si no medís lo que importa, el benchmark es al pedo).
Según el anuncio oficial de Apple WebKit, el nuevo benchmark introduce un modelo de governance completamente distinto: las decisiones sobre qué incluir se toman por consenso entre los tres navegadores, no a criterio de uno solo. Eso zafa de los sesgos que siempre tuvo cualquier benchmark controlado por una única empresa.
Principales cambios: de JetStream 2 a JetStream 3
La escalada en WebAssembly es lo más evidente. En JetStream 2, Wasm representaba el 7% de las pruebas. En JetStream 3, trepa a 15-20%, reconociendo que escribir código compilado a WebAssembly no es más un hobby de investigadores, es la forma que elegís para cosas que tienen que andar rápido.
JetStream 3 incorpora 12 nuevos workloads (más del doble del original), abarcando escenarios que no existían hace años: hash criptográfico en Wasm, modelos ML en el navegador, operaciones de base de datos, parsing de datos de alto volumen. Eso sí, no fue un tema de “hagamos 12 cosas random”. Cada workload responde a un caso de uso real que ya está corriendo en producción en algún lado.
La novedad técnica grande es el soporte para 5 nuevas toolchains de compilación a WebAssembly.
- J2CL: compila Java a JavaScript/WebAssembly. Util para equipos Java que quieren portabilidad total
- Dart2wasm: Google está apostando fuerte a Dart en web y mobile, así que necesitaba que compilara a Wasm con todo el jugo
- Kotlin/Wasm: lenguaje JVM que JetBrains promociona para desarrollo multiplataforma. Ahora podés compilar a Wasm directo
- Rust a WebAssembly: la toolchain de Rust para Wasm ya estaba, pero JetStream 3 la trata como citizen de primera clase
- .NET a WebAssembly: Microsoft agregó compilación nativa a Wasm en .NET 8, y acá está reflejado
La idea es que no importa con qué lenguaje escribas tu código backend o servidor, si querés llevarlo al cliente compilando a WebAssembly, JetStream 3 te mide. Ya lo cubrimos antes en técnicas avanzadas de optimización de código.
WebAssembly: el corazón de la actualización
El enfoque en WebAssembly no es casual. En los últimos 3 años, Wasm se volvió genuinamente útil en navegadores, pasó de “futuro prometedor” a “herramienta productiva”.
Las nuevas características de WebAssembly que JetStream 3 ahora mide incluyen SIMD (Single Instruction Multiple Data, para paralelismo vectorial), WasmGC (garbage collection nativo en Wasm para lenguajes con managed memory), y exception handling (manejo de excepciones dentro de Wasm). Acá viene lo bueno: anteriormente tenías que exportar todo a JavaScript para manejar excepciones. Ahora lo hacés en Wasm. El overhead desaparece.
Un ejemplo concreto: si necesitás hacer criptografía fuerte en el navegador (cifrado end-to-end), hacerlo en JavaScript es lento y expone datos en memoria a más gente. Compilar a Wasm, especialmente con SIMD para operaciones en paralelo, te da velocidad cercana al código nativo en C. JetStream 3 mide exactamente eso.
Otro caso real: bases de datos que corren en el navegador (tipo SQLite.js, DuckDB WASM). Con las nuevas features de Wasm, la performance sube considerablemente. Estos benchmarks están en JetStream 3 porque es lo que devs realmente están haciendo en 2026.
Workloads de JavaScript en JetStream 3
No todo es WebAssembly. Las pruebas de JavaScript siguen siendo la mayoría (porque JavaScript sigue siendo la lengua franca del navegador), pero reflejan el estado actual de la plataforma.
Entre los workloads está startup performance: cuánto tarda tu app en arrancar, parsear el JS, iniciar frameworks. JetStream 3 lo mide con aplicaciones reales: Babylon.js 3D engine (rendering 3D complejo), TypeScript v5.9 compilation in-browser (parsing y compilación de código), async pattern stress tests (cómo maneja el navegador promesas y parámetros async/await en cantidad).
Babylon.js es interesante porque mete un motor 3D completo, renderizado, y miles de entidades en movimiento. El benchmark mide cuánto tarda en cargar y renderizar el primer frame. Con WebGL y WebGPU siendo cada vez más prevalentes, tener eso en los tests es sensato. Sobre eso hablamos en modelos IA para análisis de resultados.
TypeScript compilation in-browser parece niche, pero no tanto. Hay herramientas como CodeSandbox, StackBlitz y otras que compilan TypeScript/Babel/JSX directo en el navegador. El usuario tipea código y ve el resultado sin tocar un servidor. JetStream 3 lo mide.
Cómo funciona JetStream 3: componentes y metodología
El diseño de JetStream 3 balancea microbenchmarks (pruebas de una cosa específica, muy controladas) y aplicaciones reales (messy, complejas, con distracciones). Fijate que ese balance es el truco. Un benchmark solo de microbenchmarks es irrelevante (podés optimizar para el test pero no para la vida real). Uno solo de apps reales es impredecible (hay 50 variables que no podés controlar).
Los criterios de diseño fueron: diversidad de frameworks y lenguajes (no favorecer a uno), limitaciones prácticas (los tests tienen que correr en menos de 20 minutos, senó nadie los corre), y determinismo (vos corrés el benchmark dos veces, deberías obtener el mismo score, no variance wild).
El score final es la media geométrica de todos los workloads, no la aritmética. ¿Por qué? Porque si usás media aritmética, un test que sea 10x más lento que los demás domina todo el resultado. Media geométrica lo nivela.
Acceso y ejecución: cómo usar JetStream 3
Podés correr JetStream 3 directamente en browserbench.org/JetStream. Entrás, le das play, y arranca. Tarda entre 10 y 20 minutos dependiendo de tu hardware. Al final, ves el score y breakdown por categoría (JavaScript, WebAssembly, etc).
Si querés explorar antes de hacer la versión oficial, hay una preview en webkit-jetstream-preview.netlify.app donde Apple y WebKit publican iteraciones tempranas.
Además, todo el código está open source en GitHub WebKit/JetStream. Podés bajarte los tests, correrlos localmente, modificarlos para tu caso de uso específico. Si trabajás en un navegador o engine, probablemente querés correr los tests en tu propia máquina con control total sobre qué se mide.
También hay shell runners para automatizar, parsear resultados, correr en CI/CD. Si tu equipo de engine quiere trackear performance a lo largo del tiempo, pueden integrar JetStream 3 en el pipeline de testing.
JetStream 3 vs otros benchmarks: Speedometer, V8, y el ecosistema
JetStream 3 no es el único benchmark web, pero tiene un nicho específico.
| Benchmark | Enfoque | Cuándo usarlo |
|---|---|---|
| JetStream 3 | Rendimiento computacional intensivo (Wasm, criptografía, ML) | Apps con mucho cálculo, backends en el navegador, compilación en el cliente |
| Speedometer 3 | Rendering UI, manipulación DOM, frameworks modernos | Apps CRUD típicas, dashboards, sitios interactivos |
| V8 Benchmark Suite | Performance del engine JavaScript puro | Teams de navegadores y JS engines |
| WebXPRT | Batería completa: Wasm, web APIs, gráficos | Evaluación general de rendimiento del navegador |
Speedometer 3 es el más cercano en filosofía. Mide cosas como adding rows a una tabla, eliminando items, escribiendo text en inputs. Es lo que hace la mayoría de las web apps: mucho JavaScript interactuando con el DOM. JetStream 3 casi no toca el DOM. Es más: criptografía, compilación, transformaciones de datos, machine learning. Lo explicamos a fondo en herramientas modernas para desarrollo.
Si tu app es un dashboard con charts y forms, Speedometer 3 te dice más que JetStream 3. Si tu app es un editor de video en el navegador, un IDE en la nube, o una base de datos SQLite compilada a Wasm, JetStream 3 es lo tuyo.
Errores comunes al interpretar JetStream 3
Error 1: “Mi navegador tiene score 10000, así que es 10x más rápido que otro con 1000”. No funciona así. Los scores de diferentes benchmarks no son comparables de forma lineal. Un navegador con 1.5x el score probablemente sea un 20-30% más rápido en promedio, no 50%. El score es referencial.
Error 2: “Optimizé para JetStream 3 y ahora todo anda re lento”. Es posible. Un benchmark mide lo que mide. Si optimizás solo para pasar el test ignorando casos reales, metés tu app en un rincón. Optimizá para tus usuarios, usá JetStream 3 como parte del feedback, no como el único termómetro.
Error 3: “WebAssembly en JetStream 3 representa el 20%, así que Wasm representa el 20% del desarrollo web real”. Falso. JetStream 3 le da peso a Wasm porque es donde el benchmark agrega más valor diferenciador. En la web real, hoy la mayoría del código sigue siendo JavaScript. Wasm es estratégico pero minoritario en volumen.
Preguntas Frecuentes
¿Qué es JetStream 3 y para qué sirve?
JetStream 3 es un benchmark estándar que mide el rendimiento de navegadores web en tareas computacionalmente intensivas: WebAssembly, criptografía, ML, bases de datos. Sirve para desarrolladores que necesitan saber qué navegador es más rápido para sus apps específicas, y para equipos de navegadores que trackean performance en el tiempo.
¿Cuáles son las principales novedades en JetStream 3 comparado con JetStream 2?
Duplicó el peso de WebAssembly (de 7% a 15-20%), agregó 12 nuevos workloads que reflejan desarrollo real en 2026, y sumó soporte para 5 nuevas toolchains de compilación a Wasm (Kotlin, Dart, Java, Rust, .NET). Además cambió el governance: decisiones por consenso entre Google, Apple y Mozilla en lugar de control de una sola empresa. Esto se conecta con lo que analizamos en plataformas colaborativas para desarrolladores.
¿Cómo mido el rendimiento de mi aplicación web con JetStream 3?
Entrás a browserbench.org/JetStream, clickeás “Run”, y esperás 10-20 minutos. Al final obtenés un score general y desglose por categoría. Si querés integrar en CI/CD, bajás el código del GitHub y lo ejecutás localmente con los shell runners.
¿Por qué WebAssembly es tan importante en JetStream 3?
Porque en 2024-2026 Wasm pasó de ser experimental a productivo. Ahora hay bases de datos reales en Wasm, ML inference en el cliente, criptografía fuerte. JetStream 3 las mide porque son workloads reales que devs ejecutan hoy.
¿Cuál es la diferencia entre JetStream 3 y Speedometer 3?
JetStream 3 mide cálculo intensivo y WebAssembly. Speedometer 3 mide interacción UI y DOM manipulation. Usá JetStream 3 si tu app es backend-heavy en el navegador (bases de datos, ML, criptografía). Usá Speedometer 3 si tu app es CRUD y formularios típicos.
Conclusión
JetStream 3 es el snapshot más actualizado de lo que importa en performance web en 2026. Después de 6 años, Google, Apple y Mozilla finalmente reconocieron que WebAssembly no es experimental, que la compilación desde múltiples lenguajes a Wasm es real, y que el desarrollo web moderno necesita medir cosas que antes no existían.
El cambio de governance hacia consenso es tan importante como los benchmarks nuevos. Un benchmark controladosolamente por un navegador siempre tiene sesgos implícitos. Este, con tres cabezas pensando, tiene más chances de ser justo (ojo, no perfecto, pero mejor).
Si trabajás en performance de navegadores o en apps que corren JavaScript/Wasm intensivo, JetStream 3 es obligatorio. Si tu app es típica (forms, listas, dashboards), Speedometer 3 sigue siendo tu mejor indicador. Lo ideal: corrés ambos, ves en qué sos fuerte y dónde tenés margen.
Fuentes
- Google Chromium Blog – JetStream 3: A modern benchmark for high-performance, compute-intensive Web apps
- Apple WebKit – Introducing the JetStream 3 Benchmark Suite
- GitHub WebKit/JetStream – Código fuente oficial de JetStream 3
- BrowserBench.org – JetStream 3 online runner
- WebKit JetStream Preview – Versión preview y experimental
