# Rendimiento de Vue 3 en 2026: Vapor Mode, Alien Signals y el fin del Virtual DOM

> Análisis a fondo del rendimiento del Vapor Mode de Vue 3.6: cómo elimina el Virtual DOM, el sistema de reactividad Alien Signals, benchmarks frente a Solid.js y técnicas prácticas de optimización para producción.

- Published: 2026-06-02
- Updated: 2026-06-06
- Author: SharpSkill
- Tags: vue, vue-3, vapor-mode, performance, virtual-dom, alien-signals, reactivity
- Reading time: 10 min

---

El Vapor Mode de Vue 3.6 representa el cambio de arquitectura de renderizado más importante desde que Vue adoptó el Virtual DOM en su versión 2. Al compilar los Single File Components directamente en operaciones imperativas del DOM, el Vapor Mode elimina el sobrecosto del diffing que ha definido la canalización de renderizado de Vue durante años. Combinado con la reescritura del sistema de reactividad Alien Signals, Vue 3.6 alcanza la paridad en benchmarks con Solid.js y Svelte 5, sin obligar a los desarrolladores a aprender una nueva API.

> **Vapor Mode en un vistazo**
>
> El Vapor Mode es una estrategia de compilación opcional en Vue 3.6 que evita por completo el Virtual DOM. Los componentes compilados en Vapor Mode conectan cada dependencia reactiva directamente con el nodo del DOM exacto que afecta, lo que produce actualizaciones quirúrgicas sin recorrer ningún árbol. Se activa con un solo atributo: `<script setup vapor>`.

## Cómo funciona el Virtual DOM de Vue: por qué se convirtió en un cuello de botella

El patrón Virtual DOM (VDOM), popularizado por React y adoptado por Vue 2, crea una representación ligera en JavaScript del árbol real del DOM. En cada cambio de estado, Vue genera un nuevo árbol VDOM, lo compara con el anterior y aplica al DOM real solo los nodos que cambiaron.

Este enfoque funciona bien para la mayoría de las aplicaciones. El algoritmo de diffing se ejecuta en tiempo O(n) y el compilador de Vue ya excluye los subárboles estáticos de la ruta de comparación. Pero el sobrecosto se acumula en escenarios específicos:

- **Las listas grandes** con cientos de filas disparan comparaciones completas de subárboles en cada actualización
- **Los cambios de estado frecuentes** (animaciones, datos en tiempo real) generan una rotación de VDOM que el recolector de basura debe limpiar
- **Los árboles de componentes profundos** multiplican el costo del recorrido del árbol y de la generación de parches

El compilador de plantillas de Vue 3 introdujo varias optimizaciones del VDOM (hoisting estático, patch flags, block trees) que redujeron el trabajo innecesario. Aportaron mejoras medibles, pero la arquitectura fundamental seguía exigiendo generar, comparar y desechar objetos de JavaScript en cada ciclo de renderizado.

## Vue 3.6 Vapor Mode: compilar para eliminar el Virtual DOM

El Vapor Mode adopta un enfoque radicalmente distinto. En lugar de compilar las plantillas en funciones de renderizado que devuelven nodos VDOM, el compilador Vapor genera código que crea y actualiza directamente los elementos del DOM. Cada enlace reactivo se corresponde con una mutación concreta del DOM, sin ninguna representación intermedia.

Así se compila de forma diferente un componente Vue estándar según el modo:

```vue
<!-- Counter.vue -->
<script setup vapor>
import { ref } from 'vue'

const count = ref(0)
const increment = () => count.value++
</script>

<template>
  <button @click="increment">
    Count: {{ count }}
  </button>
</template>
```

En el modo VDOM clásico, esta plantilla se compila en una función de renderizado que devuelve un árbol de nodos virtuales. En cada clic, Vue crea un nuevo árbol VDOM, lo compara con el anterior, detecta que cambió el contenido del texto y aplica el parche al DOM real.

En Vapor Mode, el compilador genera algo más parecido a esto:

```javascript
// Salida de compilación Vapor (simplificada)
const button = document.createElement('button')
const text = document.createTextNode('Count: 0')
button.appendChild(text)

// Enlace directo: fuente reactiva -> mutación del DOM
effect(() => {
  text.nodeValue = `Count: ${count.value}`
})

button.addEventListener('click', increment)
```

El efecto reactivo conecta `count` directamente con `text.nodeValue`. Sin creación de VDOM, sin diffing, sin parcheo. El cambio de estado dispara exactamente una mutación del DOM.

### Activar el Vapor Mode en un proyecto

El Vapor Mode opera a nivel de componente. Existen dos estrategias de integración:

```javascript
// vaporApp.js — Aplicación 100 % Vapor (sin runtime de VDOM)
import { createVaporApp } from 'vue'
import App from './App.vue'

createVaporApp(App).mount('#app')
```

```javascript
// hybridApp.js — Componentes VDOM + Vapor mezclados
import { createApp, vaporInteropPlugin } from 'vue'
import App from './App.vue'

createApp(App)
  .use(vaporInteropPlugin)
  .mount('#app')
```

El enfoque híbrido permite una migración gradual. Los componentes críticos en rendimiento, tablas de datos, paneles en tiempo real, vistas con muchas animaciones, pueden adoptar Vapor mientras el resto de la aplicación sigue usando el runtime estándar de VDOM. Ambos tipos de componentes conviven en el mismo árbol.

> **Limitaciones del Vapor Mode en Vue 3.6**
>
> El Vapor Mode requiere la Composition API con `<script setup>`. La Options API, `app.config.globalProperties`, `getCurrentInstance()` y los eventos del ciclo de vida por elemento (`@vue:mounted`, etc.) no son compatibles. Las directivas personalizadas usan una interfaz diferente que acepta getters reactivos en lugar de objetos de binding. Suspense funciona cuando envuelve componentes Vapor dentro de un padre VDOM, pero no en aplicaciones 100 % Vapor.

## Alien Signals: el nuevo motor de reactividad de Vue

Vue 3.6 incorpora un segundo cambio importante junto al Vapor Mode: una reescritura completa de `@vue/reactivity` basada en la biblioteca [Alien Signals](https://github.com/stackblitz/alien-signals). Creada por Johnson Chu, Alien Signals implementa un algoritmo de reactividad push-pull que reduce tanto la asignación de memoria como el costo de cómputo.

El modelo push-pull funciona en dos fases:

1. **Fase push**: cuando un signal (fuente reactiva) cambia, propaga una bandera «dirty» a todas las propiedades computadas dependientes. Este recorrido es barato: solo alterna banderas booleanas sin ejecutar ningún cálculo.
2. **Fase pull**: cuando se lee una propiedad computada, esta verifica su bandera dirty. Si está dirty, recalcula. Si está limpia, devuelve de inmediato el valor en caché.

Este diseño elimina los recálculos innecesarios. En el sistema de reactividad de Vue 3.5, una propiedad computada que dependía de tres signals se recalculaba cada vez que cambiaba cualquiera de ellos, aunque el resultado siguiera siendo el mismo. Alien Signals solo recalcula cuando el valor se lee realmente y al menos una dependencia ha cambiado.

```typescript
// reactivityComparison.ts
import { ref, computed, watch } from 'vue'

const firstName = ref('Jane')
const lastName = ref('Doe')
const isActive = ref(true)

// Este computed solo recalcula cuando se lee Y está dirty
const displayName = computed(() => {
  return isActive.value
    ? `${firstName.value} ${lastName.value}`
    : 'Inactive User'
})

// Cambiar isActive marca displayName como dirty
// Pero no se ejecuta ningún cálculo hasta que algo lee displayName.value
isActive.value = false

// AHORA ocurre el recálculo
console.log(displayName.value) // 'Inactive User'
```

La estructura de datos interna también cambió. Alien Signals reemplaza el rastreo de dependencias basado en `Set` por listas doblemente enlazadas, lo que reduce la memoria por dependencia reactiva y mejora la velocidad de recorrido durante la limpieza.

### Resultados de los benchmarks: Alien Signals en la práctica

Las cifras de los benchmarks de la beta de Vue 3.6 muestran mejoras consistentes frente a Vue 3.5:

| Métrica | Vue 3.5 | Vue 3.6 (Alien Signals) | Mejora |
|---|---|---|---|
| Memoria por ref reactiva | Base | -14 % | Menor asignación |
| Recálculo de computed | Base | -20 % de media | Menos ejecuciones innecesarias |
| Montaje de componentes (100k) | ~300 ms | ~100 ms | 3x más rápido |
| First Contentful Paint | Base | 0,7 s habitual | Menor sobrecosto del framework |
| Tamaño del bundle base | ~16 KB | &lt;10 KB | -37 % |

Estas ganancias se aplican automáticamente a todas las aplicaciones Vue 3.6. A diferencia del Vapor Mode, que requiere activarse por componente, el sistema de reactividad Alien Signals viene activado de forma predeterminada en Vue 3.6.

## Técnicas prácticas de optimización del rendimiento en Vue 3

El Vapor Mode y Alien Signals atacan el sobrecosto del framework, pero el rendimiento a nivel de aplicación sigue dependiendo de cómo se estructuran los componentes. Estas técnicas aplican tanto a componentes VDOM como Vapor.

### Reactividad superficial para grandes estructuras de datos

La reactividad profunda envuelve cada propiedad anidada en un Proxy. Para grandes conjuntos de datos, respuestas de API, objetos de configuración, estado en caché, esto crea miles de envoltorios Proxy innecesarios. `shallowRef` y `shallowReactive` limitan la reactividad a la referencia de nivel superior.

```typescript
// shallowReactivity.ts
import { shallowRef, triggerRef } from 'vue'

interface Product {
  id: number
  name: string
  variants: { sku: string; price: number }[]
}

// Solo la propia ref es reactiva, no las propiedades anidadas
const products = shallowRef<Product[]>([])

// Obtención de datos: asignar el nuevo arreglo dispara la reactividad
async function fetchProducts() {
  const response = await fetch('/api/products')
  products.value = await response.json() // dispara la actualización
}

// Mutación de datos anidados: hay que disparar manualmente
function updatePrice(productId: number, sku: string, newPrice: number) {
  const product = products.value.find(p => p.id === productId)
  const variant = product?.variants.find(v => v.sku === sku)
  if (variant) {
    variant.price = newPrice
    triggerRef(products) // disparo explícito requerido
  }
}
```

### La directiva v-memo para el renderizado costoso de listas

Para los componentes VDOM que renderizan listas largas, `v-memo` cachea el resultado del renderizado de un subárbol según valores de dependencia. El VDOM omite por completo el diffing de los subárboles memoizados cuyas dependencias no han cambiado.

```vue
<!-- ProductGrid.vue -->
<script setup>
import { ref } from 'vue'

const products = ref([])
const selectedId = ref(null)
</script>

<template>
  <div class="grid">
    <div
      v-for="product in products"
      :key="product.id"
      v-memo="[product.id === selectedId, product.price]"
      :class="{ selected: product.id === selectedId }"
    >
      <h3>{{ product.name }}</h3>
      <span>{{ product.price }}</span>
    </div>
  </div>
</template>
```

El arreglo de `v-memo` `[product.id === selectedId, product.price]` le indica a Vue: no vuelvas a renderizar este elemento a menos que cambie el estado de selección o el precio. Para una lista de 500 productos donde solo uno queda seleccionado, esto reduce el trabajo del VDOM de 500 comparaciones de subárboles a 2 (el elemento antes seleccionado y el recién seleccionado).

### Componentes asíncronos con Suspense para la división de código

Cargar de forma diferida los componentes pesados mantiene ligero el bundle inicial. El `defineAsyncComponent` de Vue junto con `Suspense` gestiona el estado de carga de forma declarativa.

```vue
<!-- Dashboard.vue -->
<script setup>
import { defineAsyncComponent } from 'vue'

// Biblioteca de gráficos pesada cargada solo cuando se necesita
const AnalyticsChart = defineAsyncComponent(() =>
  import('./components/AnalyticsChart.vue')
)

const DataExport = defineAsyncComponent({
  loader: () => import('./components/DataExport.vue'),
  delay: 200,       // muestra la carga después de 200 ms
  timeout: 10000,   // falla después de 10 s
})
</script>

<template>
  <Suspense>
    <template #default>
      <AnalyticsChart />
      <DataExport />
    </template>
    <template #fallback>
      <div class="skeleton-loader" />
    </template>
  </Suspense>
</template>
```

## Vapor Mode vs VDOM: cuándo usar cada enfoque

El Vapor Mode no es un reemplazo universal del Virtual DOM. Cada modo de compilación tiene fortalezas adecuadas a distintos perfiles de componentes.

| Escenario | Modo recomendado | Razón |
|---|---|---|
| Tablas de datos (1000+ filas) | Vapor | Elimina el sobrecosto VDOM por fila |
| Paneles en tiempo real | Vapor | Las actualizaciones frecuentes se benefician del enlace directo al DOM |
| Componentes con muchas animaciones | Vapor | Sin presión sobre el GC por la rotación de VDOM |
| Bibliotecas de componentes de terceros en VDOM | VDOM | La capa de interoperabilidad añade complejidad |
| Componentes que usan la Options API | VDOM | Vapor exige la Composition API |
| Formularios con validación compleja | Cualquiera | Sobrecosto de renderizado mínimo en ambos modos |
| Páginas de contenido estático | Cualquiera | El SSG/SSR hace el trabajo pesado |

La ruta de migración recomendada: primero perfilar la aplicación con la pestaña Performance de Vue DevTools. Identificar los componentes con mayor tiempo de renderizado y frecuencia de re-renderizado. Convertirlos a Vapor Mode, medir el impacto y expandir desde ahí.

## Preguntas de entrevista: rendimiento de Vue 3 y Vapor Mode

Estas preguntas reflejan lo que los equipos de ingeniería preguntan al evaluar la experiencia en Vue en 2026. Cada respuesta resume el razonamiento técnico que espera un entrevistador.

**P: ¿Qué problema resuelve el Vapor Mode y en qué se diferencia de las optimizaciones de VDOM que Vue ya tenía?**

El compilador de VDOM de Vue 3 ya optimizaba los subárboles estáticos, añadía patch flags e implementaba block trees para omitir comparaciones innecesarias. Esto reducía el sobrecosto del VDOM, pero no lo eliminaba: cada cambio de estado seguía exigiendo crear nodos VDOM, recorrer el árbol y generar parches. El Vapor Mode elimina toda esa canalización. El compilador mapea el estado reactivo directamente a mutaciones del DOM, de modo que un cambio de estado dispara exactamente las operaciones del DOM necesarias: sin estructuras de datos intermedias, sin algoritmo de comparación y sin recolección de nodos VDOM desechados.

**P: ¿Pueden convivir los componentes Vapor y VDOM en la misma aplicación?**

Sí. El `vaporInteropPlugin` permite ambos tipos de componentes en un mismo árbol. Un padre VDOM puede renderizar hijos Vapor y viceversa, con algunas salvedades: los slots Vapor no pueden usar `slots.default()` dentro de un componente VDOM (usar `renderSlot` en su lugar), y la interoperabilidad con bibliotecas de componentes basadas en VDOM (Vuetify, PrimeVue) puede presentar asperezas durante la fase experimental.

**P: Explica el modelo de reactividad push-pull de los Alien Signals en Vue 3.6.**

El modelo push-pull divide las actualizaciones reactivas en dos fases. En la fase push, cuando un signal cambia de valor, el sistema propaga una bandera dirty aguas abajo hacia todas las propiedades computadas dependientes: es barato porque solo alterna banderas booleanas. En la fase pull, cuando un valor computado se lee realmente, comprueba si está dirty. Si lo está, recalcula a partir de sus dependencias. Si no, devuelve el valor en caché. Esto evita recalcular de forma anticipada propiedades computadas que podrían no leerse nunca durante un ciclo de actualización concreto.

**P: ¿Cuándo conviene usar `shallowRef` en lugar de `ref` en una aplicación Vue 3?**

`shallowRef` es apropiado cuando la estructura de datos es grande y solo la reasignación de nivel superior debe disparar la reactividad: cachés de respuestas de API, objetos de configuración y arreglos grandes donde las mutaciones de elementos individuales se controlan manualmente con `triggerRef()`. La reactividad profunda envuelve cada propiedad anidada en un Proxy, un sobrecosto innecesario para datos que se reemplazarán por completo en lugar de mutarse en el sitio.

Para practicar más, consulta las [preguntas de entrevista de Vue.js](/technologies/vue-nuxt/interview-questions/vue-composables) sobre composables y patrones de reactividad en SharpSkill.

> **Lecturas adicionales**
>
> La [guía oficial de rendimiento de Vue.js](https://vuejs.org/guide/best-practices/performance) cubre otras técnicas de optimización, incluida la estabilidad de las props, el scroll virtual y el streaming en SSR. Las [notas de la versión beta de Vue 3.6](https://github.com/vuejs/core/releases/tag/v3.6.0-beta.1) documentan cada API del Vapor Mode y sus limitaciones conocidas.

## Conclusión

- El Vapor Mode compila los SFC de Vue en operaciones directas del DOM, eliminando por completo el sobrecosto de creación, comparación y parcheo del Virtual DOM
- Se activa por componente con `<script setup vapor>`, sin necesidad de una migración a nivel de toda la aplicación
- Alien Signals, el nuevo motor de reactividad predeterminado, reduce el uso de memoria en un 14 % y mejora el rendimiento de las propiedades computadas mediante la evaluación perezosa push-pull
- Usa `shallowRef` para grandes estructuras de datos, `v-memo` para el renderizado costoso de listas y `defineAsyncComponent` para la división de código: estos patrones aplican tanto en modo VDOM como Vapor
- El Vapor Mode requiere la Composition API con `<script setup>`. La Options API, `getCurrentInstance()` y `globalProperties` no son compatibles
- Perfila primero con Vue DevTools, convierte a Vapor los componentes de mayor impacto, mide e itera
- Vue 3.6 está en beta a principios de 2026: trata el Vapor Mode como experimental para producción, pero empieza desde ya a que el equipo gane familiaridad

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/es/blog/vue-nuxt/vue-3-performance-vapor-mode-virtual-dom