Framer Motion en Next.js App Router sin penalizar el rendimiento

Framer Motion es la librería de animación más completa del ecosistema React, pero también una de las más fáciles de usar mal: importarla entera en cada componente e infla el bundle inicial de una landing que debería cargar en milisegundos. Esto es lo que hago para usarla con criterio.

Solo en Client Components, y solo donde aporta

Framer Motion necesita 'use client'. Eso ya significa que cualquier componente que lo use se hidrata en el navegador. La regla: solo animo con Framer Motion elementos donde la animación es parte real de la experiencia (transiciones de sección, reveals con física de resorte), no donde un transition de CSS puro ya resuelve el 90% del efecto.

Lazy loading del componente animado

Los bloques que usan Framer Motion y no son above-the-fold se cargan con next/dynamic y { ssr: false } cuando no necesitan SSR. Esto retrasa la descarga de esa parte del bundle hasta que el navegador la necesita, manteniendo el LCP inicial ligero.

AnimatePresence con cuidado en listas largas

AnimatePresence para animar entradas y salidas de elementos es potente, pero cada nodo que anima necesita seguimiento del framework. En listas largas (más de 15-20 items), prefiero animaciones CSS con Intersection Observer (el patrón que uso en mi propio Reveal) en vez de AnimatePresence, que no escala igual de bien.

Conclusión

Framer Motion no es el problema; usarlo sin medir el impacto en el bundle sí lo es. Con lazy loading selectivo y reservando la librería para las animaciones que de verdad lo necesitan, el rendimiento no se resiente y la experiencia gana el pulido que CSS puro no siempre logra.