El navegador se puso al día: lo que aprendimos reemplazando Framer Motion con APIs nativas

En 2026, el navegador incluye primitivas de transición que antes requerían 50–100 KB de JavaScript. Reemplazamos Framer Motion, Barba.js y manejadores de scroll personalizados con View Transitions API, Speculation Rules y animaciones CSS basadas en scroll en un portafolio multimedia. El resultado: 85 KB menos de dependencias JS, una mejora del 18% en INP y animaciones más suaves en dispositivos de gama baja.

El trimestre pasado reconstruimos el portafolio de un cliente de producción de video — una empresa con 60+ reels, detrás de cámaras y muestras de trabajo. El sitio original usaba Framer Motion para transiciones entre páginas, Barba.js para convertir el sitio multi-página de Astro en una experiencia tipo SPA, y ScrollTrigger para revelaciones basadas en scroll. Total de JavaScript relacionado con animación: 112 KB minificados. El sitio se veía espectacular en una MacBook Pro. En un Moto G Power las transiciones se entrecortaban, la respuesta a interacciones llegaba con retraso y el INP superaba consistentemente los 300 ms.

Decidimos tratar la migración como un experimento: ¿qué tan lejos pueden llevarnos las APIs nativas del navegador en un sitio con mucho contenido multimedia en 2026?

Lo que reemplazamos — y con qué

La cifra principal — cero JavaScript adicional — subestima la verdadera victoria. La eliminación del runtime de animación del thread principal mejoró directamente la capacidad de respuesta a interacciones. Se acabó Framer Motion reconciliando diferencias de layout en cada cambio de ruta. Se acabó Barba.js interceptando clics en enlaces y gestionando su propio historial. Se acabó ScrollTrigger muestreando la posición del scroll en cada frame.

La migración: tres APIs nativas que eliminaron un stack de librerías

1. View Transitions API — Reemplazando Framer Motion + Barba.js

La View Transitions API en 2026 soporta transiciones cross-document (navegación MPA) y same-document (cambios de estado en SPA). Para el portafolio, un sitio Astro con páginas mayormente estáticas, el modo cross-document fue el adecuado.

/* Habilitar en todas las páginas — eso es todo para transiciones básicas */
@view-transition {
  navigation: auto;
}

Esta única regla CSS reemplazó Barba.js por completo. Las navegaciones entre páginas ahora tienen un cross-fade suave sin JavaScript. Pero el poder real llegó con las transiciones nombradas para elementos específicos.

El portafolio tenía una cuadrícula de thumbnails de video que necesitaban "morphearse" a la vista de detalle — la imagen de la tarjeta se expande para convertirse en el hero de la página siguiente. En Framer Motion, esto requería LayoutGroup y AnimatePresence con IDs de layout compartidos. Con View Transitions:

/* En la página de cuadrícula */
.video-thumb {
  view-transition-name: video-thumbnail;
  contain: paint;
}

/* En la página de detalle */
.video-hero {
  view-transition-name: video-thumbnail;
  contain: paint;
}

El navegador interpola automáticamente posición, tamaño y opacidad entre los dos elementos. Sin JavaScript. Sin thrashing de layout. Sin errores de hidratación.

Problema que encontramos: Para que view-transition-name funcione correctamente, ambos elementos deben existir en el DOM simultáneamente por un breve instante — lo que significa que el elemento de origen debe persistir hasta que el navegador complete la captura. Añadimos un retraso de 200 ms en el desmontaje de la página de cuadrícula para evitar que el thumbnail desaparezca antes del snapshot.

2. Speculation Rules API — Eliminando la pausa de carga percibida

View Transitions hace que la navegación se vea suave, pero sin contenido es un cross-fade hacia un esqueleto. La Speculation Rules API resuelve esto prerenderizando las páginas probables en segundo plano.

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "eagerness": "moderate"
  }]
}
</script>

Con eagerness: "moderate", Chrome prerenderiza páginas que el usuario probablemente visitará basándose en patrones de hover y comportamiento de scroll — sin que el desarrollador tenga que especificar enlaces exactos. Para el portafolio, esto significó que hacer clic en un thumbnail se sentía instantáneo porque la página destino ya estaba completamente cargada y renderizada.

Impacto en rendimiento: Las navegaciones a páginas con video en la primera visita pasaron de 1.2–2.5 segundos de carga a efectivamente cero — la página se prerenderiza mientras el usuario navega la cuadrícula. El costo de CPU se distribuye en tiempo idle, sin competir con la capacidad de respuesta a interacciones.

3. Animaciones CSS basadas en scroll — Reemplazando ScrollTrigger

Las animaciones de revelación de ScrollTrigger (secciones con fade-in, headers con parallax, barras de progreso) fueron las más fáciles de reemplazar. CSS animation-timeline soporta animaciones impulsadas por scroll de forma nativa:

@keyframes fade-in {
  from { opacity: 0; transform: translateY(20px); }
  to { opacity: 1; transform: translateY(0); }
}

.reveal-section {
  animation: fade-in linear both;
  animation-timeline: scroll(root);
  animation-range: entry 0% entry 100%;
}

Esto dispara la animación cuando el elemento entra al viewport — cero JavaScript, corre fuera del thread principal. Lo usamos para encabezados de sección, contadores y el footer de "siguiente proyecto". La única brecha fueron las revelaciones secuenciales (animar sección A, luego B, luego C al hacer scroll) — para eso mantuvimos un script de observación de scroll de 4 KB en lugar de reimportar GSAP.

Los datos de rendimiento

Recogimos datos de campo de usuarios reales a través de Chrome UX Report y nuestro propio RUM antes y después de la migración.

*En primera visita sin caché *Con Speculation Rules prerender activo

La mejora en INP merece atención. Eliminar el runtime de animación significó que el thread principal quedó libre para procesar interacciones de usuario inmediatamente. Antes de la migración, hacer scroll por la cuadrícula del portafolio mientras las animaciones aún se inicializaban disparaba long tasks con frecuencia. Después, las interacciones durante las transiciones de página eran responsivas porque el thread del compositor manejaba la animación independientemente.

Vale la pena mencionar la contrapartida: prerenderizar con Speculation Rules incrementa el uso de memoria total. En el Moto G Power (3 GB RAM), medimos unos 40 MB adicionales por página prerenderizada. Para la mayoría de los sitios esto es insignificante, pero en dispositivos extremadamente limitados podría provocar descartes de pestañas. Lo mitigamos limitando el presupuesto de prerender a una página a la vez.

Cuándo las APIs nativas no son suficientes

Esta migración funcionó para un portafolio multimedia con patrones de transición relativamente sencillos. No recomendaríamos ir completamente nativo para:

• Coreografías con timeline complejo — Si necesitas animaciones que se secuencian a través de múltiples elementos con retardos, pausas y control de reproducción, los timelines CSS no son suficientemente expresivos aún. Mantén GSAP o una librería ligera (~8 KB tree-shaken).
• Animaciones con Canvas/WebGL — View Transitions no captura el contenido de canvas para morphing. Las transiciones basadas en WebGL siguen necesitando una librería JS.
• Drag-and-drop con animaciones — Las APIs nativas popover y dialog ayudan con overlays, pero el drag-and-drop animado requiere JavaScript.
• Narrativas multi-escena controladas por scroll — Si tu página cuenta una historia a través de la posición controlada del scroll (como las páginas de producto de Apple), las animaciones de scroll CSS son demasiado rígidas. Mantén ScrollTrigger.

Hemos aplicado el mismo patrón a otros dos proyectos — un sitio de documentación y una tienda e-commerce pequeña — con resultados similares. El sitio de documentación ganó +15 puntos en Lighthouse. La tienda e-commerce vio una mejora del 9% en la velocidad de interacción de añadir al carrito.

El framework de decisión que usamos ahora

Al empezar un proyecto nuevo, revisamos esta lista antes de importar cualquier librería de animación:

1. ¿Son animaciones de transición entre páginas? → View Transitions API
2. ¿Hay elementos compartidos que morphean entre páginas? → Añadir view-transition-name
3. ¿Necesitas navegaciones instantáneas en páginas probables? → Añadir Speculation Rules
4. ¿Las animaciones se disparan por posición de scroll? → Animaciones CSS basadas en scroll
5. ¿Hay revelaciones secuenciales con orden estricto? → Observador JS ligero (4 KB máx)
6. ¿Necesitas coreografía multi-elemento con timeline? → Evaluar GSAP o Motion (tree-shaken)

Si llegas al paso 6 en más de un proyecto por trimestre, el costo de la librería vale la pena. Si solo haces pasos 1–5, el navegador ya te cubre.

La plataforma web en 2026 está cerrando la brecha más rápido de lo que la mayoría de los equipos creen. Perdimos meses asumiendo que necesitábamos frameworks para transiciones y animaciones que el navegador ahora provee de forma nativa. Antes de añadir tu próxima dependencia de animación, verifica si la plataforma ya incluye lo que necesitas.

Artículo publicado originalmente en el blog de Mintec. Para más sobre arquitectura web moderna y desarrollo orientado al rendimiento, explora nuestros artículos de desarrollo web.