Construyó un sitio hermoso en Framer. Las animaciones se ven fluidas en el editor, el diseño luce impecable y todo parece rápido en su MacBook Pro. Luego ejecuta una prueba de PageSpeed y obtiene una puntuación de 45.
No es el único en esta situación. Muchos sitios de Framer obtienen resultados por debajo de las expectativas en Core Web Vitals de Google, especialmente en móvil. A continuación se explica por qué suele ocurrir y qué puede hacer al respecto.
Los datos de rendimiento
Durante el último año se han auditado decenas de sitios Framer. El patrón es consistente:
| Métrica | Promedio en Framer | Umbral "bueno" de Google | Promedio en Next.js |
|---|---|---|---|
| Puntuación móvil de PageSpeed | 42-65 | 90+ | 92-99 |
| Largest Contentful Paint | 3,2-5,8 s | Menos de 2,5 s | 0,8-1,5 s |
| Total Blocking Time | 400-1.200 ms | Menos de 200 ms | 10-80 ms |
| Cumulative Layout Shift | 0,05-0,25 | Menos de 0,1 | 0-0,02 |
Estos son los rangos habituales observados en sitios empresariales de Framer con animaciones, contenido CMS y componentes personalizados. Los sitios más simples pueden rendir mejor, pero la complejidad tiende a reducir las puntuaciones.
Por qué los sitios de Framer pueden ser lentos
Bundle de JavaScript pesado
Framer envía un gran runtime de JavaScript a cada página. Este runtime impulsa el motor de animaciones, el renderizado del CMS y el sistema de componentes. Incluso una landing page sencilla con contenido mínimo carga 200-400 KB de JavaScript antes de que aparezca el contenido real.
En un teléfono Android de gama media con conexión 4G, analizar y ejecutar ese JavaScript lleva entre 1 y 3 segundos. Eso es antes de que carguen las imágenes, se rendericen las fuentes o el usuario vea algo útil.
Renderizado del lado del cliente
Framer renderiza las páginas principalmente en el cliente. El navegador descarga el HTML, luego el JavaScript, y después el JavaScript construye la página. Next.js, en cambio, envía HTML completamente renderizado desde el servidor: el navegador muestra el contenido de inmediato mientras el JavaScript se carga en segundo plano.
Por eso su sitio de Framer se siente rápido en el portátil pero obtiene puntuaciones bajas en PageSpeed. La prueba simula un dispositivo móvil real con una conexión móvil real, no una MacBook con fibra óptica.
Carga de las animaciones
El sistema de animaciones de Framer es potente pero costoso. Cada animación activada por scroll, efecto hover y transición de página añade al costo de ejecución de JavaScript. Las animaciones que resultan fluidas en escritorio pueden provocar tirones visibles en dispositivos móviles con menor capacidad de procesamiento.
Optimización de imágenes limitada
Framer realiza una optimización básica de imágenes, pero no permite controlar formatos, ajustes de calidad ni estrategias de tamaño responsivo. El componente Image de Next.js sirve automáticamente WebP/AVIF en las dimensiones correctas para cada dispositivo, con carga diferida y placeholders de desenfoque progresivo. La diferencia en el peso de las imágenes puede ser del 50-80%.
Qué puede hacer dentro de Framer
Si desea mantenerse en Framer, hay mejoras significativas que puede aplicar:
- Reducir el número de animaciones, ya que cada una tiene un costo de rendimiento
- Comprimir las imágenes antes de subirlas en lugar de depender de la optimización de Framer
- Minimizar las sobreescrituras de código personalizado y los scripts embebidos
- Eliminar componentes y secciones que no se usen
- Evitar estructuras de componentes profundamente anidadas
En la práctica, estas optimizaciones pueden mejorar la puntuación entre 10 y 15 puntos. Si está en 45, podría llegar a 55-60. Aun así, por debajo del umbral de rendimiento "bueno" de Google.
El costo empresarial
Google utiliza Core Web Vitals como señal de posicionamiento. Una experiencia móvil lenta se traduce en peor ranking en buscadores. Más allá del SEO, el 53% de los visitantes móviles abandona un sitio que tarda más de 3 segundos en cargar (datos de Google). Si el LCP de su sitio Framer supera los 4 segundos, está perdiendo visitantes antes de que vean su contenido.
Para sitios que dependen del tráfico orgánico o de conversiones de anuncios de pago, el bajo rendimiento afecta directamente a los ingresos. Cada 100 ms de tiempo de carga adicional reduce la tasa de conversión aproximadamente un 1%.
La alternativa
Una migración a Next.js conserva el diseño mientras soluciona los problemas de rendimiento de fondo. El resultado visual permanece igual: mismo layout, mismas animaciones, misma identidad de marca. Lo que cambia es el mecanismo de entrega: de JavaScript renderizado en el cliente a HTML renderizado en el servidor con activos optimizados.
El resultado habitual en los proyectos de migración de webvise es pasar de 45-65 en PageSpeed móvil a 92-99. Mismo diseño, rendimiento sustancialmente mejor. Mejor posicionamiento, menor tasa de rebote, más conversiones.
Si su sitio Framer es una herramienta de negocio, no solo una pieza de portfolio, el rendimiento debe ser una prioridad. Analice su sitio en PageSpeed Insights desde móvil y compruebe en qué punto se encuentra. Los números le dirán si la optimización dentro de la plataforma es suficiente o si ha llegado a los límites de lo que la arquitectura de Framer puede ofrecer para su caso de uso.