01
Solo transform y opacity
Son las propiedades que el navegador puede animar sin recalcular el layout. Animar ancho, alto o posición en el flujo es la forma más rápida de romper CLS e INP.
Experimento
Experimento: cuánto motion aguanta un sitio antes de ponerse lento.
El motion de este sitio es una decisión de diseño y una apuesta de performance. Acá está la hipótesis, las reglas, el método y la tabla de resultados, que por ahora está vacía a propósito.
- Experimento
- 2026
- Diseño web
- WordPress + Elementor Pro
Aclaración
Esto no es un cliente real. Es un experimento sobre nuestro propio sitio.
No prueba que valga lo mismo en el tuyo. Prueba si nuestro método de cuidar la velocidad funciona, y lo publicamos aunque no salga bien.
Contexto
Un sitio con movimiento tiene que ser, primero, un sitio rápido
Este sitio usa animaciones con GSAP: títulos que entran y secciones que se pinean al scrollear. Es parte de la identidad. Pero una animación que hace esperar al visitante es un defecto, no un detalle.
El desafío, planteado como hipótesis: se puede tener motion editorial con un sitio en WordPress y Elementor Pro, y aun así quedar dentro de los umbrales de Core Web Vitals en mobile.
Enfoque
Seis reglas para el motion
02
Carga diferida
ScrollTrigger y SplitText se cargan fuera del camino crítico. La primera pantalla no depende de ellos.
03
El LCP no espera al motion
El título y el primer visual se renderizan sin esperar JS: un elemento con opacidad 0 no cuenta como LCP hasta que se ve, y esconderlo hasta que cargue el script retrasaría la métrica.
04
prefers-reduced-motion manda
Con movimiento reducido no hay animaciones de scroll ni pins, y el contenido aparece en su estado final. Es la versión completa, sin movimiento.
05
Menos motion en mobile
Con gsap.matchMedia() separamos escritorio y mobile: en pantallas chicas, sin pins ni texto partido, solo fundidos cortos.
06
Presupuesto antes de empezar
Peso de JS, elementos animados por pantalla y tres métricas. Si una pieza rompe el presupuesto, se simplifica o se saca.
Qué construimos
Las piezas del experimento
Motion
- GSAP 3.15
- ScrollTrigger
- SplitText
Plataforma
- WordPress
- Elementor Pro
Control
- gsap.matchMedia()
- prefers-reduced-motion
- Interruptor para comparar con y sin motion
Medición
- Lighthouse y PageSpeed Insights
- Reporte de Core Web Vitals de Search Console
Qué mediríamos
La tabla que se llena después
Medimos primero en laboratorio, con y sin motion, en mobile y con red lenta. Después usamos datos de campo, cuando haya tráfico suficiente.
| Métrica | Objetivo | Resultado |
|---|---|---|
| LCP (carga del elemento principal) | < 2,5 s | Se publica tras medir en producción |
| INP (respuesta a la interacción) | < 200 ms | Se publica tras medir en producción |
| CLS (estabilidad visual) | < 0,1 | Se publica tras medir en producción |
| Peso de JS | Presupuesto propio: animación en 100 KB comprimidos o menos, en diferido | Se publica tras medir en producción |
LCP, INP y CLS usan los umbrales de “bueno” de Google, medidos en el percentil 75 de las visitas. El presupuesto de JS es nuestro.
Límites y riesgos
Lo que este experimento no puede decir
- Laboratorio no es campo. Lighthouse simula; lo que cuenta es lo que viven los visitantes, y los datos de campo se acumulan en una ventana de 28 días.
- El motion no es lo único que pesa. Imágenes, fuentes y plugins pueden pesar más que la animación, por eso medimos el sitio entero.
- GSAP no arregla un sitio pesado. Si el tema o los plugins ya rompen INP, animar no ayuda.
- Un caso no es una regla. Es nuestro sitio, con nuestro contenido.
- Gamas bajas. Un celular modesto puede comportarse distinto al que usamos para probar.
Con un cliente real
Qué cambiaría
Partiríamos de los datos de campo del sitio actual, acordaríamos el presupuesto con el cliente y pondríamos el movimiento solo donde acompaña la conversión: nunca en el formulario ni en el carrito. Revisaríamos plugins antes que animaciones y seguiríamos midiendo después del lanzamiento, como parte del mantenimiento de WordPress. El enfoque general está en WordPress + Elementor Pro y en diseño web.
Fuentes
- web.dev: Web Vitals y sus umbrales — Documentación de Google.
- web.dev: Interaction to Next Paint (INP) — Documentación de Google.
- MDN: prefers-reduced-motion — Documentación de Mozilla.
- GSAP: documentación v3 — ScrollTrigger, SplitText y matchMedia.
Seguí por acá
Bien hecho, y editable por vos.
Que tu web no sea una bomba de tiempo.
Rápido, claro y hecho para vender.
Naming, identidad y web, con decisiones y descartes.
Siguiente paso
¿Tu web se siente lenta?
Contanos qué sitio tenés y qué te preocupa. Te devolvemos qué mediríamos primero.