¿Las animaciones hacen lento un sitio en Webflow?

La versión honesta

Un sitio con movimiento real casi siempre va a puntuar más bajo que el mismo sitio sin nada. El que te diga lo contrario te está vendiendo algo. La pregunta que vale no es si el movimiento cuesta, es si lo que recibís a cambio vale lo que pagaste.

BIKE es un instituto de inglés en Uruguay, y sirve como caso de prueba porque no es un build contenido. Tiene un preloader a medida que se dibuja antes del primer scroll, reveals con GSAP que marcan el ritmo de toda la página, y una bicicleta 3D interactiva en el 404. Saca 81 en rendimiento de Lighthouse, 100 en SEO y 90 en accesibilidad.

81 es un buen número. No es 98, y decir lo contrario sería deshonesto. Pero ese número compra un sitio que se siente yendo a algún lado, para un negocio cuya promesa entera es que vas a mejorar en algo con el tiempo. Una página estática habría vendido eso de menos.

Qué hace lento a un sitio en Webflow de verdad

En la práctica, la librería de animación rara vez es la culpable. Lo que aparece una y otra vez es más aburrido que eso:

• Imágenes sin comprimir. Una sola foto de hero exportada a resolución completa pesa más que todos los scripts de la página juntos.
• Tipografías mal cargadas. Cuatro pesos cuando usás dos, sin preload, sin swap.
• Scripts de terceros. Widgets de chat, mapas de calor, tres herramientas de analytics, un banner de cookies de 2019. Cada uno es código ajeno corriendo en tu camino crítico.
• Que todo se mueva. No que las cosas se muevan, sino que no se haya dejado nada quieto.

Fijate que solo el último tiene que ver con el movimiento, y ni siquiera ahí el problema es GSAP. El problema es que no se tomó ninguna decisión sobre dónde va el movimiento.

Dónde va el presupuesto

Tratá al movimiento como cualquier otro presupuesto. Tenés una cantidad finita y repartirla en partes iguales es lo mismo que gastarla mal.

En BIKE se concentró en tres lugares: el preloader, porque marca el tono antes que cualquier otra cosa; los reveals de la página, porque la marca habla de progreso y la página tiene que sentirse avanzando; y el 404, porque un callejón sin salida era una oportunidad de ser memorable en vez de pedir disculpas.

Todo lo demás está quieto. Los formularios no rebotan. Las cards no se inclinan. La sección de cursos, que es a lo que la gente realmente vino, se corre del camino y los deja leer.

Tres preguntas antes de animar algo

Son las que me hago en cada build, y matan la mayoría de las ideas de animación antes de que cuesten nada:

• ¿Ayuda a entender la página? El movimiento que muestra una relación entre dos cosas se gana su lugar. El que decora, no.
• ¿Alguien que entra por primera vez notaría que falta? Si no, es un buen argumento para sacarlo.
• ¿Demora lo que la persona vino a buscar? Cualquier cosa entre el visitante y el contenido que quiere tiene que ser corta y deliberada.

La parte que nadie menciona

El movimiento tiene un costo de mantenimiento que no aparece en ningún reporte de Lighthouse. Cada elemento animado es algo que se puede romper cuando un cliente agrega un quinto ítem a una grilla de cuatro, o pega un párrafo el doble de largo que el placeholder.

Esta es la razón real para ser selectivo, y es por lo que construyo el movimiento contra la estructura del CMS y no contra un contenido específico. Un reveal que asume tres cards te va a hacer pasar vergüenza el día que alguien agregue la cuarta.

Entonces: ¿las animaciones hacen lento un sitio en Webflow?

Un poco. Menos que tus imágenes. Y si el movimiento está haciendo trabajo real, sosteniendo una marca, explicando una estructura, haciendo que un callejón sin salida se sienta intencional, unos puntos de Lighthouse son un precio razonable.

Lo que no es razonable es pagar ese precio por movimiento que nadie pidió en una página que nadie puede leer.