Las page transitions dañan el INP cuando el navegador ejecuta JavaScript pesado en el hilo principal justo después de una interacción —clic de navegación, toque en el menú— y retrasa la siguiente pintura más allá de los 200 milisegundos que marca el umbral de Core Web Vitals. La fórmula segura: transiciones con View Transitions API para cambios del mismo documento o CSS puro sobre transform y opacity; GSAP solo para coreografía de elementos en vista con presupuesto estricto; todo apagado con prefers-reduced-motion; e INP medido en datos de campo antes y después de cada cambio. Si la transición bloquea el manejo de input o no cabe en un frame cómodo, no se publica. A continuación: por qué ocurre, patrones seguros, comparativa View Transitions contra GSAP, checklist de medición y cuándo no usarlas.
Por qué las transiciones matan el INP
El INP mide cuánto tarda la página en responder de forma visible tras una interacción. Cualquier tarea larga que ocupe el hilo principal en esa ventana se cobra el valor: el usuario toca, la interfaz no responde y el percentil se va por los cielos. Las transiciones son un candidato perfecto para esa tarea larga porque, por diseño, ocurren justo después del clic.
Cuatro mecanismos explican casi todos los casos. Primero, el JavaScript de la transición corre en el hilo principal: construir nodos, calcular estilos o disparar cientos de tweens durante la interacción compite directamente con el input. Segundo, el forced reflow: animar propiedades de layout —top, height, margin, width— obliga al navegador a recalcular el documento en cada frame, y esos recálculos encadenados se acumulan como tareas largas. Tercero, el trabajo post-carga: librerías que cargan y luego animan convierten una transición suave en un rebote feo en dispositivos modestos. Y cuarto, la navegación entre documentos: cada cambio de página es un mundo nuevo y, sin precarga ni estrategia, la transición se come el presupuesto de la propia página entrante, golpeando también el LCP.
El detalle que muchos pasan por alto: el INP de datos de campo no se salva con un buen promedio de laboratorio. Lighthouse corre en una máquina limpia; el 75% de tus usuarios reales no. Por eso el análisis completo de este tema vive en nuestra guía de page transitions y Core Web Vitals.
Patrones seguros de transición
No todas las transiciones son iguales. Estos patrones caben en un presupuesto serio:
- View Transitions del mismo documento: cambiar de vista o panel con la API nativa delega el snapshot al navegador; el JavaScript solo registra el cambio y no coordina cientos de propiedades a mano. Es la vía más barata cuando la navegación ocurre dentro de la página.
- CSS puro sobre transform y opacity: el navegador compone en la GPU sin recalcular layout. Entradas y salidas de 200 a 400 ms con easing suave cubren la mayoría de menús, drawers y cambios de sección.
- Skeletons y swapped de contenido: en vez de ocultar y revelar bloques completos, reserva el espacio y funde el contenido nuevo. Cero sorpresas de layout y cero CLS de regalo.
- Precarga en hover y en coladera de red: si la transición necesita la siguiente página, adelanta la descarga cuando el usuario se acerca al enlace o cuando la conexión lo permite; la animación entonces solo orquesta bytes que ya están cerca.
- Presupuesto por página: una o dos transiciones con duración máxima y propiedades permitidas. Si cada sección quiere la suya, el presupuesto se rompe y el INP lo paga.
- Respeta prefers-reduced-motion: con movimiento reducido, la transición se sustituye por un fundido mínimo o por nada. No es opcional: es accesibilidad y está especificada en el API de View Transitions en MDN y en las guías de motion de la propia plataforma.
Cuando el alcance crece —storytelling de scroll, secuencias con varias capas— el patrón deja de ser «transición» y pasa a ser motion de página completo. Ahí el trabajo se diseña como sistema, como explicamos en desarrollo motion web y en motion web development.
View Transitions API contra GSAP
La pregunta no es cuál es mejor, sino cuál encaja con el trabajo. La tabla resume la decisión que tomamos en producción:
| Criterio | View Transitions API | GSAP |
|---|---|---|
| Caso de uso ideal | Cambios de vista y navegación del mismo documento con snapshots | Coreografía de scroll, timelines y estados encadenados |
| Control | Limitado: el navegador compone; tú defines pseudo-elementos | Total: easing, retardos, callbacks y secuencias a medida |
| Costo en el hilo principal | Bajo si el snapshot es barato y no hay layout forzado | Depende: mal usado (layout properties) dispara tareas largas |
| Soporte y degradación | Navegadores modernos; sin soporte, transición ausente pero la navegación funciona | Universal vía JavaScript; falla si el script no carga |
| Riesgo de INP | Snapshots de documentos enormes y callbacks lentos | Muchas animaciones simultáneas y forzado de reflow |
Regla práctica: si la transición es «una pantalla sustituye a otra», empieza por View Transitions y solo baja a GSAP si necesitas control que la API no da. Si la animación vive dentro de la pantalla —scroll, entrada de elementos, estados de componentes—, GSAP con transform y opacity sigue siendo la herramienta correcta, con su documentación oficial como referencia del equipo. La matriz completa de elección está en motion web development.
Checklist de medición
Antes y después de cada transición, pasa esta lista. Sin números de campo, no hay decisión:
- INP en campo: por debajo de 200 ms en el percentil 75, no solo en Lighthouse. Mira datos de ventana reciente, no el promedio histórico.
- LCP de la página entrante: la transición no puede retrasar el primer contenido grande; precarga o elimina el bloqueo.
- CLS durante la transición: si el swap mueve el layout, el salto se cobra; reserva alturas y usa fundidos.
- Tareas largas en Performance: ninguna tarea de más de 50 ms durante la interacción; si aparecen, el JavaScript de la transición es el sospechoso.
- Prueba en dispositivo modesto con CPU limitada: simula un cuatro o seis veces más lento; la transición que solo funciona en tu portátil no funciona.
- Conexión lenta: verifica que la precarga exista y que la degradación sea elegante sin red.
- Movimiento reducido: con la preferencia activada, la transición se apaga o se sustituye por un fundido mínimo.
- Corre tras cada release: el presupuesto se vigila en cada deploy, no en la auditoría anual. El marco de umbrales vive en optimización de INP en web.dev.
Cuándo NO usar transiciones
Hay contextos donde la animación entre páginas es peor que nada:
- Sitios con tráfico mayoritariamente móvil modesto: si tus datos de campo ya rozan el umbral de INP, una transición nueva es un lujo que no puedes pagar.
- Flujos transaccionales: checkouts, formularios críticos y paneles donde la respuesta inmediata al clic vale más que cualquier efecto.
- Contenido que el usuario repite rápido: búsquedas, filtros y paginación; ahí la transición se ve cientos de veces y cada milisegundo se multiplica.
- Sin presupuesto ni medición: si nadie va a medir INP después del lanzamiento, no introduzcas la variable; es deuda disfrazada de pulido.
- Cuando el movimiento no comunica nada: si la transición no explica de dónde vino la nueva pantalla ni a dónde va el usuario, es ruido visual con costo técnico.
- Plataformas sin degradación prevista: si el navegador del visitante no soporta la API y no hay plan B, mejor entregar la navegación limpia.
La regla que usamos en el estudio: la transición se gana su lugar con evidencia, no con gusto. Se implementa, se mide en campo y se queda solo si el INP, el LCP y el CLS siguen verdes. Si no, se retira sin drama: un sitio rápido y simple siempre gana contra uno lindo y lento.
Preguntas frecuentes
¿Cuánto puede durar una page transition sin dañar el INP?
Entre 200 y 400 ms con transform y opacity suele ser seguro, siempre que el trabajo de JavaScript en la interacción sea mínimo. Por encima de eso, o con recálculo de layout, el riesgo sube rápido.
¿View Transitions API reemplaza a GSAP?
No. La API cubre cambios de vista con snapshots del navegador; GSAP cubre coreografía, scroll y estados encadenados. Muchos proyectos usan ambas: API para el cambio de pantalla y GSAP dentro de cada pantalla.
¿Las transiciones afectan el SEO?
No deberían, si el contenido existe en el DOM desde el primer render y no depende de la animación para aparecer. La navegación entre documentos debe seguir siendo enlaces reales, rastreables y precargables.
¿Cómo mido el INP de mis transiciones?
Con datos de campo —Chrome UX Report o la biblioteca web-vitals en producción— más una pasada en Performance con CPU limitada. Lab sin campo miente; campo sin lab no explica.
¿Cuándo conviene quitar una transición que ya está?
Cuando el percentil 75 de INP se acerca a 200 ms, cuando aparecen tareas largas durante el clic o cuando la transición no aporta comprensión al usuario. Medir dos semanas seguidas da la respuesta.
Guías relacionadas: Cuánto cuesta una página web en México en 2026 (precios reales) · Diseño web en CDMX para negocios