Cómo animar un menú móvil con CSS

Posted on by marta

Los menús de navegación para dispositivos móviles se han convertido en un componente imprescindible en la mayoría de los sitios web. Cuando el espacio disponible en pantalla es reducido, la navegación principal suele ocultarse detrás de un botón reconocible, generalmente representado mediante tres líneas horizontales. Al pulsarlo, el menú aparece con una transición que ayuda al usuario a comprender qué está ocurriendo en la interfaz.

Sin embargo, añadir movimiento a un menú no consiste únicamente en aplicar una propiedad transition. Una animación mal planteada puede generar saltos visuales, problemas de rendimiento o dificultades de accesibilidad. Por el contrario, un menú móvil CSS animado correctamente implementado puede mejorar la orientación, reforzar la jerarquía visual y hacer que la navegación resulte más natural.

En esta guía veremos cómo animar un menú móvil con CSS, qué estructura HTML conviene utilizar, cómo controlar su apertura, qué propiedades ofrecen mejor rendimiento y cómo respetar las preferencias de movimiento de cada persona.

¿Qué es un menú móvil animado?

Un menú móvil animado es un sistema de navegación diseñado para pantallas pequeñas que permanece oculto hasta que el usuario activa un botón. Al abrirse o cerrarse, el panel cambia de estado mediante una transición o una animación.

El patrón más habitual es el denominado menú hamburguesa CSS, aunque también pueden utilizarse otros iconos, como una flecha, varios puntos o una etiqueta de texto que indique claramente “Menú”.

La animación puede aplicarse de diferentes maneras:

  • Desplazando el panel desde uno de los laterales.
  • Mostrándolo desde la parte superior.
  • Aplicando una aparición gradual.
  • Escalando el contenido desde un punto concreto.
  • Ocupando toda la pantalla con una capa de navegación.
  • Animando cada enlace con un pequeño retraso.

El objetivo no debería ser llamar la atención mediante efectos complejos. La animación tiene que explicar el cambio de estado, no dificultarlo.

Cuando el menú se desplaza desde el lateral derecho, por ejemplo, el usuario percibe que existe un panel fuera del área visible. Cuando se desvanece, entiende que el elemento estaba oculto y acaba de aparecer. El movimiento aporta contexto espacial a la interacción.

Estructura básica de un menú hamburguesa accesible

Antes de comenzar con la animación, necesitamos una estructura HTML clara y semántica.

Aunque es posible abrir y cerrar un menú utilizando exclusivamente CSS mediante un checkbox, en un proyecto real suele ser preferible emplear un botón y una pequeña cantidad de JavaScript. Esto facilita la gestión de atributos de accesibilidad como aria-expanded.

<header class="site-header">
  <a class="site-logo" href="/">
    Marta González
  </a>

  <button
    class="menu-toggle"
    type="button"
    aria-expanded="false"
    aria-controls="mobile-menu"
    aria-label="Abrir menú"
  >
    <span class="menu-toggle__line"></span>
    <span class="menu-toggle__line"></span>
    <span class="menu-toggle__line"></span>
  </button>

  <nav
    class="mobile-menu"
    id="mobile-menu"
    aria-label="Navegación principal"
  >
    <ul class="mobile-menu__list">
      <li><a href="/">Inicio</a></li>
      <li><a href="/servicios/">Servicios</a></li>
      <li><a href="/proyectos/">Proyectos</a></li>
      <li><a href="/blog/">Blog</a></li>
      <li><a href="/contacto/">Contacto</a></li>
    </ul>
  </nav>
</header>

El botón utiliza aria-controls para indicar qué elemento controla. El atributo aria-expanded comunica si el menú está abierto o cerrado.

Estos detalles no modifican la apariencia, pero sí ayudan a quienes navegan mediante lectores de pantalla u otras tecnologías de asistencia.

¿Por qué conviene utilizar un botón?

Un error habitual consiste en crear el activador mediante un <div> o un <span>. Aunque estos elementos pueden recibir eventos de clic, no ofrecen de forma predeterminada el comportamiento de un botón.

Un elemento <button>:

  • Puede recibir el foco mediante teclado.
  • Se activa con las teclas adecuadas.
  • Tiene una semántica reconocible.
  • Permite utilizar atributos aria.
  • No requiere recrear manualmente comportamientos nativos.

Siempre que un elemento ejecute una acción, el botón suele ser la opción correcta.

Cómo crear la apariencia inicial del menú

Empecemos definiendo algunas variables y los estilos generales del encabezado.

:root {
  --header-height: 4.5rem;
  --menu-background: #ffffff;
  --menu-text: #020101;
  --menu-accent: #cc2b5e;
  --menu-duration: 350ms;
  --menu-easing: cubic-bezier(0.22, 1, 0.36, 1);
}

*,
*::before,
*::after {
  box-sizing: border-box;
}

body {
  margin: 0;
  color: var(--menu-text);
  font-family: system-ui, sans-serif;
}

.site-header {
  position: relative;
  z-index: 20;
  display: flex;
  min-height: var(--header-height);
  align-items: center;
  justify-content: space-between;
  padding-inline: 1.25rem;
  background: #ffffff;
}

.site-logo {
  position: relative;
  z-index: 30;
  color: inherit;
  font-weight: 700;
  text-decoration: none;
}

El z-index del encabezado será importante cuando coloquemos el menú en una capa independiente.

Estilos del botón hamburguesa

El botón tendrá tres líneas que después transformaremos en una cruz.

.menu-toggle {
  position: relative;
  z-index: 30;
  display: grid;
  width: 3rem;
  height: 3rem;
  padding: 0.65rem;
  border: 0;
  background: transparent;
  cursor: pointer;
}

.menu-toggle__line {
  display: block;
  width: 100%;
  height: 2px;
  margin: auto;
  border-radius: 999px;
  background: currentColor;
  transform-origin: center;
  transition:
    transform var(--menu-duration) var(--menu-easing),
    opacity 200ms ease;
}

.menu-toggle:focus-visible {
  outline: 3px solid var(--menu-accent);
  outline-offset: 3px;
}

El estilo :focus-visible permite mostrar un indicador claro cuando el control recibe el foco mediante teclado.

No conviene eliminar el contorno con outline: none sin proporcionar una alternativa. El foco visible es esencial para saber qué elemento está activo.

Cómo animar un menú móvil con CSS mediante transform

Una de las soluciones más eficaces consiste en colocar el menú fuera de la pantalla y desplazarlo cuando se activa.

.mobile-menu {
  position: fixed;
  inset: 0 0 0 auto;
  z-index: 10;
  display: grid;
  width: min(85vw, 25rem);
  min-height: 100dvh;
  padding:
    calc(var(--header-height) + 2rem)
    2rem
    2rem;
  background: var(--menu-background);
  box-shadow: -1rem 0 3rem rgb(0 0 0 / 15%);
  transform: translateX(100%);
  visibility: hidden;
  transition:
    transform var(--menu-duration) var(--menu-easing),
    visibility 0s linear var(--menu-duration);
}

.mobile-menu.is-open {
  transform: translateX(0);
  visibility: visible;
  transition:
    transform var(--menu-duration) var(--menu-easing),
    visibility 0s linear 0s;
}

El panel empieza con translateX(100%), por lo que queda desplazado hacia la derecha. Al añadir la clase .is-open, vuelve a su posición original.

La propiedad visibility evita que los enlaces ocultos puedan recibir el foco. Su transición se retrasa durante el cierre para que el panel no desaparezca antes de completar el movimiento.

¿Por qué utilizar transform en lugar de left o right?

También podríamos animar la propiedad right:

.mobile-menu {
  right: -100%;
}

.mobile-menu.is-open {
  right: 0;
}

Visualmente podría ofrecer un resultado parecido, pero animar propiedades relacionadas con la posición y la geometría puede obligar al navegador a recalcular la distribución de la página.

En cambio, transform suele ser una opción más adecuada para el movimiento. Por este motivo, al plantear una mobile menu animation CSS, normalmente conviene priorizar:

  • transform
  • opacity

Estas propiedades permiten crear animaciones fluidas sin modificar continuamente las dimensiones o la posición calculada del documento.

Controlar la apertura del menú con JavaScript

CSS se ocupará de la animación, mientras que JavaScript cambiará el estado del componente.

const menuButton = document.querySelector(".menu-toggle");
const mobileMenu = document.querySelector(".mobile-menu");

function setMenuState(isOpen) {
  mobileMenu.classList.toggle("is-open", isOpen);
  menuButton.classList.toggle("is-active", isOpen);

  menuButton.setAttribute("aria-expanded", String(isOpen));
  menuButton.setAttribute(
    "aria-label",
    isOpen ? "Cerrar menú" : "Abrir menú"
  );

  document.body.classList.toggle("menu-open", isOpen);
}

menuButton.addEventListener("click", () => {
  const isOpen =
    menuButton.getAttribute("aria-expanded") === "true";

  setMenuState(!isOpen);
});

La función centraliza todos los cambios relacionados con el estado:

  • Añade o elimina la clase del panel.
  • Actualiza el botón.
  • Modifica aria-expanded.
  • Cambia la etiqueta accesible.
  • Añade una clase al body.

Esta última clase permite impedir que la página continúe desplazándose mientras el menú ocupa la pantalla.

body.menu-open {
  overflow: hidden;
}

Centralizar el comportamiento evita inconsistencias. Si en el futuro añadimos nuevas formas de cerrar el menú, todas podrán llamar a la misma función.

Cómo transformar el icono hamburguesa en una cruz

Las líneas del botón también pueden animarse para indicar que el menú se encuentra abierto.

.menu-toggle.is-active .menu-toggle__line:nth-child(1) {
  transform: translateY(0.56rem) rotate(45deg);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(2) {
  opacity: 0;
  transform: scaleX(0);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(3) {
  transform: translateY(-0.56rem) rotate(-45deg);
}

La primera y la tercera línea se desplazan hacia el centro y rotan. La línea central desaparece mediante opacity y scaleX.

El resultado es una transición reconocible entre el icono de menú y el icono de cierre.

Ajustar la transformación sin valores frágiles

El desplazamiento de las líneas depende del tamaño del botón, del espacio disponible y de la distribución interna. Por ello, no conviene copiar valores de otro proyecto sin revisarlos.

Una alternativa más controlable consiste en posicionar las líneas de forma absoluta:

.menu-toggle {
  position: relative;
}

.menu-toggle__line {
  position: absolute;
  left: 25%;
  width: 50%;
}

.menu-toggle__line:nth-child(1) {
  top: 32%;
}

.menu-toggle__line:nth-child(2) {
  top: 50%;
  transform: translateY(-50%);
}

.menu-toggle__line:nth-child(3) {
  bottom: 32%;
}

.menu-toggle.is-active .menu-toggle__line:nth-child(1) {
  top: 50%;
  transform: translateY(-50%) rotate(45deg);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(2) {
  opacity: 0;
  transform: translateY(-50%) scaleX(0);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(3) {
  bottom: 50%;
  transform: translateY(50%) rotate(-45deg);
}

Esta solución ofrece un mayor control sobre el punto en el que las líneas se cruzan.

Animar los enlaces del menú de forma escalonada

Además del panel, podemos animar cada enlace con un pequeño retraso. Este recurso se conoce habitualmente como animación escalonada o staggered animation.

.mobile-menu__list {
  display: grid;
  gap: 0.75rem;
  margin: 0;
  padding: 0;
  list-style: none;
}

.mobile-menu__list li {
  opacity: 0;
  transform: translateX(1.25rem);
  transition:
    transform 300ms var(--menu-easing),
    opacity 300ms ease;
}

.mobile-menu.is-open .mobile-menu__list li {
  opacity: 1;
  transform: translateX(0);
}

Después podemos aplicar diferentes retrasos:

.mobile-menu.is-open .mobile-menu__list li:nth-child(1) {
  transition-delay: 80ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(2) {
  transition-delay: 120ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(3) {
  transition-delay: 160ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(4) {
  transition-delay: 200ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(5) {
  transition-delay: 240ms;
}

El desfase debe ser breve. Si cada elemento tarda demasiado en aparecer, el usuario tendrá que esperar para encontrar el enlace que necesita.

Una animación escalonada funciona mejor cuando:

  • Hay pocos elementos.
  • Los retrasos son reducidos.
  • El movimiento conserva una misma dirección.
  • El contenido continúa siendo usable con rapidez.

Utilizar una variable CSS para controlar el retraso

Podemos evitar varios selectores nth-child utilizando una variable personalizada:

<li style="--item-index: 0"><a href="/">Inicio</a></li>
<li style="--item-index: 1"><a href="/servicios/">Servicios</a></li>
<li style="--item-index: 2"><a href="/proyectos/">Proyectos</a></li>
<li style="--item-index: 3"><a href="/blog/">Blog</a></li>
<li style="--item-index: 4"><a href="/contacto/">Contacto</a></li>

.mobile-menu.is-open .mobile-menu__list li {
  transition-delay: calc(70ms + var(--item-index) * 40ms);
}

Así, la duración puede ajustarse desde un único lugar.

Añadir una capa oscura detrás del menú

Cuando el menú aparece como un panel lateral, resulta útil oscurecer el contenido situado detrás. Esta capa dirige la atención y comunica que la página principal se encuentra temporalmente inactiva.

Podemos crearla mediante un pseudoelemento:

.site-header::before {
  content: "";
  position: fixed;
  inset: 0;
  z-index: 5;
  background: rgb(0 0 0 / 45%);
  opacity: 0;
  visibility: hidden;
  transition:
    opacity var(--menu-duration) ease,
    visibility 0s linear var(--menu-duration);
}

.site-header:has(.mobile-menu.is-open)::before {
  opacity: 1;
  visibility: visible;
  transition:
    opacity var(--menu-duration) ease,
    visibility 0s linear 0s;
}

La pseudoclase :has() permite modificar el encabezado cuando contiene un menú abierto.

También podemos crear una capa independiente en el HTML. Esta alternativa resulta práctica cuando queremos cerrar el menú al pulsar fuera del panel.

<div class="menu-overlay" aria-hidden="true"></div>

.menu-overlay {
  position: fixed;
  inset: 0;
  z-index: 5;
  background: rgb(0 0 0 / 45%);
  opacity: 0;
  visibility: hidden;
  transition:
    opacity var(--menu-duration) ease,
    visibility 0s linear var(--menu-duration);
}

.menu-overlay.is-visible {
  opacity: 1;
  visibility: visible;
  transition-delay: 0s;
}

Y actualizamos JavaScript:

const menuOverlay = document.querySelector(".menu-overlay");

function setMenuState(isOpen) {
  mobileMenu.classList.toggle("is-open", isOpen);
  menuButton.classList.toggle("is-active", isOpen);
  menuOverlay.classList.toggle("is-visible", isOpen);

  menuButton.setAttribute("aria-expanded", String(isOpen));
  menuButton.setAttribute(
    "aria-label",
    isOpen ? "Cerrar menú" : "Abrir menú"
  );

  document.body.classList.toggle("menu-open", isOpen);
}

menuOverlay.addEventListener("click", () => {
  setMenuState(false);
});

Cerrar el menú con la tecla Escape

Un menú accesible debería poder cerrarse mediante la tecla Escape.

document.addEventListener("keydown", (event) => {
  if (event.key !== "Escape") {
    return;
  }

  const isOpen =
    menuButton.getAttribute("aria-expanded") === "true";

  if (isOpen) {
    setMenuState(false);
    menuButton.focus();
  }
});

Al cerrar el panel, devolvemos el foco al botón que lo abrió. De esta forma, quien navega mediante teclado no pierde su posición en la interfaz.

También puede ser conveniente cerrar el menú después de seleccionar un enlace:

mobileMenu.addEventListener("click", (event) => {
  const clickedLink = event.target.closest("a");

  if (clickedLink) {
    setMenuState(false);
  }
});

Esta medida resulta especialmente útil en páginas de una sola sección, donde los enlaces llevan a distintos puntos del mismo documento.

Animaciones alternativas para un menú móvil

El desplazamiento lateral es una solución frecuente, pero no es la única forma de animar un menú CSS.

Menú desplegable desde la parte superior

Podemos hacer que el menú aparezca debajo del encabezado.

.mobile-menu {
  position: absolute;
  top: 100%;
  right: 0;
  left: 0;
  min-height: auto;
  transform: translateY(-1rem);
  opacity: 0;
  visibility: hidden;
  transition:
    transform 250ms ease,
    opacity 250ms ease,
    visibility 0s linear 250ms;
}

.mobile-menu.is-open {
  transform: translateY(0);
  opacity: 1;
  visibility: visible;
  transition-delay: 0s;
}

Esta variante funciona bien en menús cortos que no necesitan ocupar toda la pantalla.

Menú a pantalla completa

Un menú superpuesto puede ocupar todo el viewport:

.mobile-menu {
  position: fixed;
  inset: 0;
  display: grid;
  place-items: center;
  min-height: 100dvh;
  padding: 5rem 2rem 2rem;
  background: var(--menu-background);
  opacity: 0;
  transform: scale(1.03);
  visibility: hidden;
  transition:
    opacity 300ms ease,
    transform 400ms var(--menu-easing),
    visibility 0s linear 400ms;
}

.mobile-menu.is-open {
  opacity: 1;
  transform: scale(1);
  visibility: visible;
  transition-delay: 0s;
}

El cambio de escala debe ser sutil. Una ampliación excesiva puede resultar agresiva o generar una sensación de movimiento innecesaria.

Aparición mediante clip-path

Otra opción visual consiste en revelar el menú progresivamente con clip-path.

.mobile-menu {
  position: fixed;
  inset: 0;
  clip-path: circle(0 at calc(100% - 2.5rem) 2.5rem);
  visibility: hidden;
  transition:
    clip-path 500ms var(--menu-easing),
    visibility 0s linear 500ms;
}

.mobile-menu.is-open {
  clip-path: circle(150% at calc(100% - 2.5rem) 2.5rem);
  visibility: visible;
  transition-delay: 0s;
}

Este efecto puede resultar atractivo, pero debería comprobarse en los navegadores y dispositivos incluidos en los requisitos del proyecto.

La solución más llamativa no siempre es la más adecuada. Para la mayoría de las interfaces, una transición sencilla con transform y opacity será más fácil de mantener.

Cómo respetar prefers-reduced-motion

Algunas personas reducen las animaciones en el sistema operativo porque el movimiento puede provocar molestias, mareos o dificultades de concentración.

La media query prefers-reduced-motion permite adaptar la experiencia.

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    scroll-behavior: auto !important;
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    transition-delay: 0ms !important;
  }
}

También podemos aplicar una versión más específica:

@media (prefers-reduced-motion: reduce) {
  .mobile-menu,
  .mobile-menu__list li,
  .menu-toggle__line,
  .menu-overlay {
    transition: none;
  }
}

La segunda opción evita modificar todas las animaciones del proyecto y se limita al componente.

Respetar esta preferencia no significa eliminar funcionalidad. El menú debe continuar abriéndose y cerrándose, pero sin una transición prolongada.

Adaptar el menú a escritorio

Un menú móvil no debería continuar oculto detrás de un botón cuando existe espacio suficiente para mostrar la navegación completa.

@media (min-width: 48rem) {
  .menu-toggle,
  .menu-overlay {
    display: none;
  }

  .mobile-menu {
    position: static;
    display: block;
    width: auto;
    min-height: auto;
    padding: 0;
    background: transparent;
    box-shadow: none;
    transform: none;
    visibility: visible;
  }

  .mobile-menu__list {
    display: flex;
    align-items: center;
    gap: 1.5rem;
  }

  .mobile-menu__list li {
    opacity: 1;
    transform: none;
    transition: none;
  }

  body.menu-open {
    overflow: auto;
  }
}

El punto de ruptura no debería elegirse únicamente por un dispositivo concreto. Conviene observar el momento en el que los enlaces dejan de caber cómodamente en una línea.

Un menú puede necesitar transformarse en móvil a 768 píxeles, 900 píxeles o cualquier otra anchura, dependiendo de:

  • La cantidad de enlaces.
  • La longitud de las etiquetas.
  • El tamaño del logotipo.
  • El espacio entre elementos.
  • El idioma del sitio.
  • El diseño general del encabezado.

Errores frecuentes al animar un menú móvil

Animar display: none

La propiedad display no puede interpolarse como opacity o transform.

Este código no producirá una transición gradual:

.mobile-menu {
  display: none;
  opacity: 0;
}

.mobile-menu.is-open {
  display: block;
  opacity: 1;
}

Cuando el elemento pasa de display: none a display: block, aparece directamente. Después puede aplicarse la opacidad, pero el proceso no siempre ofrece el resultado esperado.

Para controlar la interacción y la visibilidad durante una transición, podemos combinar:

  • opacity
  • transform
  • visibility
  • pointer-events

Ocultar el menú solo con opacity

Un elemento con opacity: 0 continúa ocupando espacio y puede seguir recibiendo clics o foco.

Por ello, este código es insuficiente:

.mobile-menu {
  opacity: 0;
}

Podemos reforzarlo así:

.mobile-menu {
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
}

.mobile-menu.is-open {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
}

Utilizar duraciones demasiado largas

Un menú es una herramienta funcional. El usuario quiere acceder rápidamente a otra sección.

Las transiciones de entre aproximadamente 200 y 400 milisegundos suelen ofrecer una sensación fluida sin introducir una espera evidente. No obstante, la duración adecuada dependerá del tamaño del panel y de la distancia recorrida.

Un panel que atraviesa toda la pantalla puede necesitar algo más de tiempo que un pequeño cambio de opacidad, pero rara vez requiere una animación de un segundo completo.

Sobrecargar el componente con efectos

Mover el panel, escalarlo, rotarlo, difuminarlo y animar simultáneamente todos sus enlaces puede dificultar la lectura.

Una buena regla práctica consiste en elegir:

  1. Una animación principal para el contenedor.
  2. Una transformación clara para el botón.
  3. Una animación secundaria opcional para los enlaces.

Más efectos no implican una mejor experiencia.

No comprobar la navegación mediante teclado

El menú puede parecer correcto con el ratón y presentar problemas al utilizar la tecla Tab.

Antes de darlo por terminado, conviene comprobar que:

  • El botón recibe el foco.
  • El estado del foco es visible.
  • Los enlaces ocultos no pueden enfocarse.
  • El menú puede cerrarse con Escape.
  • El foco vuelve al botón al cerrar.
  • El orden de navegación es lógico.

Prestar atención al control del foco

En un menú que ocupa toda la pantalla, puede ser recomendable mantener temporalmente el foco dentro del panel mientras permanece abierto. Esto se conoce como focus trapping.

No todos los menús desplegables necesitan comportarse como un diálogo modal. Sin embargo, cuando la navegación bloquea completamente el resto de la interfaz, conviene estudiar si el foco debería quedar limitado a sus controles.

Consejos para conseguir una animación más profesional

Mantén una dirección coherente

Si el panel entra desde la derecha, los enlaces pueden aparecer desplazándose ligeramente desde esa misma dirección. Esta coherencia ayuda a que el movimiento resulte predecible.

Utiliza una curva de aceleración adecuada

La función ease puede ser suficiente, pero una curva personalizada permite controlar mejor la sensación de movimiento.

transition-timing-function: cubic-bezier(0.22, 1, 0.36, 1);

Esta curva genera una entrada rápida que se suaviza al llegar al destino. El menú se percibe ágil sin detenerse de forma brusca.

Evita utilizar will-change permanentemente

La propiedad will-change puede avisar al navegador de que un elemento cambiará próximamente:

.mobile-menu {
  will-change: transform;
}

Sin embargo, no debería aplicarse indiscriminadamente a muchos componentes. Mantener capas optimizadas de forma permanente puede aumentar el consumo de recursos.

En un menú pequeño quizá no sea necesaria. Conviene utilizarla únicamente cuando las pruebas de rendimiento muestren una mejora real.

Prueba en dispositivos reales

Las herramientas del navegador permiten simular diferentes anchuras, pero no reproducen por completo:

  • El rendimiento de un teléfono de gama media o baja.
  • La interacción táctil.
  • La barra dinámica del navegador.
  • Los cambios de orientación.
  • El comportamiento del teclado virtual.
  • Las áreas seguras de algunos dispositivos.

Para la altura del panel, 100dvh puede adaptarse mejor a los cambios de la interfaz del navegador que el tradicional 100vh.

Lista de comprobación antes de publicar

Antes de dar por finalizado el menú hamburguesa CSS, revisa los siguientes puntos:

  • El botón es un elemento <button>.
  • Incluye aria-controls y aria-expanded.
  • El texto accesible cambia entre abrir y cerrar.
  • El menú oculto no puede recibir el foco.
  • La animación utiliza preferentemente transform y opacity.
  • El contenido no se desplaza accidentalmente al abrir el panel.
  • Existe una forma clara de cerrar el menú.
  • La tecla Escape funciona.
  • El foco es visible.
  • Se respeta prefers-reduced-motion.
  • El menú se adapta correctamente a escritorio.
  • Los enlaces tienen un área táctil suficiente.
  • La duración de la transición no retrasa la navegación.
  • El comportamiento se ha probado con teclado y pantalla táctil.

Esta revisión permite detectar problemas que pueden pasar desapercibidos cuando solo se evalúa la apariencia visual.

Preguntas frecuentes sobre cómo animar un menú móvil con CSS

¿Es posible crear un menú móvil animado solo con CSS?

Sí. Puede utilizarse un checkbox oculto junto con un <label> y selectores como :checked para modificar el estado del menú.

No obstante, esta solución puede complicar la semántica y la actualización de atributos accesibles. En proyectos reales suele resultar más mantenible utilizar CSS para la presentación y una pequeña cantidad de JavaScript para gestionar el estado.

¿Qué propiedades CSS conviene utilizar para animar un menú?

Las propiedades más recomendables son transform y opacity. Permiten desplazar, escalar o desvanecer el menú sin depender continuamente de cambios en su geometría.

Propiedades como width, height, left, right o margin pueden utilizarse, pero suelen requerir más trabajo del navegador durante la animación. Siempre conviene comprobar el resultado con las herramientas de rendimiento.

¿Cuánto debería durar la animación de un menú hamburguesa?

La duración debe ser suficiente para que el cambio de estado se entienda, pero no tan larga como para retrasar el acceso a los enlaces.

Como referencia inicial, pueden probarse valores entre 200 y 400 milisegundos. Los efectos secundarios, como la aparición escalonada de los enlaces, deberían utilizar retrasos pequeños para evitar que la navegación se sienta lenta.

El movimiento debe acompañar a la navegación, no competir con ella

Aprender cómo animar un menú móvil con CSS implica algo más que elegir un efecto llamativo. El componente debe ser comprensible, rápido, accesible y fácil de mantener.

Una animación lateral mediante transform, acompañada de una capa de fondo y una transformación sencilla del botón, suele ser suficiente para crear una experiencia clara. A partir de esa base pueden añadirse detalles como la entrada escalonada de los enlaces, siempre que no retrasen la interacción.

También es importante recordar que el menú es una de las principales vías de acceso al contenido. Si su apertura resulta confusa, si los enlaces ocultos reciben el foco o si el movimiento genera molestias, la animación deja de cumplir su función.

La mejor animación no es necesariamente la más compleja. Es aquella que hace visible el cambio de estado sin obligar al usuario a pensar en el propio efecto. Cuando el movimiento acompaña de forma natural a la navegación, el diseño se percibe más cuidado y la interfaz resulta más fácil de utilizar.

Emails accesibles: contraste, jerarquía y lectores de pantalla

Posted on by marta

La accesibilidad email no debería verse como un añadido técnico que se incorpora al final, cuando la newsletter ya está diseñada, maquetada y aprobada. En realidad, debería formar parte del proceso desde el primer boceto. Un email accesible es un email que se puede leer, entender y utilizar con menos esfuerzo, tanto por personas con discapacidad visual, motriz o cognitiva como por cualquier usuario que abre el correo en un móvil pequeño, con poca luz, con prisa o con las imágenes bloqueadas.

Cuando hablamos de newsletters accesibles, solemos pensar en lectores de pantalla, textos alternativos o normas WCAG. Todo eso importa, por supuesto. Pero la accesibilidad empieza mucho antes: en el contraste entre texto y fondo, en la jerarquía visual, en el tamaño de la tipografía, en la claridad de los enlaces, en el orden de lectura y en la forma en la que estructuramos el contenido.

Un email puede ser visualmente bonito y, aun así, resultar difícil de leer. También puede estar técnicamente bien maquetado, pero ser confuso para quien navega con tecnologías de asistencia. Por eso, diseñar emails accesibles no consiste solo en “cumplir una checklist”, sino en tomar mejores decisiones de comunicación.

Si estás empezando a trabajar con emails responsive, también puede interesarte leer qué es MJML y por qué facilita la maquetación de emails responsive, porque muchas decisiones de accesibilidad también dependen de cómo estructuramos el HTML del correo desde el principio.

Qué significa crear emails accesibles

Crear emails accesibles significa diseñar y desarrollar mensajes que puedan ser consumidos por el mayor número posible de personas, independientemente de sus capacidades, contexto o dispositivo. En email marketing, esto es especialmente importante porque el entorno es muy fragmentado: Gmail, Outlook, Apple Mail, Yahoo, clientes móviles, modo oscuro, imágenes bloqueadas, zoom de texto y distintas configuraciones de accesibilidad.

A diferencia de una web, donde tenemos algo más de control sobre HTML, CSS y JavaScript, en email development trabajamos con muchas limitaciones. Algunos clientes eliminan estilos, otros interpretan mal ciertas propiedades CSS y otros tienen un soporte irregular para atributos avanzados. Por eso, la accesibilidad en email debe apoyarse en una idea fundamental: hacerlo simple, robusto y legible.

Las WCAG del W3C son una de las referencias principales para entender los criterios de accesibilidad digital. Aunque están pensadas para contenido web en general, muchos de sus principios son perfectamente aplicables al email: que el contenido sea perceptible, operable, comprensible y robusto.

En la práctica, una newsletter accesible debe permitir que la persona usuaria pueda leer el contenido sin forzar la vista, entender qué información es prioritaria, identificar claramente botones y enlaces, navegar el email con lector de pantalla y acceder a una versión funcional aunque las imágenes no carguen.

La accesibilidad no resta diseño. Al contrario: mejora el diseño porque obliga a tomar decisiones más claras.

Contraste en emails: el primer filtro de legibilidad

El contraste es uno de los aspectos más importantes de la accesibilidad email. Si el texto no se distingue bien del fondo, el mensaje falla desde el principio. No importa que el copy esté muy trabajado, que el CTA sea persuasivo o que la newsletter tenga una composición preciosa: si cuesta leer, se pierde impacto.

Por qué el contraste no es solo una cuestión estética

Muchas veces se eligen colores por identidad visual, tendencia o armonía gráfica. Eso está bien, pero en email hay que ir un paso más allá. Un color corporativo puede funcionar muy bien como acento visual y, al mismo tiempo, no ser adecuado para texto pequeño sobre fondo claro. Un gris suave puede parecer elegante en una maqueta, pero volverse ilegible en una pantalla con bajo brillo.

Las WCAG recomiendan una relación de contraste mínima de 4.5:1 para texto normal y 3:1 para texto grande en nivel AA. Para componentes visuales importantes, como bordes de botones o iconos funcionales, el criterio de contraste no textual apunta a una relación mínima de 3:1 frente al color adyacente. Puedes comprobar combinaciones concretas con herramientas como el Contrast Checker de WebAIM.

Esto no significa que todos los emails tengan que ser en blanco y negro. Significa que debemos comprobar que las combinaciones elegidas funcionan. La accesibilidad visual no elimina la personalidad de marca; simplemente evita que la estética se imponga sobre la lectura.

Errores comunes de contraste en newsletters

Uno de los errores más habituales es usar gris claro sobre blanco para textos secundarios. En una landing puede parecer sutil; en un email, especialmente en móvil, puede convertirse en una barrera. Otro error frecuente es colocar texto blanco sobre imágenes sin añadir una capa de contraste suficiente. La imagen puede tener zonas claras y oscuras, y el texto puede quedar bien en una parte pero desaparecer en otra.

También conviene revisar los botones. Un CTA con fondo de color y texto blanco puede parecer correcto, pero no siempre cumple contraste. Lo mismo ocurre con botones secundarios que solo tienen borde: si el borde es demasiado tenue, algunas personas no identificarán el elemento como interactivo.

Este punto conecta muy bien con el diseño de interfaces en general. Si te interesa profundizar en cómo la accesibilidad afecta a patrones habituales de producto digital, puedes leer también el artículo sobre componentes UI accesibles.

Recomendación práctica para contraste

Una buena regla de trabajo es definir una pequeña paleta accesible para email. No hace falta complicarla demasiado, pero sí conviene tener claro qué colores se usan para texto principal, titulares, fondos, botones y elementos secundarios.

  • Un color principal para titulares y texto importante.
  • Un color de cuerpo con contraste alto.
  • Un color de fondo claro y seguro.
  • Un color de CTA validado.
  • Un color secundario que no se use para texto crítico si no cumple contraste.

En lugar de improvisar colores en cada campaña, conviene tener un pequeño sistema. Esto reduce errores, acelera la producción y hace que las newsletters accesibles sean más consistentes.

Jerarquía visual: guiar sin saturar

La jerarquía visual es la forma en que organizamos la información para que el lector entienda qué mirar primero, qué es secundario y qué acción debe realizar. En email, la jerarquía es todavía más importante porque la atención suele ser breve. Muchas personas escanean el mensaje antes de decidir si lo leen completo.

Una buena jerarquía no depende solo del tamaño de letra. También intervienen el peso tipográfico, el espacio, la longitud de los bloques, la posición de los elementos, la repetición de patrones y la claridad de los CTA.

El problema de las newsletters sin estructura

Un email sin jerarquía suele tener varios síntomas: titulares que no destacan, bloques de texto demasiado largos, botones que compiten entre sí, imágenes que ocupan demasiado espacio sin aportar información y enlaces dispersos sin prioridad clara.

Cuando todo parece importante, nada lo es. Y esto afecta tanto a la conversión como a la accesibilidad. Una persona con baja visión puede necesitar más esfuerzo para identificar la información clave. Una persona con dificultades cognitivas puede abandonar si el contenido parece denso o desordenado. Y una persona que utiliza lector de pantalla puede perder contexto si los encabezados no están bien planteados.

En este sentido, la jerarquía visual está muy relacionada con la carga cognitiva. Si un email exige demasiado esfuerzo para entender qué está pasando, la persona tarda más en decidir y tiene más posibilidades de abandonar. Sobre este tema, puedes ampliar con el artículo sobre la Ley de Miller y su impacto en la experiencia de usuario.

Cómo construir una jerarquía accesible en email

Una jerarquía accesible empieza con una pregunta sencilla: ¿qué necesita entender la persona en los primeros segundos?

Normalmente, una newsletter debería responder a estas cuestiones:

  • Quién envía el mensaje.
  • De qué trata.
  • Por qué me interesa.
  • Qué puedo hacer ahora.

El asunto y el preheader abren la experiencia. Después, el encabezado principal debe confirmar la promesa. A partir de ahí, el contenido debería dividirse en secciones claras, con subtítulos descriptivos y bloques breves.

Encabezado principal claro

El H1 o título visual del email debe ser directo. Evita titulares demasiado crípticos si el resto del mensaje no los aclara de inmediato. La creatividad está bien, pero la comprensión debe ir primero.

Subtítulos que ordenan el contenido

Los subtítulos ayudan a dividir bloques y permiten que una persona entienda el recorrido del email sin leer cada palabra. También ayudan a lectores de pantalla cuando la estructura HTML está correctamente definida.

CTAs visibles y específicos

Un botón con el texto “Haz clic aquí” no es tan claro como “Descargar la guía”, “Ver la colección” o “Reservar plaza”. Los enlaces deben tener sentido por sí mismos, porque algunas personas navegan saltando de enlace en enlace con tecnologías de asistencia.

La WAI recomienda que los textos de enlace sean significativos y comprensibles fuera de contexto. Puedes consultar sus recomendaciones en la guía de consejos de escritura para accesibilidad.

Menos ruido, más intención

La jerarquía accesible también implica renunciar. No todos los elementos merecen el mismo peso visual. Si una newsletter tiene tres objetivos distintos, cinco botones y diez enlaces secundarios, probablemente necesite simplificarse.

Una buena newsletter accesible no grita. Acompaña.

Lectores de pantalla: pensar en el orden real del contenido

Los lectores de pantalla transforman el contenido visual en una experiencia auditiva o navegable mediante teclado. Esto cambia por completo la forma en la que debemos pensar el email. Una persona que ve la newsletter puede interpretar columnas, colores, iconos y agrupaciones visuales. Una persona que escucha el email necesita que el orden del HTML tenga sentido.

El orden visual no siempre coincide con el orden de lectura

En email development se utilizan muchas tablas para asegurar compatibilidad. Esto no es un problema por sí mismo, pero puede convertirse en uno si el orden del código no coincide con el orden lógico del mensaje.

Por ejemplo, imaginemos una newsletter con una imagen a la izquierda y un texto a la derecha. Visualmente se entiende bien. Pero si en el HTML el contenido se organiza de forma extraña, el lector de pantalla puede anunciar primero elementos secundarios, luego el CTA y después el titular. El resultado es una experiencia confusa.

Por eso, una de las mejores prácticas es comprobar el email no solo “mirándolo”, sino también revisando el flujo de lectura. El contenido debería tener sentido incluso si se elimina el diseño visual.

Texto alternativo en imágenes

El texto alternativo es clave para que una imagen importante no se pierda cuando alguien no puede verla o cuando el cliente de correo bloquea imágenes. Las alternativas textuales comunican el propósito de imágenes, ilustraciones o gráficos a personas que no las ven o que tienen las imágenes desactivadas.

Ahora bien, no todas las imágenes necesitan el mismo tipo de alt. Una imagen decorativa puede tener alt="" para que el lector de pantalla la ignore. Una imagen informativa necesita un texto alternativo claro. Y una imagen que contiene texto importante debería evitarse siempre que sea posible: es mejor que el texto esté en HTML real.

Ejemplos de alt text en newsletters

Si una imagen muestra un producto, un buen alt podría ser:

“Bolso de piel marrón con asa corta y cierre metálico.”

Si la imagen es un banner decorativo con formas abstractas, puede llevar:

alt=""

Si la imagen anuncia una oferta con texto incrustado, lo ideal es no depender solo de la imagen. El texto “20% de descuento hasta el domingo” debería aparecer también como texto HTML dentro del email.

Cuidado con ARIA en email

En desarrollo web, ARIA puede ayudar a mejorar la accesibilidad cuando se usa correctamente. Pero en email conviene ser prudente. El soporte de atributos ARIA y técnicas avanzadas no siempre es consistente entre clientes de correo. Algunos clientes eliminan atributos por seguridad o los interpretan de forma irregular.

Por eso, en email suele ser más seguro priorizar HTML simple, estructura clara, textos visibles y enlaces descriptivos. Si un botón necesita contexto, muchas veces es mejor escribir un texto visible más claro que depender de un atributo que podría no comportarse igual en todos los clientes.

Este criterio también aplica a otros componentes digitales. Por ejemplo, en interfaces web, un icono sin texto puede parecer limpio, pero resultar ambiguo si no tiene un nombre accesible. En ese caso, puedes ver ejemplos concretos en el artículo sobre iconos sin texto, aria-hidden y nombre accesible.

Tipografía, tamaño y espaciado en newsletters accesibles

La tipografía también forma parte de la accesibilidad. Un email con buen contraste puede seguir siendo difícil de leer si usa una fuente demasiado pequeña, líneas muy largas o poco espacio entre bloques.

En newsletters, especialmente en móvil, conviene trabajar con tamaños cómodos. Para el cuerpo del texto, una base de 16 px suele ser una opción razonable. Los textos legales o notas secundarias pueden ser algo más pequeños, pero no deberían convertirse en letra microscópica. El hecho de que un contenido sea secundario no significa que pueda ser ilegible.

Longitud de línea y bloques de texto

Los párrafos largos cansan. En email, donde el usuario suele desplazarse rápido, los bloques deben ser más breves que en un artículo de blog. Esto no significa escribir de forma superficial, sino presentar la información de manera digerible.

Un patrón útil es combinar párrafos cortos, subtítulos descriptivos, listas cuando ayuden a comparar o resumir, espacio suficiente entre secciones y un CTA principal por bloque.

La accesibilidad cognitiva también importa. Una newsletter clara reduce la carga mental y facilita la toma de decisiones.

Modo oscuro y accesibilidad

El modo oscuro añade otra capa de complejidad. Algunos clientes de correo invierten colores automáticamente, otros respetan ciertos estilos y otros aplican transformaciones parciales. Esto puede afectar al contraste, a los logotipos, a los fondos y a los botones.

Por eso, si se diseña una newsletter accesible, hay que probarla también en modo oscuro. Un logo oscuro en fondo transparente puede desaparecer. Un botón con color de marca puede cambiar de forma inesperada. Una sombra o borde muy sutil puede perderse por completo.

La solución no es evitar el modo oscuro, sino diseñar con suficiente robustez: colores sólidos, bordes visibles, imágenes preparadas y contraste validado en varios escenarios. Si quieres profundizar en este tema desde una perspectiva más amplia de diseño de interfaz, puedes leer Dark mode vs Light mode: cuándo usar cada uno y cómo implementarlos.

Botones y enlaces accesibles

Los botones son una parte crítica de cualquier campaña. Si el CTA no se entiende o no se puede activar cómodamente, la newsletter pierde eficacia.

Un botón accesible debe ser fácil de identificar, tener buen contraste, un área táctil cómoda y un texto claro. En móvil, no conviene crear botones demasiado pequeños ni enlaces pegados entre sí. La precisión táctil no es igual para todo el mundo, y un diseño demasiado apretado genera errores.

Textos de enlace que sí ayudan

Los enlaces deberían explicar la acción o el destino. En lugar de escribir:

“Haz clic aquí”

Es mejor usar:

“Leer la guía completa sobre accesibilidad email”

En lugar de:

“Más información”

Puede funcionar mejor:

“Ver ejemplos de newsletters accesibles”

Este tipo de texto no solo mejora la accesibilidad. También mejora la claridad editorial, la confianza del usuario y la calidad general de la experiencia.

Checklist práctica para crear newsletters accesibles

Antes de enviar una campaña, conviene revisar algunos puntos básicos. Esta checklist no sustituye una auditoría completa, pero ayuda a evitar muchos errores frecuentes en newsletters accesibles.

Contraste y color

  • El texto principal cumple al menos contraste 4.5:1.
  • Los titulares grandes mantienen contraste suficiente.
  • Los botones tienen contraste claro entre fondo y texto.
  • Los bordes o estados visuales importantes no dependen de colores demasiado sutiles.
  • La información no se comunica solo mediante color.

Estructura y jerarquía

  • El email tiene un objetivo principal claro.
  • El titular resume bien el contenido.
  • Los subtítulos ayudan a escanear.
  • Los bloques de texto son breves.
  • Hay una prioridad visual clara entre CTA principal y enlaces secundarios.

Lectores de pantalla

  • El orden del HTML tiene sentido.
  • Las imágenes importantes tienen alt descriptivo.
  • Las imágenes decorativas tienen alt vacío.
  • Los enlaces son comprensibles fuera de contexto.
  • No se depende exclusivamente de imágenes para comunicar información importante.
  • Existe una versión de texto plano cuando sea posible.

Mobile y modo oscuro

  • El texto se lee cómodamente en móvil.
  • Los botones tienen tamaño suficiente.
  • Los enlaces no están demasiado juntos.
  • El email se revisa en modo claro y oscuro.
  • Las imágenes no pierden sentido si se bloquean.

Errores frecuentes al diseñar emails accesibles

Aunque muchas decisiones de accesibilidad parecen sencillas, es fácil cometer errores cuando se trabaja con prisas, plantillas heredadas o campañas con demasiados elementos visuales. Estos son algunos de los problemas más habituales.

Usar imágenes como si fueran texto

Una imagen con todo el mensaje dentro puede parecer cómoda desde diseño, pero suele ser una mala práctica. Si la imagen no carga, el contenido desaparece. Si alguien usa lector de pantalla, dependerá por completo del texto alternativo. Y si el usuario necesita ampliar el texto, no podrá hacerlo con comodidad.

No probar el email sin imágenes

Muchas personas abren emails con imágenes bloqueadas. Por eso, una newsletter debería seguir teniendo sentido aunque los recursos visuales no carguen. El asunto, el preheader, los titulares, los textos y los botones principales deberían funcionar por sí mismos.

Crear demasiados CTAs

Un email con demasiadas llamadas a la acción aumenta la carga cognitiva. La persona no sabe qué decisión tomar, qué botón es prioritario o qué enlace debería seguir. En accesibilidad, la claridad también es una forma de cuidado.

Depender solo del color para comunicar estados

Si una oferta, aviso o mensaje importante se comunica únicamente mediante color, algunas personas pueden no percibirlo correctamente. Es mejor combinar color con texto, iconos comprensibles o etiquetas visibles.

Preguntas frecuentes sobre accesibilidad email

1. ¿La accesibilidad email solo importa para personas que usan lectores de pantalla?

No. Los lectores de pantalla son una parte importante, pero la accesibilidad email beneficia a muchas más personas. También ayuda a usuarios con baja visión, daltonismo, dificultades cognitivas, problemas de movilidad, sensibilidad a diseños saturados o personas que leen desde dispositivos pequeños. Además, mejora la experiencia general porque hace que el mensaje sea más claro, legible y fácil de usar.

2. ¿Puedo usar imágenes con texto dentro de una newsletter accesible?

Se puede, pero no es lo ideal si ese texto es importante. Muchos clientes de correo bloquean imágenes por defecto, y las personas que usan lector de pantalla dependerán del texto alternativo. Lo más recomendable es que la información clave esté siempre en HTML real. Si usas una imagen con texto, asegúrate de repetir esa información en el contenido visible o en un alt text adecuado.

3. ¿Las newsletters accesibles tienen peor diseño?

No. Esta es una idea bastante extendida, pero equivocada. Una newsletter accesible puede ser visualmente atractiva, tener personalidad de marca y usar recursos gráficos cuidados. La diferencia está en que cada decisión visual tiene una intención: buen contraste, jerarquía clara, textos legibles, botones reconocibles y estructura comprensible. La accesibilidad no limita el diseño; lo hace más sólido.

Diseñar emails que no excluyan

Crear newsletters accesibles no consiste en convertir cada campaña en un documento rígido y sin personalidad. Consiste en recordar que detrás de cada apertura hay una persona con un contexto distinto. Algunas leerán desde un móvil en la calle. Otras tendrán las imágenes bloqueadas. Otras escucharán el contenido con un lector de pantalla. Otras necesitarán más contraste, más claridad o menos ruido visual.

La accesibilidad en email es una forma de respeto. También es una forma de eficacia. Un mensaje que se lee mejor, se entiende mejor y se puede usar mejor tiene más posibilidades de cumplir su objetivo.

Por eso, antes de enviar tu próxima campaña, merece la pena hacer una pausa y preguntarte: ¿este email se entiende si no veo las imágenes?, ¿se lee bien en una pantalla pequeña?, ¿el CTA es claro?, ¿el contraste acompaña o dificulta?, ¿la estructura ayuda o confunde?

Si la respuesta no es clara, ahí tienes una oportunidad de mejora.

Diseñar emails accesibles no es añadir una capa técnica al final. Es construir desde el principio una comunicación más clara, más inclusiva y más profesional. Y en un entorno tan competitivo como la bandeja de entrada, esa claridad puede marcar la diferencia.

Animaciones CSS y rendimiento: qué propiedades conviene animar

Posted on by marta

Las animaciones CSS pueden transformar una interfaz estática en una experiencia más clara, fluida y agradable. Un botón que responde al pasar el cursor, una tarjeta que aparece suavemente, un menú que se despliega con naturalidad o un pequeño indicador de carga pueden ayudar al usuario a entender mejor qué está ocurriendo en la pantalla.

Sin embargo, no todas las animaciones tienen el mismo coste. En CSS, animar una propiedad u otra puede marcar una diferencia enorme en el rendimiento. Hay animaciones que el navegador puede resolver de forma muy eficiente, y otras que obligan a recalcular posiciones, redibujar elementos y consumir más recursos en cada fotograma.

Por eso, cuando hablamos de animaciones CSS y rendimiento, no basta con preguntarse si una animación “queda bonita”. También conviene preguntarse: ¿qué propiedad estoy animando?, ¿cómo afecta al navegador?, ¿puede provocar saltos visuales?, ¿se sentirá fluida en móviles o dispositivos menos potentes?

En este artículo vamos a ver qué propiedades conviene animar en CSS, cuáles deberías evitar siempre que sea posible y cómo optimizar animaciones CSS para crear interfaces más suaves, accesibles y profesionales.

Por qué el rendimiento importa tanto en las animaciones CSS

Una animación mal optimizada no solo afecta a la estética de una web. También puede afectar a la experiencia de usuario, a la percepción de calidad del producto e incluso al rendimiento general de la página.

Cuando una animación va a tirones, aparece lo que muchas veces se conoce como jank: pequeños bloqueos, saltos o interrupciones visuales que hacen que el movimiento no se perciba fluido. Puede parecer un detalle menor, pero en una interfaz interactiva esos tirones generan una sensación de lentitud, descuido o falta de respuesta.

Esto es especialmente importante en:

  • Menús móviles.
  • Modales.
  • Carruseles.
  • Tarjetas interactivas.
  • Botones con estados visuales.
  • Loaders.
  • Transiciones entre vistas.
  • Animaciones al hacer scroll.
  • Microinteracciones frecuentes.

Una animación puntual puede no suponer un problema. Pero si una página tiene muchos elementos animados, o si se animan propiedades costosas, el navegador puede empezar a sufrir. Y cuando el navegador sufre, el usuario también lo nota.

La clave está en entender que una animación CSS no es solo una declaración visual. Es una instrucción que el navegador tiene que procesar muchas veces por segundo.

Cómo renderiza el navegador una animación

Para entender qué propiedades CSS conviene animar, primero hay que comprender de forma sencilla cómo trabaja el navegador cuando muestra una página.

Cuando cambias estilos en una web, el navegador puede pasar por varias fases:

  1. Style, donde calcula qué estilos se aplican a cada elemento.
  2. Layout, donde calcula tamaños, posiciones y distribución de los elementos.
  3. Paint, donde dibuja visualmente los elementos, colores, sombras, bordes, textos e imágenes.
  4. Composite, donde combina las capas ya dibujadas para mostrarlas en pantalla.

No todas las propiedades CSS activan las mismas fases. Algunas obligan al navegador a recalcular el layout. Otras requieren volver a pintar elementos. Y otras, las más eficientes para animar, pueden resolverse principalmente en la fase de composición.

Aquí está la gran diferencia.

Si animas una propiedad como width, height, top, left, margin o padding, es muy probable que el navegador tenga que recalcular el layout. Eso significa que necesita revisar cómo cambia el tamaño o la posición del elemento y cómo ese cambio afecta al resto de la página.

En cambio, si animas transform u opacity, el navegador suele poder gestionar el cambio de forma mucho más eficiente, sin recalcular toda la estructura del documento.

Dicho de forma práctica: no todas las propiedades animables CSS son igual de recomendables desde el punto de vista del rendimiento.

Las mejores propiedades para animar en CSS

Si quieres crear animaciones fluidas y optimizadas, hay dos propiedades que deberían ser tu primera opción en la mayoría de casos: transform y opacity.

transform: la propiedad estrella para animaciones CSS de alto rendimiento

transform permite modificar visualmente un elemento sin alterar el flujo normal del documento. Puedes moverlo, escalarlo, rotarlo o inclinarlo sin cambiar realmente el espacio que ocupa en el layout.

Esto la convierte en una de las propiedades más recomendables para trabajar con performance CSS animations.

Con transform puedes usar funciones como:

  • translate()
  • translateX()
  • translateY()
  • scale()
  • rotate()
  • skew()

Por ejemplo, si quieres que una tarjeta se eleve ligeramente al pasar el cursor, es mejor usar transform que modificar márgenes o posiciones.

.card {
  transition: transform 0.25s ease;
}

.card:hover {
  transform: translateY(-8px);
}

Este enfoque es más eficiente que hacer algo como esto:

.card {
  position: relative;
  top: 0;
  transition: top 0.25s ease;
}

.card:hover {
  top: -8px;
}

Aunque visualmente el resultado pueda parecer parecido, técnicamente no es lo mismo. Al animar top, el navegador puede tener que recalcular posiciones. Al animar transform, el cambio se gestiona de forma más ligera.

Cuándo usar transform

Conviene utilizar transform para:

  • Desplazar elementos.
  • Crear efectos de entrada y salida.
  • Elevar tarjetas.
  • Animar botones.
  • Escalar iconos.
  • Rotar flechas o elementos decorativos.
  • Crear pequeños efectos de profundidad.
  • Animar menús o paneles laterales.

Un menú lateral, por ejemplo, puede animarse con translateX():

.menu {
  transform: translateX(-100%);
  transition: transform 0.3s ease;
}

.menu.is-open {
  transform: translateX(0);
}

Este patrón suele ser más recomendable que modificar left, right o margin-left.

opacity: ideal para apariciones y desapariciones suaves

La segunda gran propiedad recomendada para animaciones CSS de buen rendimiento es opacity.

opacity permite controlar la transparencia de un elemento sin alterar su tamaño ni su posición. Por eso es perfecta para efectos de aparición, desaparición, transiciones suaves y cambios visuales discretos.

Un ejemplo clásico:

.tooltip {
  opacity: 0;
  transition: opacity 0.2s ease;
}

.button:hover .tooltip {
  opacity: 1;
}

Este tipo de transición es ligera, clara y muy útil para mejorar la interacción sin sobrecargar la interfaz.

Combinar opacity y transform

Muchas animaciones profesionales combinan opacity y transform. Por ejemplo, un elemento puede aparecer al mismo tiempo que se desplaza suavemente hacia su posición final.

.modal {
  opacity: 0;
  transform: translateY(16px);
  transition:
    opacity 0.25s ease,
    transform 0.25s ease;
}

.modal.is-visible {
  opacity: 1;
  transform: translateY(0);
}

Este patrón funciona muy bien para modales, tarjetas, mensajes emergentes y elementos que entran en pantalla. Además, permite que el movimiento tenga intención: el usuario percibe que algo aparece desde una dirección concreta, no simplemente que “se enciende” de golpe.

Propiedades que conviene evitar al animar

Que una propiedad sea animable no significa que sea buena idea animarla. CSS permite transicionar muchas propiedades, pero algunas tienen un coste mucho mayor que otras.

Propiedades que pueden provocar recalculo de layout

Las propiedades relacionadas con tamaño, posición y distribución suelen ser más costosas porque pueden afectar al layout de la página.

Entre ellas están:

  • width
  • height
  • min-width
  • min-height
  • max-width
  • max-height
  • top
  • right
  • bottom
  • left
  • margin
  • padding
  • border-width
  • font-size
  • line-height

Por ejemplo, si quieres agrandar un botón al pasar el cursor, podrías pensar en animar el width y el height:

.button {
  width: 160px;
  height: 48px;
  transition:
    width 0.2s ease,
    height 0.2s ease;
}

.button:hover {
  width: 172px;
  height: 54px;
}

El problema es que ese cambio puede afectar al espacio ocupado por el botón y, por tanto, al resto del layout. Una alternativa más eficiente sería usar transform: scale():

.button {
  transition: transform 0.2s ease;
}

.button:hover {
  transform: scale(1.04);
}

Visualmente el botón crece, pero sin obligar al navegador a redistribuir el documento.

Propiedades que pueden provocar repintado

También hay propiedades que no siempre recalculan layout, pero sí pueden obligar al navegador a volver a pintar partes de la pantalla.

Algunos ejemplos son:

  • background-color
  • color
  • box-shadow
  • border-color
  • filter
  • text-shadow
  • outline
  • clip-path

Esto no significa que estén prohibidas. De hecho, animar background-color o color en un botón puede ser perfectamente aceptable si el cambio es sencillo. Pero conviene entender que no suelen ser tan eficientes como transform u opacity.

Un caso especialmente delicado es box-shadow. Las sombras grandes, difuminadas o animadas pueden ser costosas, sobre todo si se aplican a muchos elementos a la vez.

Por ejemplo:

.card {
  transition: box-shadow 0.25s ease;
}

.card:hover {
  box-shadow: 0 24px 60px rgba(0, 0, 0, 0.2);
}

Este efecto puede quedar muy bien, pero si tienes una cuadrícula con muchas tarjetas y todas animan sombras complejas, el rendimiento puede resentirse.

Una alternativa sería combinar una sombra estática con un pequeño desplazamiento mediante transform:

.card {
  box-shadow: 0 12px 32px rgba(0, 0, 0, 0.12);
  transition: transform 0.25s ease;
}

.card:hover {
  transform: translateY(-6px);
}

El resultado mantiene la sensación de elevación, pero reduce el trabajo durante la animación.

Tabla práctica: qué propiedades conviene animar y cuáles no

Para simplificar la toma de decisiones, puedes usar esta guía rápida.

Propiedades recomendadas

transform

Ideal para mover, escalar, rotar o crear efectos de entrada y salida. Es la opción preferente para animaciones fluidas.

Ejemplos de uso:

transform: translateY(-8px);
transform: scale(1.05);
transform: rotate(180deg);

opacity

Ideal para mostrar u ocultar elementos de forma suave, crear fundidos y reforzar cambios de estado.

Ejemplo:

opacity: 0;
opacity: 1;

Propiedades aceptables con moderación

background-color y color

Son útiles para estados hover, botones y feedback visual. Funcionan bien en microinteracciones simples, aunque pueden requerir repintado.

.button {
  transition:
    background-color 0.2s ease,
    color 0.2s ease;
}

filter

Puede servir para efectos visuales como desenfoque, brillo o escala de grises, pero conviene usarlo con cuidado. Un blur() grande o aplicado a elementos complejos puede ser costoso.

.image {
  transition: filter 0.3s ease;
}

.image:hover {
  filter: brightness(1.1);
}

clip-path

Puede crear efectos visuales muy interesantes, pero no siempre es la opción más barata. Úsala cuando aporte valor real y prueba el rendimiento en dispositivos reales.

Propiedades que conviene evitar siempre que puedas

width y height

Evita animarlas para simular crecimiento o expansión si puedes resolverlo con transform: scale().

top, left, right y bottom

Evita usarlas para mover elementos. En su lugar, utiliza transform: translate().

margin y padding

Pueden afectar al espacio del elemento y al flujo de la página. Si solo buscas movimiento visual, usa transform.

box-shadow

No está prohibida, pero animarla puede ser costoso. Es mejor usar sombras estáticas y reforzar el efecto con transform.

Ejemplos de animaciones CSS optimizadas

Veamos algunos casos prácticos donde se puede mejorar el rendimiento cambiando la propiedad animada.

Ejemplo 1: botón con efecto hover

En lugar de agrandar el botón modificando su tamaño real, puedes usar transform.

.button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 0.85rem 1.4rem;
  border-radius: 999px;
  transition:
    transform 0.2s ease,
    opacity 0.2s ease;
}

.button:hover {
  transform: translateY(-2px);
  opacity: 0.92;
}

Este efecto es sencillo, rápido y transmite respuesta sin exagerar el movimiento.

Ejemplo 2: tarjeta que aparece en pantalla

Una tarjeta puede aparecer combinando desplazamiento y opacidad:

.card {
  opacity: 0;
  transform: translateY(24px);
  transition:
    opacity 0.35s ease,
    transform 0.35s ease;
}

.card.is-visible {
  opacity: 1;
  transform: translateY(0);
}

Este patrón es muy habitual en interfaces modernas porque aporta suavidad sin forzar cambios de layout.

Ejemplo 3: icono que rota al abrir un desplegable

Para indicar que un acordeón o menú se ha abierto, puedes rotar una flecha:

.icon {
  transition: transform 0.2s ease;
}

.accordion.is-open .icon {
  transform: rotate(180deg);
}

Es una microinteracción clara y eficiente.

Ejemplo 4: menú lateral optimizado

Un panel lateral puede moverse con translateX():

.sidebar {
  transform: translateX(-100%);
  transition: transform 0.3s ease;
}

.sidebar.is-open {
  transform: translateX(0);
}

Evitar left o margin-left en este caso ayuda a mantener la animación más fluida.

will-change: útil, pero no mágico

Cuando se habla de optimizar animaciones CSS, es habitual encontrarse con la propiedad will-change. Esta propiedad permite avisar al navegador de que un elemento va a cambiar próximamente.

Por ejemplo:

.card {
  will-change: transform;
}

A primera vista parece una solución perfecta: si vas a animar algo, se lo dices al navegador y listo. Pero no conviene usar will-change de forma indiscriminada.

will-change puede ayudar en casos concretos, pero también puede consumir más memoria y empeorar el rendimiento si se aplica a demasiados elementos o si se deja permanentemente en el CSS sin necesidad.

Cuándo usar will-change

Puede tener sentido usar will-change cuando:

  • Has detectado un problema real de rendimiento.
  • La animación afecta a un elemento importante.
  • El cambio va a ocurrir pronto.
  • Has medido que realmente mejora la experiencia.
  • No lo estás aplicando a decenas o cientos de elementos.

Cuándo evitar will-change

Es mejor evitarlo cuando:

  • La animación ya funciona bien.
  • Lo estás usando “por si acaso”.
  • Lo aplicas globalmente a muchas tarjetas, botones o imágenes.
  • No has comprobado el impacto real.
  • Lo dejas fijo en todos los estados.

Una buena regla práctica sería: primero elige bien las propiedades animadas; después mide; y solo entonces considera will-change si hace falta.

Duración, easing y percepción de rendimiento

El rendimiento técnico es importante, pero la percepción también lo es. Una animación puede estar bien optimizada y aun así sentirse lenta, pesada o molesta si la duración y la curva de aceleración no están bien elegidas.

Duraciones recomendadas

Para microinteracciones, las duraciones suelen funcionar bien entre:

  • 150ms y 250ms para botones, iconos y pequeños cambios de estado.
  • 250ms y 400ms para modales, menús y tarjetas.
  • Más de 500ms solo cuando el movimiento tiene una intención narrativa o visual muy clara.

Una animación demasiado rápida puede pasar desapercibida. Una demasiado lenta puede hacer que la interfaz se sienta torpe.

Elegir bien el easing

El valor de transition-timing-function también influye mucho. linear rara vez se siente natural para interfaces, porque los objetos en el mundo real no suelen moverse a velocidad constante desde el principio hasta el final.

Una opción sencilla y efectiva es:

transition: transform 0.25s ease;

También puedes usar curvas personalizadas:

transition: transform 0.3s cubic-bezier(0.22, 1, 0.36, 1);

La clave es que el movimiento acompañe la acción del usuario, no que compita con ella.

Animaciones CSS y accesibilidad

Optimizar animaciones CSS no solo significa mejorar la velocidad. También significa respetar a las personas usuarias.

Hay usuarios que pueden sentirse incómodos con determinados movimientos, especialmente si son bruscos, repetitivos, rápidos o afectan a grandes zonas de la pantalla. Por eso es recomendable tener en cuenta la media query prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms;
    animation-iteration-count: 1;
    transition-duration: 0.01ms;
    scroll-behavior: auto;
  }
}

También puedes crear alternativas más cuidadas, reduciendo el desplazamiento pero manteniendo pequeños cambios de opacidad o color.

@media (prefers-reduced-motion: reduce) {
  .card {
    transition: opacity 0.2s ease;
    transform: none;
  }

  .card.is-visible {
    opacity: 1;
  }
}

La accesibilidad no está reñida con el diseño. Una interfaz puede ser elegante, animada y a la vez respetuosa con las preferencias del usuario.

Cómo medir el rendimiento de tus animaciones

No conviene optimizar a ciegas. Aunque hay buenas prácticas generales, cada proyecto tiene su contexto: número de elementos, complejidad visual, imágenes, sombras, scripts, dispositivos objetivo y comportamiento del usuario.

Para comprobar si una animación funciona bien, puedes revisar:

  • Si hay tirones visibles.
  • Si el scroll se vuelve pesado.
  • Si la animación empeora en móvil.
  • Si se activan demasiadas animaciones al mismo tiempo.
  • Si hay cambios de layout inesperados.
  • Si una microinteracción se repite de forma excesiva.

Las herramientas de desarrollo del navegador pueden ayudarte a analizar qué está ocurriendo. En Chrome DevTools, por ejemplo, puedes revisar el rendimiento, observar fotogramas, detectar repintados y comprobar si una animación está provocando más trabajo del necesario.

Pero más allá de la herramienta, hay una pregunta básica que nunca falla: ¿la animación ayuda o solo decora?

Si ayuda a entender la interfaz, refuerza una acción o guía la atención, tiene sentido. Si solo añade ruido visual, quizá convenga simplificarla.

Buenas prácticas para optimizar animaciones CSS

A modo de resumen práctico, estas son algunas recomendaciones para mejorar el rendimiento de tus animaciones CSS.

Prioriza transform y opacity

Cuando puedas elegir, usa transform para movimiento y escala, y opacity para apariciones o desapariciones.

Evita animar propiedades de layout

No uses width, height, top, left, margin o padding para crear efectos visuales si puedes conseguir el mismo resultado con transform.

No animes demasiados elementos a la vez

Una animación aislada puede ser ligera. Cien elementos animándose al mismo tiempo pueden no serlo.

Cuidado con sombras y filtros

box-shadow, filter y efectos visuales complejos pueden ser útiles, pero conviene medir su impacto.

Usa transition cuando solo haya dos estados

Si el cambio es de un estado inicial a uno final, normalmente una transición es suficiente.

.element {
  transition: transform 0.25s ease;
}

Usa animation cuando necesites una secuencia

Si necesitas varios pasos, repetición o control mediante @keyframes, entonces sí tiene sentido usar animaciones CSS.

@keyframes pulse {
  0% {
    transform: scale(1);
  }

  50% {
    transform: scale(1.04);
  }

  100% {
    transform: scale(1);
  }
}

Respeta prefers-reduced-motion

No todas las personas quieren o pueden ver movimiento en pantalla. Ofrece una experiencia alternativa.

Mide antes de complicar

No añadas will-change, trucos o soluciones avanzadas sin comprobar antes si existe un problema real.

Errores comunes al animar propiedades CSS

Animar todo “porque queda moderno”

Una web no es mejor por tener más movimiento. Una animación debería tener una función: guiar, confirmar, explicar, suavizar o dar feedback.

Usar transition: all

Aunque es cómodo, transition: all puede generar problemas porque el navegador intentará transicionar cualquier propiedad que cambie.

.card {
  transition: all 0.3s ease;
}

Es mejor especificar exactamente qué propiedades quieres animar:

.card {
  transition:
    transform 0.3s ease,
    opacity 0.3s ease;
}

Esto hace que el código sea más predecible y evita animaciones accidentales.

Confundir movimiento visual con cambio de layout

Si solo quieres que algo “parezca” moverse, probablemente necesitas transform, no top, left o margin.

Crear animaciones demasiado largas

Una animación de interfaz no debería hacer esperar al usuario. Si cada interacción tarda demasiado en completarse, la experiencia se vuelve pesada.

No probar en móvil

Una animación que funciona bien en escritorio puede sentirse lenta en un móvil de gama media o baja. Por eso es importante probar en dispositivos reales siempre que sea posible.

Preguntas frecuentes sobre animaciones CSS y rendimiento

¿Qué propiedades CSS conviene animar para mejorar el rendimiento?

Las propiedades más recomendadas son transform y opacity. transform es ideal para mover, escalar o rotar elementos, mientras que opacity funciona muy bien para apariciones y desapariciones suaves. Ambas suelen ser más eficientes porque no obligan al navegador a recalcular el layout de la página.

¿Es malo animar width y height?

No siempre es “malo”, pero sí suele ser menos recomendable desde el punto de vista del rendimiento. Animar width o height puede provocar recalculos de layout, especialmente si el elemento afecta a otros elementos de la página. Cuando el objetivo es crear una sensación visual de crecimiento, normalmente es mejor usar transform: scale().

¿Debo usar siempre will-change para optimizar animaciones CSS?

No. will-change debe usarse con cuidado y solo cuando exista una necesidad real. Aplicarlo sin medir o usarlo en demasiados elementos puede aumentar el consumo de memoria y empeorar el rendimiento. Antes de usarlo, conviene elegir bien las propiedades animadas, probar la animación y analizar si realmente hay un problema.

Movimiento con intención: la clave de una buena animación CSS

Las animaciones CSS no deberían estar ahí solo para decorar. Una buena animación tiene intención. Ayuda a entender un cambio, suaviza una interacción, guía la mirada o confirma que una acción ha ocurrido.

Desde el punto de vista del rendimiento, la mejor estrategia suele ser sencilla: animar menos, pero mejor. Elegir transform y opacity como primeras opciones, evitar propiedades que provoquen layout, usar sombras y filtros con moderación, respetar las preferencias de movimiento reducido y medir cuando algo no se siente fluido.

Optimizar animaciones CSS no significa renunciar al diseño. Significa diseñar con más criterio. Porque una interfaz bien animada no es la que más se mueve, sino la que se mueve justo lo necesario para que la experiencia sea más clara, más ligera y más humana.