Las animaciones pueden hacer que una interfaz resulte más clara, agradable y fácil de comprender. Un botón que responde al pasar el cursor, una tarjeta que aparece suavemente o un menú que se despliega ayudan a comunicar que se ha producido un cambio.
Sin embargo, no todas las propiedades CSS tienen el mismo coste para el navegador.
Aunque visualmente dos animaciones puedan parecer similares, internamente pueden activar procesos muy distintos. Cambiar el tamaño de un elemento mediante width o height, por ejemplo, suele requerir más trabajo que modificar su apariencia con transform. Del mismo modo, mostrar u ocultar un componente animando opacity suele ser más eficiente que alterar propiedades que afectan directamente a su geometría.
Por este motivo, una de las recomendaciones más habituales al trabajar con movimiento en interfaces web es animar transform y opacity siempre que sea posible, antes que propiedades como width, height, top o left.
Esta recomendación no es una regla arbitraria. Está relacionada con la manera en que el navegador calcula, pinta y compone cada página.
En este artículo veremos por qué conviene animar transform en CSS, cuándo es recomendable animar opacity, cómo influye la elección de propiedades en el rendimiento y qué alternativas podemos utilizar para evitar animar width y height innecesariamente.
Si todavía estás familiarizándote con estos conceptos, puedes comenzar por esta guía básica de animaciones CSS, donde explico las diferencias entre transition, animation y @keyframes.
Cómo renderiza una página el navegador
Para comprender por qué algunas animaciones son más eficientes que otras, primero debemos observar, de forma simplificada, cómo convierte el navegador nuestro HTML y CSS en los píxeles que aparecen en pantalla.
Cuando una página se carga o cambia, el navegador puede atravesar varias etapas:
- Cálculo de estilos.
- Layout o disposición.
- Pintado.
- Composición.
No todos los cambios CSS necesitan recorrer todas estas fases. Esa es precisamente la diferencia que puede hacer que una animación se perciba fluida o, por el contrario, entrecortada.
Cálculo de estilos
El navegador analiza qué reglas CSS se aplican a cada elemento.
Si añadimos una clase, modificamos un estado como :hover o cambiamos una propiedad mediante JavaScript, puede ser necesario recalcular parte de los estilos de la página.
Este proceso no siempre es especialmente costoso. El problema aparece cuando afecta a una gran cantidad de elementos o se repite continuamente durante una animación.
Por ejemplo, si una clase modifica varias propiedades en un componente complejo, el navegador debe determinar de nuevo qué estilos corresponden a cada elemento involucrado.
Layout: calcular tamaños y posiciones
Durante la fase de layout, también conocida como reflow, el navegador calcula el tamaño y la posición de los elementos dentro del documento.
Aquí intervienen propiedades como:
widthheightmarginpaddingtopleftfont-sizedisplay
Cuando cambia la anchura de un elemento, también puede cambiar la posición de sus hermanos, el tamaño de su contenedor o la distribución de una sección completa.
Imagina una tarjeta situada dentro de una cuadrícula. Si modificamos su width, es posible que el navegador tenga que comprobar si las demás tarjetas caben en la misma fila, si alguna debe pasar a la siguiente línea o si el contenedor necesita cambiar de tamaño.
Por tanto, el navegador no siempre actualiza únicamente el elemento animado. En algunos casos debe volver a calcular una parte considerable de la página.
Paint: convertir los elementos en píxeles
Después del layout, el navegador pinta el contenido.
En esta fase procesa, entre otros elementos:
- Colores.
- Fondos.
- Bordes.
- Texto.
- Imágenes.
- Sombras.
- Gradientes.
Propiedades como background-color, border-color o box-shadow pueden provocar nuevas operaciones de pintado.
El coste dependerá del tamaño del área modificada y de la complejidad visual del componente. No es lo mismo volver a pintar un icono pequeño que una sección que ocupa toda la pantalla y contiene sombras, imágenes y filtros.
Composición: organizar las capas
En la fase de composición, el navegador combina las distintas capas visuales y genera la imagen final que vemos en pantalla.
Propiedades como transform y opacity pueden gestionarse, en muchos casos, principalmente durante esta etapa. Esto permite reutilizar contenido que ya ha sido calculado y pintado.
Por qué la composición suele ser más eficiente
Imagina una tarjeta que ya ha sido colocada y pintada.
Si la movemos cambiando su propiedad left, el navegador puede necesitar recalcular su posición y comprobar cómo afecta el cambio al resto de la página.
En cambio, si la desplazamos utilizando transform: translateX(), el navegador puede mover visualmente una capa que ya estaba preparada.
En términos sencillos, una opción puede obligar a reconstruir parte de la escena, mientras que la otra mueve una pieza que ya existe.
Por qué conviene animar transform en CSS
La propiedad transform permite modificar visualmente un elemento sin cambiar directamente el espacio que ocupa dentro del flujo del documento.
Con ella podemos aplicar diferentes transformaciones:
- Desplazamientos con
translate(). - Cambios de escala con
scale(). - Rotaciones con
rotate(). - Inclinaciones con
skew().
Estas operaciones suelen ser adecuadas para crear animaciones porque no obligan a recolocar automáticamente los elementos que se encuentran alrededor.
Mover un elemento con left frente a translateX
Supongamos que queremos desplazar un elemento horizontalmente.
Una primera opción sería animar la propiedad left:
.elemento {
position: relative;
left: 0;
transition: left 300ms ease;
}
.elemento:hover {
left: 40px;
}
El código funciona, pero left participa en el cálculo de la posición del elemento. Durante la transición, el navegador puede tener que actualizar el layout en cada fotograma.
Una alternativa más eficiente consiste en utilizar transform:
.elemento {
transform: translateX(0);
transition: transform 300ms ease;
}
.elemento:hover {
transform: translateX(40px);
}
El efecto visual es parecido, pero el segundo ejemplo puede resolverse principalmente durante la composición.
Cuando el objetivo sea crear un desplazamiento puramente visual, suele ser preferible utilizar translate() en lugar de animar top, right, bottom o left.
Cambiar el tamaño con scale frente a width
También podemos utilizar transform para simular un cambio de tamaño.
Por ejemplo, podríamos hacer crecer un botón modificando su anchura:
.boton {
width: 180px;
transition: width 250ms ease;
}
.boton:hover {
width: 200px;
}
Esta transición altera el tamaño real del botón. Como consecuencia, puede afectar al texto, al contenedor y a los elementos cercanos.
En muchos casos podemos conseguir una respuesta visual similar utilizando scale():
.boton {
transform: scale(1);
transition: transform 250ms ease;
}
.boton:hover {
transform: scale(1.05);
}
Ahora el espacio utilizado por el layout permanece igual. Lo que cambia es la representación visual del botón.
Este recurso puede resultar especialmente útil en botones, tarjetas o pequeños elementos gráficos. También puede aplicarse a algunos iconos creados únicamente con CSS para añadir una respuesta visual sin modificar su tamaño estructural.
Cuándo scale no sustituye realmente a width o height
Es importante comprender que scale() no modifica el espacio reservado en el documento.
Si un elemento mide 200 píxeles de ancho y aplicamos:
transform: scaleX(1.5);
visualmente será más ancho, pero el navegador continuará reservando los 200 píxeles originales dentro del layout.
Esto puede provocar que el elemento transformado se superponga con otros componentes.
Por tanto, scale() es especialmente útil para:
- Efectos de interacción.
- Botones que crecen ligeramente.
- Tarjetas que destacan al pasar el cursor.
- Iconos que cambian de tamaño.
- Elementos que entran o salen de escena.
- Animaciones decorativas.
No siempre es adecuado para cambios estructurales en los que el contenido debe empujar, reducir o recolocar otros elementos.
Por qué animar opacity en CSS suele ser eficiente
La propiedad opacity controla la transparencia de un elemento.
Su valor puede ir desde 0, completamente transparente, hasta 1, completamente visible:
.elemento {
opacity: 0;
}
Una transición sencilla de aparición podría escribirse así:
.elemento {
opacity: 0;
transition: opacity 300ms ease;
}
.elemento.visible {
opacity: 1;
}
Este cambio no modifica el tamaño ni la posición del componente. Por tanto, generalmente no obliga al navegador a recalcular el layout.
El navegador puede reutilizar la capa del elemento y cambiar su nivel de transparencia durante la composición.
Combinar transform y opacity
Una de las técnicas más útiles para crear entradas suaves consiste en combinar un pequeño desplazamiento con un cambio de opacidad:
.tarjeta {
opacity: 0;
transform: translateY(16px);
transition:
opacity 300ms ease,
transform 300ms ease;
}
.tarjeta.visible {
opacity: 1;
transform: translateY(0);
}
En este ejemplo, la tarjeta:
- Comienza ligeramente desplazada.
- Aparece de forma progresiva.
- Recupera su posición visual.
- No necesita animar su altura ni su posición mediante
top.
Esta combinación es habitual en tarjetas, modales, menús, avisos y elementos que aparecen al hacer scroll.
Cuando la animación requiere secuencias más complejas, coordinación entre varios elementos o un control preciso de los tiempos, puede ser conveniente utilizar una herramienta específica. En ese caso, puedes consultar cómo crear animaciones para la web con la librería GSAP.
Opacity no elimina el elemento del documento
Un detalle importante es que opacity: 0 no equivale a eliminar un elemento.
Un componente transparente continúa:
- Ocupando espacio.
- Pudiendo recibir eventos del puntero.
- Pudiendo recibir el foco mediante el teclado.
- Formando parte del árbol de accesibilidad si no se gestiona de otra manera.
Por eso, para ocultar correctamente un elemento interactivo puede ser necesario combinar varias propiedades:
.menu {
opacity: 0;
visibility: hidden;
pointer-events: none;
transform: translateY(-8px);
transition:
opacity 200ms ease,
transform 200ms ease,
visibility 0s linear 200ms;
}
.menu.abierto {
opacity: 1;
visibility: visible;
pointer-events: auto;
transform: translateY(0);
transition-delay: 0s;
}
La opacidad controla la transición visual, mientras que visibility y pointer-events evitan interacciones accidentales cuando el menú está oculto.
Dependiendo del componente, también puede ser necesario actualizar atributos como aria-hidden, aria-expanded o el estado de los elementos que pueden recibir el foco.
Qué ocurre al animar width o height
Las propiedades width y height forman parte de la geometría del elemento.
Cuando cambian, el navegador puede tener que calcular de nuevo:
- El tamaño del propio elemento.
- La distribución de sus contenidos.
- La posición de los elementos cercanos.
- Las dimensiones del contenedor.
- Los saltos de línea del texto.
- El espacio ocupado por la sección.
Si este cálculo se repite muchas veces por segundo, la animación puede exigir más trabajo al hilo principal.
Esto no significa que animar width o height esté siempre mal. Significa que conviene comprobar si el mismo efecto puede conseguirse sin modificar continuamente el layout.
Ejemplo de una animación de width
Observemos una barra de progreso:
.barra {
width: 0;
height: 8px;
transition: width 500ms ease;
}
.barra.completa {
width: 100%;
}
Animar width puede parecer la solución más evidente. Sin embargo, podemos construir la barra con su tamaño final y animar únicamente su escala horizontal:
.barra {
width: 100%;
height: 8px;
transform: scaleX(0);
transform-origin: left;
transition: transform 500ms ease;
}
.barra.completa {
transform: scaleX(1);
}
El resultado visual es una barra que crece desde la izquierda, pero sin modificar su anchura real en cada fotograma.
La propiedad transform-origin es fundamental:
transform-origin: left;
Sin ella, la barra crecería desde el centro, ya que ese es el origen predeterminado de la transformación.
Ejemplo de una animación de height
Un patrón frecuente consiste en intentar desplegar un contenido animando su altura:
.contenido {
height: 0;
overflow: hidden;
transition: height 300ms ease;
}
.contenido.abierto {
height: 300px;
}
El problema es que el contenido puede no medir exactamente 300 píxeles. Además, la altura se recalcula durante toda la transición.
Otra aproximación conocida utiliza max-height:
.contenido {
max-height: 0;
overflow: hidden;
transition: max-height 300ms ease;
}
.contenido.abierto {
max-height: 600px;
}
Esta técnica puede resultar útil, pero tiene limitaciones. La duración visual real depende de la relación entre la altura del contenido y el valor máximo definido.
Si el bloque mide 150 píxeles y animamos hasta 600, el contenido llegará a su altura visible antes de que termine la transición matemática.
Alternativas para desplegar contenido
No existe una única solución válida para todos los acordeones o paneles.
Dependiendo del diseño, podemos utilizar:
- CSS Grid.
- JavaScript para medir
scrollHeight. - View Transitions cuando el contexto lo permita.
- Una combinación de
opacityytransform. - Una animación de altura cuando sea realmente necesaria.
Un ejemplo con CSS Grid consiste en pasar de una fila con fracción cero a una fila con una fracción:
.acordeon__contenedor {
display: grid;
grid-template-rows: 0fr;
transition: grid-template-rows 300ms ease;
}
.acordeon__contenedor.abierto {
grid-template-rows: 1fr;
}
.acordeon__contenido {
overflow: hidden;
}
Esta técnica permite desplegar contenido de altura variable sin establecer un número fijo. Aun así, sigue existiendo un cambio de layout, por lo que debe utilizarse de manera razonable.
Transform y opacity no son propiedades mágicas
Aunque el rendimiento de transform y opacity suele ser mejor, no significa que cualquier animación basada en estas propiedades vaya a funcionar perfectamente.
El coste final depende de varios factores:
- El tamaño del elemento.
- La cantidad de elementos animados.
- La complejidad del contenido.
- El dispositivo utilizado.
- La memoria gráfica disponible.
- La duración de la animación.
- La presencia de filtros, sombras o desenfoques.
- La cantidad de capas creadas.
Una animación de transform aplicada a cientos de elementos simultáneos puede seguir provocando problemas.
Del mismo modo, animar la opacidad de una capa que cubre toda la pantalla y contiene efectos complejos puede resultar más costoso de lo esperado.
Cuidado con will-change
La propiedad will-change permite avisar al navegador de que una propiedad probablemente cambiará:
.elemento {
will-change: transform;
}
Este aviso puede ayudar al navegador a preparar determinadas optimizaciones antes de que comience la animación.
Sin embargo, no conviene aplicarlo de forma general:
* {
will-change: transform;
}
Este enfoque puede aumentar innecesariamente el consumo de memoria y crear demasiadas capas.
Lo recomendable es utilizar will-change únicamente en componentes concretos que realmente lo necesiten:
.modal {
will-change: transform, opacity;
}
Incluso en esos casos, debemos comprobar si aporta una mejora real. Los navegadores actuales ya realizan muchas optimizaciones sin que tengamos que indicarlas manualmente.
Cómo evitar animar width y height en casos habituales
Antes de crear una transición, conviene preguntarse qué efecto visual queremos conseguir y si realmente necesitamos modificar la estructura del documento.
En muchos casos podemos sustituir una propiedad geométrica por una transformación.
Para mover un elemento
En lugar de modificar su posición con:
left: 20px;
top: 10px;
podemos utilizar:
transform: translate(20px, 10px);
Para agrandar o reducir
En lugar de animar:
width: 110%;
height: 110%;
podemos utilizar:
transform: scale(1.1);
Para mostrar una barra de progreso
En lugar de comenzar con:
width: 0;
podemos utilizar:
transform: scaleX(0);
transform-origin: left;
Para hacer aparecer un componente
Podemos combinar:
opacity: 0;
transform: translateY(12px);
con:
opacity: 1;
transform: translateY(0);
Para ocultar contenido interactivo
Podemos combinar las siguientes propiedades:
opacity
visibility
pointer-events
transform
Cada una cumple una función diferente: transición visual, visibilidad, interacción con el puntero y movimiento.
Cuándo sí tiene sentido animar width o height
Evitar width y height no significa prohibirlas.
Hay situaciones en las que el cambio de tamaño real forma parte de la experiencia y debe modificar el layout.
Por ejemplo:
- Un panel lateral que reduce el espacio disponible del contenido principal.
- Un editor con columnas redimensionables.
- Un acordeón que desplaza los elementos situados debajo.
- Un componente que expande su contenido de forma estructural.
- Una interfaz en la que el tamaño final no puede simularse mediante
scale().
En estos casos, animar la geometría puede ser una decisión válida.
La clave está en hacerlo conscientemente, limitar el número de elementos afectados y comprobar el resultado en dispositivos reales.
La diferencia entre una animación visual y una estructural
Una animación visual modifica cómo percibimos un elemento, pero no necesita alterar el flujo de la página.
Una animación estructural cambia realmente la distribución del contenido.
Para una respuesta al pasar el cursor, un pequeño desplazamiento o una aparición, transform y opacity suelen ser suficientes.
Para un panel que debe empujar otro contenido, es posible que necesitemos cambiar el layout.
No se trata de escoger siempre la propiedad teóricamente más rápida, sino de utilizar la propiedad adecuada para el comportamiento que estamos diseñando.
Cómo comprobar el rendimiento de una animación
No es recomendable asumir que una animación funciona bien únicamente porque se ve fluida en nuestro ordenador.
Un equipo potente puede ocultar problemas que aparecerán en:
- Teléfonos antiguos.
- Dispositivos con poca memoria.
- Páginas con mucho contenido.
- Navegadores con implementaciones diferentes.
- Situaciones en las que se ejecutan varios procesos simultáneamente.
Las herramientas de desarrollo del navegador permiten analizar el trabajo realizado durante una animación.
Podemos revisar:
- La actividad del hilo principal.
- Los cálculos de estilo.
- Las operaciones de layout.
- Las tareas de pintado.
- Los fotogramas lentos.
- La creación de capas.
- Las zonas que se vuelven a pintar.
Si al animar un componente aparecen operaciones de layout continuas, puede ser una señal de que estamos utilizando propiedades geométricas innecesariamente.
También conviene evaluar la animación limitando artificialmente la CPU desde las herramientas de desarrollo y comprobarla en un dispositivo móvil real.
Accesibilidad y prefers-reduced-motion
El rendimiento no es el único criterio que debemos considerar.
Algunas personas pueden experimentar molestias, mareos o dificultades de concentración ante movimientos intensos. Por eso, es importante respetar la preferencia prefers-reduced-motion.
Podemos establecer una animación normal y reducirla cuando la persona haya solicitado menos movimiento en su sistema:
.tarjeta {
opacity: 0;
transform: translateY(16px);
transition:
opacity 300ms ease,
transform 300ms ease;
}
.tarjeta.visible {
opacity: 1;
transform: translateY(0);
}
@media (prefers-reduced-motion: reduce) {
.tarjeta {
transform: none;
transition-duration: 1ms;
}
}
En algunos componentes puede ser mejor eliminar la transición por completo:
@media (prefers-reduced-motion: reduce) {
.elemento-animado {
animation: none;
transition: none;
}
}
Reducir el movimiento no significa ocultar información. El componente debe seguir siendo comprensible y funcional aunque la animación desaparezca.
Buenas prácticas para crear animaciones CSS eficientes
Una animación efectiva no depende únicamente de las propiedades utilizadas. También influyen su duración, su propósito y el contexto en el que aparece.
Animar solo lo necesario
Evita añadir movimiento a todos los elementos de la interfaz.
Cada animación debería cumplir alguna función:
- Confirmar una acción.
- Mostrar una relación entre estados.
- Orientar la atención.
- Explicar la aparición de un componente.
- Suavizar un cambio.
- Comunicar progreso.
Cuando todo se mueve, ningún movimiento destaca.
Mantener duraciones razonables
Las microinteracciones suelen funcionar bien con duraciones breves, aunque no existe un valor universal.
Una transición demasiado lenta puede hacer que la interfaz parezca pesada. Una transición excesivamente rápida puede resultar imperceptible o brusca.
Como referencia inicial, muchos efectos pequeños pueden situarse entre 150 y 300 milisegundos. No obstante, el valor debe ajustarse según la distancia recorrida, el tamaño del elemento y la importancia del cambio.
Evitar transition: all
Es frecuente encontrar reglas como esta:
.elemento {
transition: all 300ms ease;
}
Aunque resulte cómoda, puede animar propiedades que no teníamos intención de modificar.
Es mejor especificar qué propiedades deben cambiar:
.elemento {
transition:
transform 300ms ease,
opacity 300ms ease;
}
De esta forma, el comportamiento es más predecible y reducimos el riesgo de crear transiciones costosas accidentalmente.
Utilizar transform-origin correctamente
Cuando trabajamos con scale() o rotate(), el punto de origen cambia la percepción del movimiento.
Por ejemplo:
transform-origin: left center;
puede hacer que un indicador crezca desde la izquierda, mientras que:
transform-origin: center;
hará que se expanda en ambas direcciones.
Elegir el origen adecuado permite sustituir muchas animaciones de anchura o altura por transformaciones visualmente coherentes.
No olvidar las animaciones SVG
Los mismos criterios de rendimiento pueden aplicarse a gráficos e ilustraciones.
En lugar de reconstruir continuamente el tamaño o la geometría de un elemento, podemos animar desplazamientos, rotaciones y opacidad. Para profundizar en este tipo de recursos, puedes consultar el artículo sobre Sass y animaciones SVG.
Errores frecuentes al optimizar animaciones
Uno de los errores más habituales es sustituir todas las propiedades por transform sin considerar el comportamiento real del layout.
Otro consiste en aplicar will-change a numerosos componentes con la idea de que mejorará automáticamente el rendimiento.
También debemos evitar:
- Animar decenas de elementos sin comprobar el coste.
- Utilizar filtros intensivos junto con grandes desplazamientos.
- Ejecutar animaciones infinitas que no aportan información.
- Mantener elementos transparentes pero interactivos.
- Ignorar
prefers-reduced-motion. - Evaluar el rendimiento únicamente en un ordenador potente.
- Utilizar
transition: allpor comodidad. - Crear animaciones largas para acciones frecuentes.
- Usar
scale()cuando el elemento debe modificar realmente el layout.
La optimización no consiste en memorizar una lista de propiedades permitidas y prohibidas. Consiste en comprender qué trabajo estamos pidiendo al navegador.
Preguntas frecuentes sobre transform, opacity, width y height
¿Por qué transform suele rendir mejor que width o height?
transform modifica principalmente la representación visual del elemento y, en muchos casos, puede gestionarse durante la fase de composición.
Por el contrario, width y height cambian la geometría real del componente y pueden obligar al navegador a recalcular el layout, recolocar otros elementos y volver a pintar parte de la página.
¿Siempre debo evitar animar width y height?
No. Debes evitarlas cuando el efecto sea puramente visual y pueda resolverse con transform.
Si el cambio debe modificar realmente el espacio disponible, desplazar otros componentes o reorganizar el contenido, animar width o height puede ser necesario. Lo importante es utilizar estas propiedades de forma controlada y comprobar su impacto.
¿Es suficiente usar transform y opacity para garantizar una animación fluida?
No. Estas propiedades suelen ser más eficientes, pero el resultado depende del tamaño de los elementos, la cantidad de animaciones, los efectos visuales utilizados, el dispositivo y la complejidad de la página.
Una animación con transform también puede funcionar mal si afecta a demasiados elementos, utiliza capas muy grandes o se combina con filtros y sombras complejas.
Elegir bien qué animar también es diseñar mejor
Elegir entre transform, opacity, width o height no es únicamente una decisión técnica. También es una decisión de diseño.
Cuando animamos una propiedad geométrica, estamos pidiendo al navegador que vuelva a calcular cómo encajan las piezas de la interfaz. Cuando utilizamos transform u opacity, normalmente modificamos cómo se presenta una pieza que ya ha sido calculada.
Por eso, animar transform y opacity suele ofrecer una experiencia más fluida que animar width o height. Sin embargo, esta recomendación no debería convertirse en una regla rígida.
Antes de implementar cualquier movimiento, conviene plantearse una pregunta:
¿Este elemento necesita cambiar realmente el layout o solo debe parecer que se mueve, crece o aparece?
Si el cambio es visual, transform y opacity probablemente sean el mejor punto de partida. Si el cambio es estructural, quizá necesitemos modificar la geometría real.
Una buena animación no es la que utiliza más efectos ni la que resulta más espectacular. Es aquella que ayuda a comprender la interfaz, responde con fluidez y respeta tanto el rendimiento del dispositivo como las preferencias de la persona usuaria.
