Cómo crear loaders animados solo con CSS

Cuando una página necesita unos segundos para cargar datos, procesar una acción o completar una petición, el usuario debe recibir alguna señal que confirme que el sistema continúa funcionando. De lo contrario, puede pensar que la interfaz se ha bloqueado, pulsar varias veces el mismo botón o abandonar el sitio antes de que termine el proceso.

Los loaders cumplen precisamente esa función. Son pequeños indicadores visuales que comunican que existe una tarea en curso y que es necesario esperar. Aunque pueden desarrollarse mediante imágenes, SVG o JavaScript, en muchos casos es posible crear un loader CSS animado utilizando únicamente HTML y CSS.

Un círculo giratorio, una secuencia de puntos, unas barras que cambian de tamaño o una línea de progreso indeterminada pueden construirse con unas pocas propiedades, pseudoelementos y una regla @keyframes.

En esta guía veremos cómo crear diferentes loaders animados solo con CSS, cómo personalizarlos y qué medidas debemos aplicar para que sean accesibles, eficientes y coherentes con el diseño de la interfaz.

Si todavía no tienes claros los fundamentos de las transiciones y las animaciones, puedes consultar primero esta guía básica de animaciones CSS, donde se explican conceptos como transition, animation y @keyframes desde cero.

Qué es un loader CSS y para qué sirve

Un loader es un componente visual que informa de que una aplicación está realizando una operación cuyo resultado todavía no está disponible.

Puede aparecer mientras:

  • se recuperan datos de una API;
  • se envía un formulario;
  • se procesa un pago;
  • se sube un archivo;
  • se carga una nueva página;
  • se generan resultados;
  • se prepara una imagen;
  • se actualiza una sección dinámica.

El loader no acelera técnicamente la operación. Su función consiste en hacer comprensible el tiempo de espera.

Cuando el usuario recibe una respuesta visual inmediata, entiende que su acción ha sido registrada. Aunque el proceso tarde exactamente lo mismo, la experiencia resulta más clara y controlada.

Diferencias entre loader, spinner y barra de progreso

Los términos loader y spinner se utilizan a menudo como si fueran sinónimos, pero no significan exactamente lo mismo.

Un loader es cualquier indicador de carga. Puede tener forma circular, lineal, geométrica o incluso representar una pequeña ilustración.

Un spinner CSS es un tipo específico de loader basado en un movimiento giratorio. El ejemplo más habitual es un círculo con una parte del borde destacada que gira de manera continua.

Por otra parte, una barra de progreso puede ser determinada o indeterminada:

  • Una barra determinada muestra cuánto falta para completar el proceso, normalmente mediante un porcentaje.
  • Una barra indeterminada comunica que existe una operación en curso, pero no representa su duración ni su progreso exacto.

Cuando no conocemos el avance real de una tarea, no debemos mostrar un porcentaje inventado. En esos casos, resulta más apropiado utilizar un spinner, una animación de puntos o una barra indeterminada.

Qué significa crear un loader solo con CSS

Crear un loader solo con CSS significa que su representación visual y su movimiento no necesitan imágenes externas, GIF animados ni lógica JavaScript.

La animación puede construirse mediante:

  • bordes;
  • fondos;
  • transformaciones;
  • cambios de opacidad;
  • pseudoelementos;
  • retrasos de animación;
  • reglas @keyframes.

No obstante, conviene aclarar una cuestión importante: CSS puede animar el loader, pero normalmente no decide cuándo debe aparecer o desaparecer.

En una aplicación real, JavaScript, React, Vue, Angular o la tecnología utilizada en el proyecto controlará el estado de carga. CSS se encargará de la apariencia, mientras que la lógica de la aplicación determinará cuándo mostrar u ocultar el componente.

Fundamentos de una animación de carga CSS

Antes de construir los ejemplos, resulta útil conocer las piezas básicas que intervienen en cualquier animación de carga.

La estructura HTML del loader

Un loader sencillo puede partir de un único elemento:

<div class="spinner"></div>

Esta estructura puede ser suficiente para representar la parte visual, pero no comunica qué está ocurriendo a los usuarios de tecnologías de asistencia.

Una versión más completa sería la siguiente:

<div class="loader" role="status">
  <span class="loader__spinner" aria-hidden="true"></span>
  <span class="loader__text">Cargando contenido…</span>
</div>

En este ejemplo:

  • role="status" identifica el contenido como una actualización de estado;
  • aria-hidden="true" oculta el elemento decorativo a los lectores de pantalla;
  • el texto explica qué operación se está realizando.

Esta separación entre contenido y decoración permite cambiar el aspecto del loader sin perder información esencial.

Cómo funciona @keyframes

La regla @keyframes define los distintos estados que atravesará un elemento durante una animación.

Un giro completo puede declararse así:

@keyframes spin {
  to {
    transform: rotate(1turn);
  }
}

El valor 1turn equivale a una vuelta completa. También podríamos utilizar 360deg, aunque 1turn expresa de forma muy clara la intención del movimiento.

Después debemos asociar la animación al elemento:

.loader__spinner {
  animation: spin 0.8s linear infinite;
}

La propiedad abreviada animation indica:

  • spin: nombre de la animación;
  • 0.8s: duración de cada ciclo;
  • linear: velocidad constante;
  • infinite: repetición indefinida.

Propiedades principales de animation

Aunque la sintaxis abreviada es cómoda, una animación está formada por diferentes propiedades:

.elemento {
  animation-name: spin;
  animation-duration: 0.8s;
  animation-timing-function: linear;
  animation-delay: 0s;
  animation-iteration-count: infinite;
  animation-direction: normal;
  animation-fill-mode: none;
}

Para un loading CSS no siempre necesitaremos configurarlas todas. Las más habituales serán el nombre, la duración, la curva de velocidad, el retraso y el número de repeticiones.

Cómo crear un spinner CSS circular

El círculo giratorio es probablemente el tipo de loader más reconocible. Puede construirse aplicando un borde uniforme a un elemento circular y cambiando el color de uno de sus lados.

HTML del spinner

<div class="loader" role="status">
  <span class="spinner" aria-hidden="true"></span>
  <span>Cargando contenido…</span>
</div>

CSS del spinner

.loader {
  display: inline-flex;
  align-items: center;
  gap: 0.75rem;
  font-family: sans-serif;
  color: #2d2433;
}

.spinner {
  width: 2.5rem;
  height: 2.5rem;
  border: 0.3rem solid #eadde7;
  border-top-color: #cc2b5e;
  border-radius: 50%;
  animation: spinner-rotation 0.8s linear infinite;
}

@keyframes spinner-rotation {
  to {
    transform: rotate(1turn);
  }
}

La clave está en border-top-color. Como uno de los lados tiene un color diferente, el giro produce la sensación de que una sección del círculo está avanzando continuamente.

La propiedad border-radius: 50% transforma el elemento cuadrado en un círculo, mientras que transform: rotate() genera el movimiento.

Este ejemplo demuestra que no necesitamos una imagen para crear una forma reconocible. Si te interesa profundizar en este enfoque, en el artículo sobre cómo dibujar formas básicas con CSS encontrarás más ejemplos de círculos, triángulos, óvalos y otras figuras construidas únicamente con estilos.

Personalizar el spinner mediante variables CSS

Cuando un loader se utiliza en diferentes secciones, es recomendable definir sus principales características mediante propiedades personalizadas.

.spinner {
  --loader-size: 2.5rem;
  --loader-width: 0.3rem;
  --loader-color: #cc2b5e;
  --loader-track: #eadde7;
  --loader-speed: 0.8s;

  width: var(--loader-size);
  height: var(--loader-size);
  border: var(--loader-width) solid var(--loader-track);
  border-top-color: var(--loader-color);
  border-radius: 50%;
  animation: spinner-rotation var(--loader-speed) linear infinite;
}

Ahora podemos crear variantes modificando únicamente las variables:

.spinner--small {
  --loader-size: 1.25rem;
  --loader-width: 0.2rem;
}

.spinner--large {
  --loader-size: 4rem;
  --loader-width: 0.45rem;
  --loader-speed: 1.1s;
}

.spinner--secondary {
  --loader-color: #753a88;
}

Este sistema facilita la reutilización del componente y reduce la duplicación de estilos.

También permite adaptar el spinner a distintos contextos, como un botón pequeño, una pantalla completa o una tarjeta que actualiza su contenido.

Cómo crear un loader de puntos animados

Los puntos secuenciales funcionan especialmente bien en botones, mensajes, chats o espacios reducidos donde un spinner circular podría ocupar demasiado espacio.

Estructura HTML

<div class="loader-dots" role="status">
  <span class="loader-dots__animation" aria-hidden="true">
    <span></span>
    <span></span>
    <span></span>
  </span>

  <span class="visually-hidden">Cargando resultados…</span>
</div>

La animación se marca como decorativa y el texto permanece disponible para los lectores de pantalla.

Estilos de los puntos

.loader-dots__animation {
  display: inline-flex;
  align-items: center;
  gap: 0.4rem;
}

.loader-dots__animation span {
  width: 0.65rem;
  height: 0.65rem;
  background-color: #cc2b5e;
  border-radius: 50%;
  animation: dot-pulse 1.2s ease-in-out infinite;
}

.loader-dots__animation span:nth-child(2) {
  animation-delay: 0.15s;
}

.loader-dots__animation span:nth-child(3) {
  animation-delay: 0.3s;
}

@keyframes dot-pulse {
  0%,
  80%,
  100% {
    transform: scale(0.65);
    opacity: 0.4;
  }

  40% {
    transform: scale(1);
    opacity: 1;
  }
}

Cada punto utiliza la misma animación, pero comienza en un momento diferente gracias a animation-delay.

Este pequeño desfase crea una secuencia continua sin necesidad de definir tres animaciones distintas.

Ocultar el texto solo visualmente

Cuando no queremos mostrar el mensaje junto al loader, podemos ocultarlo visualmente sin eliminarlo del árbol de accesibilidad:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  white-space: nowrap;
  border: 0;
  clip-path: inset(50%);
}

No deberíamos utilizar display: none para este texto, ya que dejaría de estar disponible para las tecnologías de asistencia.

Cómo crear un loader de barras con CSS

Otra alternativa consiste en animar varias barras verticales. Este patrón puede recordar a un ecualizador y resulta adecuado para interfaces relacionadas con audio, procesamiento o análisis de datos.

HTML del loader

<div class="loader-bars" role="status">
  <span class="loader-bars__animation" aria-hidden="true">
    <span></span>
    <span></span>
    <span></span>
    <span></span>
  </span>

  <span class="visually-hidden">Procesando información…</span>
</div>

CSS de las barras animadas

.loader-bars__animation {
  display: inline-flex;
  align-items: center;
  gap: 0.25rem;
  height: 2rem;
}

.loader-bars__animation span {
  width: 0.35rem;
  height: 100%;
  background-color: #753a88;
  border-radius: 999px;
  transform-origin: center;
  animation: bar-scale 1s ease-in-out infinite;
}

.loader-bars__animation span:nth-child(2) {
  animation-delay: 0.1s;
}

.loader-bars__animation span:nth-child(3) {
  animation-delay: 0.2s;
}

.loader-bars__animation span:nth-child(4) {
  animation-delay: 0.3s;
}

@keyframes bar-scale {
  0%,
  100% {
    transform: scaleY(0.35);
    opacity: 0.5;
  }

  50% {
    transform: scaleY(1);
    opacity: 1;
  }
}

En lugar de modificar directamente la altura de las barras, utilizamos transform: scaleY().

Visualmente, el resultado es similar a cambiar height, pero mantenemos intacto el espacio que ocupa cada elemento dentro del documento.

Cómo crear una barra de carga indeterminada

Cuando el loader debe ocupar un espacio horizontal, podemos crear una línea que se desplace dentro de un contenedor.

Este patrón es apropiado cuando queremos comunicar actividad sin representar un porcentaje exacto.

Marcado HTML

<div class="loading-section" role="status">
  <div class="loading-bar" aria-hidden="true"></div>
  <p>Cargando los datos solicitados…</p>
</div>

Estilos CSS

.loading-section {
  width: min(100%, 24rem);
  font-family: sans-serif;
  color: #2d2433;
}

.loading-bar {
  position: relative;
  width: 100%;
  height: 0.5rem;
  overflow: hidden;
  background-color: #eadde7;
  border-radius: 999px;
}

.loading-bar::before {
  content: "";
  position: absolute;
  inset: 0 auto 0 0;
  width: 40%;
  background-color: #cc2b5e;
  border-radius: inherit;
  transform: translateX(-125%);
  animation: loading-progress 1.4s ease-in-out infinite;
}

@keyframes loading-progress {
  to {
    transform: translateX(350%);
  }
}

El contenedor oculta todo lo que sobresale mediante overflow: hidden. El pseudoelemento comienza fuera del extremo izquierdo y atraviesa la barra utilizando translateX().

Este loader comunica que una tarea está activa, pero no muestra un avance real. Por ese motivo, no debemos presentarlo como si fuera una barra de progreso determinada.

Crear un loader con pseudoelementos

Los pseudoelementos ::before y ::after permiten generar formas adicionales sin incorporar más etiquetas al HTML.

Podemos utilizarlos para crear un loader con dos anillos que giren en direcciones distintas:

<div class="double-spinner" role="status">
  <span class="visually-hidden">Cargando aplicación…</span>
</div>
.double-spinner {
  position: relative;
  width: 3.5rem;
  height: 3.5rem;
}

.double-spinner::before,
.double-spinner::after {
  content: "";
  position: absolute;
  border-radius: 50%;
}

.double-spinner::before {
  inset: 0;
  border: 0.3rem solid transparent;
  border-top-color: #cc2b5e;
  border-right-color: #cc2b5e;
  animation: outer-rotation 1s linear infinite;
}

.double-spinner::after {
  inset: 0.65rem;
  border: 0.25rem solid transparent;
  border-bottom-color: #753a88;
  animation: inner-rotation 0.75s linear infinite reverse;
}

@keyframes outer-rotation {
  to {
    transform: rotate(1turn);
  }
}

@keyframes inner-rotation {
  to {
    transform: rotate(1turn);
  }
}

Aunque el diseño utiliza dos formas, el HTML solo necesita un contenedor. Los pseudoelementos se reservan para la parte puramente decorativa.

Este mismo recurso puede emplearse para construir otros elementos de interfaz. En la guía sobre cómo dibujar iconos sencillos con CSS sin utilizar SVG ni imágenes puedes ver cómo combinar bordes, transformaciones y pseudoelementos para crear gráficos ligeros.

Accesibilidad en los loaders animados

Un loader no debería ser únicamente un elemento que se mueve. Si el estado de carga solo se comunica visualmente, algunas personas no sabrán que la interfaz está procesando información.

Añadir un mensaje de estado

La solución más clara consiste en acompañar el loader con un texto:

<div class="loader" role="status">
  <span class="spinner" aria-hidden="true"></span>
  <span>Cargando productos…</span>
</div>

El mensaje debería describir la acción cuando resulte útil:

  • “Cargando productos…”
  • “Enviando formulario…”
  • “Procesando el pago…”
  • “Preparando el archivo…”
  • “Actualizando resultados…”

Un mensaje específico suele resultar más informativo que un “Cargando…” genérico.

Utilizar role="status"

El rol status identifica una actualización que puede anunciarse sin desplazar el foco del usuario.

El elemento visual puede llevar aria-hidden="true" para evitar información innecesaria:

<span class="spinner" aria-hidden="true"></span>

No es necesario describir que existe un círculo de color girando. Lo importante es comunicar que la operación continúa.

Indicar que una región está ocupada

Cuando una sección concreta se está actualizando, puede utilizarse aria-busy="true" en el contenedor correspondiente:

<section class="results" aria-busy="true">
  <div class="loader" role="status">
    <span class="spinner" aria-hidden="true"></span>
    <span>Cargando resultados…</span>
  </div>
</section>

Cuando termina la operación, la aplicación debe actualizar el atributo:

<section class="results" aria-busy="false">
  <!-- Contenido cargado -->
</section>

Este cambio normalmente requerirá JavaScript o la lógica del framework utilizado.

La accesibilidad no debe añadirse al final como una corrección aislada. Conviene plantearla desde el momento en el que diseñamos el componente. En el artículo sobre componentes UI accesibles encontrarás más recomendaciones para crear interfaces comprensibles mediante HTML semántico, estados visibles y compatibilidad con distintas formas de interacción.

Respetar prefers-reduced-motion

Algunas personas configuran su dispositivo para reducir las animaciones. Por ese motivo, un loader CSS animado debería tener en cuenta la media query prefers-reduced-motion.

Podemos detener las animaciones y mantener el mensaje visible:

@media (prefers-reduced-motion: reduce) {
  .spinner,
  .loader-dots__animation span,
  .loader-bars__animation span,
  .loading-bar::before,
  .double-spinner::before,
  .double-spinner::after {
    animation: none;
  }
}

En este contexto, el indicador permanece estático mientras el texto continúa informando del proceso.

También podríamos sustituir el movimiento continuo por un cambio visual más discreto. Sin embargo, para un componente tan funcional como un loader, detener la animación suele ser una solución sencilla y comprensible.

Lo importante es que la información no dependa exclusivamente del movimiento. Aunque la animación se detenga, el usuario debe poder saber que existe una operación en curso.

Rendimiento de una animación de carga CSS

Los loaders suelen repetirse indefinidamente mientras dura una operación. Por tanto, una animación mal planteada puede consumir recursos durante todo el periodo de espera.

Siempre que sea posible, conviene priorizar:

  • transform;
  • opacity.

Estas propiedades permiten crear giros, desplazamientos, escalados y pulsaciones sin modificar directamente la geometría del documento.

Propiedades que conviene evitar

Animar propiedades como width, height, top, left, margin o padding puede obligar al navegador a recalcular posiciones y dimensiones durante la animación.

Por ejemplo, podríamos cambiar la altura de una barra de esta forma:

@keyframes inefficient-bar {
  from {
    height: 0.5rem;
  }

  to {
    height: 2rem;
  }
}

Sin embargo, podemos obtener un resultado visual parecido mediante una transformación:

@keyframes efficient-bar {
  from {
    transform: scaleY(0.25);
  }

  to {
    transform: scaleY(1);
  }
}

El segundo planteamiento mantiene intacto el espacio reservado por el elemento y evita que el resto del contenido tenga que adaptarse a una altura cambiante.

No abusar de will-change

La propiedad will-change puede avisar al navegador de que una característica va a modificarse:

.spinner {
  will-change: transform;
}

Sin embargo, no debería aplicarse automáticamente a todos los elementos animados.

Mantener demasiadas optimizaciones activas puede aumentar el consumo de recursos. En un spinner pequeño, el navegador suele gestionar correctamente una transformación sencilla sin necesidad de añadir will-change.

Retirar el loader cuando deja de ser necesario

Ocultar visualmente un loader no siempre significa que su animación se haya detenido. Si el elemento permanece activo, podría continuar ejecutándose aunque ya no resulte visible.

Lo recomendable es:

  • retirar el componente cuando termina la operación;
  • detener la animación si el loader queda fuera de uso;
  • evitar mantener indicadores de carga permanentes;
  • comprobar que no existen varios loaders ejecutándose sin necesidad.

Cómo elegir la duración y el movimiento adecuados

La velocidad influye directamente en la percepción del componente.

Un spinner excesivamente rápido puede parecer nervioso, mientras que uno demasiado lento puede transmitir que la aplicación está bloqueada.

Como punto de partida, podemos utilizar estos intervalos:

  • entre 0.7s y 1.2s para un spinner circular;
  • entre 1s y 1.5s para una secuencia de puntos;
  • entre 1.2s y 2s para una barra indeterminada.

No se trata de reglas absolutas. La duración debe ajustarse al tamaño del componente, al tipo de movimiento y al lenguaje visual de la interfaz.

Utilizar una curva de velocidad coherente

Para una rotación continua, linear suele ser una buena elección:

animation: spinner-rotation 0.8s linear infinite;

Como no existe un principio ni un final perceptible entre las vueltas, mantener una velocidad constante evita cambios bruscos.

Para puntos, escalados o barras que suben y bajan, una curva como ease-in-out crea una aceleración más gradual:

animation: dot-pulse 1.2s ease-in-out infinite;

No existe una curva universal para todos los loaders. Debemos elegirla en función del tipo de movimiento que queremos representar.

Cuándo mostrar un loader y cuándo evitarlo

No todas las acciones necesitan una animación de carga.

Si una respuesta es prácticamente inmediata, mostrar un loader durante una fracción de segundo puede provocar un destello innecesario. En estos casos, suele ser preferible esperar un pequeño intervalo antes de mostrarlo.

Este retraso no se controla necesariamente desde CSS, ya que depende de la lógica de la aplicación. La idea consiste en mostrar el indicador únicamente cuando la espera empieza a ser perceptible.

También debemos evitar loaders que permanezcan indefinidamente sin ofrecer ninguna salida. Cuando una operación puede fallar, la interfaz debería contemplar:

  • un límite de espera;
  • un mensaje de error;
  • una opción para volver a intentarlo;
  • una forma de cancelar el proceso, cuando sea posible.

El loader comunica actividad, pero no reemplaza la gestión de errores.

Cuándo CSS puede quedarse corto

Para un spinner, unos puntos o una barra indeterminada, CSS suele ser suficiente. Sin embargo, las animaciones más complejas pueden requerir control sobre secuencias, pausas, eventos o líneas temporales.

En esos casos, una biblioteca de animación puede ofrecer un control más preciso. Puedes consultar esta introducción a las animaciones web con GSAP para conocer una alternativa basada en JavaScript.

Esto no significa que debamos utilizar una biblioteca para cualquier loader. Para un indicador de carga sencillo, CSS suele ser la opción más directa y fácil de mantener.

Errores frecuentes al crear loaders con CSS

Utilizar demasiados elementos HTML

Algunos loaders incluyen numerosas etiquetas para dibujar formas que podrían resolverse mediante bordes o pseudoelementos.

No es obligatorio reducir siempre el HTML al mínimo, pero conviene diferenciar entre los elementos que aportan significado y los que son puramente decorativos.

Omitir el texto de carga

Una animación sin mensaje puede ser suficiente para algunos usuarios, pero no comunica el estado de forma universal.

Siempre que el contexto no sea completamente evidente, debemos proporcionar una etiqueta visible o accesible.

Mostrar un porcentaje falso

Una animación que avanza de cero a cien y vuelve a empezar no representa un progreso real.

Si desconocemos el porcentaje completado, debemos utilizar un indicador indeterminado y evitar transmitir una precisión que la aplicación no posee.

Crear una animación demasiado llamativa

El loader debe informar, no convertirse en el protagonista de la pantalla.

Los cambios bruscos de escala, los destellos rápidos o los giros excesivos pueden distraer y empeorar la experiencia.

Bloquear toda la interfaz sin necesidad

No todas las operaciones requieren una capa superpuesta que impida interactuar con la página.

Si solo se está actualizando una sección, podemos colocar el loader dentro de esa zona y mantener disponible el resto del contenido.

Olvidar los estados de error y contenido vacío

Una interfaz no debería quedar atrapada en un estado de carga eterno.

Además del loader, debemos diseñar qué ocurrirá cuando:

  • la petición falle;
  • no existan resultados;
  • se pierda la conexión;
  • la operación tarde más de lo esperado;
  • el usuario cancele el proceso.

Preguntas frecuentes sobre loaders animados con CSS

¿Se puede crear un loader completamente sin JavaScript?

Sí. La apariencia y el movimiento pueden crearse únicamente con HTML y CSS. Un spinner, unos puntos animados o una barra indeterminada no necesitan JavaScript para funcionar visualmente.

Sin embargo, en una aplicación dinámica suele ser necesario utilizar JavaScript o la lógica de un framework para mostrar el loader al comenzar una operación y retirarlo cuando termina.

¿Qué propiedades CSS son mejores para animar un loader?

Siempre que el diseño lo permita, conviene utilizar transform y opacity.

Con ellas podemos crear rotaciones, escalados, desplazamientos y pulsaciones sin modificar directamente el tamaño o la posición calculada de los elementos.

Propiedades como width, height, top o left deberían reservarse para casos en los que no exista una alternativa razonable.

¿Cómo puedo hacer que un spinner CSS sea accesible?

El spinner visual debería marcarse como decorativo mediante aria-hidden="true" y acompañarse de un mensaje que describa el estado, como “Cargando resultados…”.

También puede utilizarse role="status" para identificar la actualización y aria-busy para indicar que una región está siendo procesada. Además, conviene respetar prefers-reduced-motion para reducir o detener la animación cuando el usuario lo haya solicitado.

Una espera bien diseñada también comunica

Crear una animación de carga CSS puede parecer un detalle menor dentro de una interfaz, pero su impacto va más allá del movimiento. Un buen loader confirma que la aplicación ha recibido una acción, reduce la incertidumbre y ayuda al usuario a interpretar lo que está ocurriendo.

La parte visual puede resolverse con muy poco código. Un borde circular, una transformación y una regla @keyframes son suficientes para construir un spinner CSS funcional.

Sin embargo, el verdadero trabajo consiste en decidir cuándo mostrarlo, cómo comunicar el estado, qué ocurrirá si la operación falla y de qué manera se adaptará a las preferencias de movimiento.

Por eso, el mejor loader no es necesariamente el más original ni el más complejo. Es aquel que aparece cuando hace falta, mantiene una animación discreta, no perjudica el rendimiento y desaparece en cuanto el contenido está preparado.

En diseño de interfaces, esperar no siempre puede evitarse. Lo que sí podemos hacer es conseguir que esa espera resulte clara, accesible y coherente.

Cómo funciona @keyframes en CSS explicado fácil

Las animaciones en CSS pueden parecer un detalle pequeño dentro de una interfaz, pero cuando están bien planteadas ayudan a que una web se sienta más fluida, clara y cuidada. Un botón que aparece suavemente, una tarjeta que entra en pantalla, un loader que gira mientras carga el contenido o un icono que llama la atención sin resultar molesto tienen algo en común: muchas veces están creados con @keyframes en CSS.

La regla @keyframes permite definir una animación paso a paso. Es decir, le indica al navegador cómo debe cambiar un elemento desde un estado inicial hasta un estado final, pasando por todos los puntos intermedios que queramos controlar.

Si ya has trabajado con transiciones o estás empezando a explorar el movimiento en interfaces, este concepto es clave para entender mejor las animaciones CSS y aplicarlas con criterio en tus proyectos.

En este artículo vamos a ver cómo funciona @keyframes en CSS, cuál es su sintaxis, qué propiedades intervienen, cuándo conviene usarlo y qué buenas prácticas deberías tener en cuenta para crear animaciones útiles, accesibles y fáciles de mantener.

Qué es @keyframes en CSS

@keyframes es una regla de CSS que se utiliza para definir los distintos estados de una animación. Su función principal es describir cómo cambia un elemento a lo largo del tiempo.

Dicho de forma sencilla, @keyframes CSS marca los pasos de una animación.

Por ejemplo, podemos hacer que un elemento pase de estar invisible a visible, que se desplace de izquierda a derecha, que cambie de tamaño, que rote, que parpadee o que combine varias transformaciones a la vez.

La estructura básica es esta:

@keyframes nombreAnimacion {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

En este caso, la animación empieza con una opacidad de 0, por lo que el elemento no se ve. Después termina con una opacidad de 1, de modo que aparece completamente visible.

Pero definir el @keyframes no es suficiente. Para que la animación se aplique a un elemento, necesitamos usar la propiedad animation.

.caja {
  animation: nombreAnimacion 1s ease-in-out;
}

Aquí estamos indicando que el elemento con clase .caja debe usar la animación llamada nombreAnimacion, que tendrá una duración de 1s y una curva de movimiento ease-in-out.

Cómo funciona @keyframes paso a paso

Para entender bien las animaciones con keyframes, conviene separar el proceso en dos partes: primero se define la animación y después se aplica al elemento.

1. Definir la animación con @keyframes

La regla @keyframes funciona como una especie de guion. Dentro de ella escribimos qué cambios queremos que ocurran durante la animación.

Podemos usar from y to cuando solo necesitamos indicar un punto inicial y un punto final.

@keyframes aparecer {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

Este ejemplo es muy común para crear un efecto de aparición suave.

También podemos escribirlo con porcentajes:

@keyframes aparecer {
  0% {
    opacity: 0;
  }

  100% {
    opacity: 1;
  }
}

Ambas versiones hacen lo mismo. from equivale a 0% y to equivale a 100%.

La ventaja de usar porcentajes es que podemos añadir pasos intermedios. Por ejemplo, podemos hacer que un elemento no solo aparezca, sino que también se mueva, crezca o rebote durante el proceso.

2. Aplicar la animación con animation

Una vez definida la animación, necesitamos aplicarla a un selector CSS.

.elemento {
  animation-name: aparecer;
  animation-duration: 1s;
  animation-timing-function: ease;
}

También podemos escribirlo de forma abreviada:

.elemento {
  animation: aparecer 1s ease;
}

La propiedad animation es un shorthand, es decir, una forma resumida de escribir varias propiedades relacionadas con la animación.

Esta separación es importante: @keyframes define qué ocurre, mientras que animation define cómo se ejecuta.

Propiedades principales de CSS animation keyframes

Para trabajar correctamente con CSS animation keyframes, no basta con conocer @keyframes. También es importante entender las propiedades que controlan cómo se reproduce la animación.

animation-name

La propiedad animation-name indica el nombre de la animación que queremos aplicar.

.elemento {
  animation-name: aparecer;
}

Ese nombre debe coincidir con el nombre definido en @keyframes.

@keyframes aparecer {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

Si el nombre no coincide, la animación no funcionará. Este es uno de los errores más habituales cuando se empieza a trabajar con keyframes CSS.

animation-duration

animation-duration define cuánto dura la animación.

.elemento {
  animation-duration: 2s;
}

Puede expresarse en segundos (s) o milisegundos (ms).

.elemento {
  animation-duration: 500ms;
}

Una duración demasiado corta puede pasar desapercibida. Una duración demasiado larga puede resultar pesada. En interfaces web, muchas microinteracciones suelen funcionar bien entre 150ms y 500ms, aunque depende del tipo de efecto y del contexto.

Por ejemplo, no es lo mismo animar el hover de un botón que una entrada de contenido más elaborada. En el primer caso, una duración breve suele ser suficiente. En el segundo, puede tener sentido usar un tiempo algo mayor.

animation-timing-function

La propiedad animation-timing-function controla la velocidad de la animación a lo largo del tiempo.

.elemento {
  animation-timing-function: ease-in-out;
}

Algunos valores frecuentes son:

  • linear: mantiene una velocidad constante.
  • ease: empieza suave, acelera y termina suave.
  • ease-in: empieza lento y acelera.
  • ease-out: empieza rápido y termina lento.
  • ease-in-out: empieza y termina suavemente.

También se puede usar cubic-bezier() para crear una curva personalizada.

.elemento {
  animation-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
}

Este nivel de control es útil cuando queremos que el movimiento tenga una sensación más natural.

animation-delay

animation-delay permite retrasar el inicio de la animación.

.elemento {
  animation-delay: 1s;
}

Esto significa que la animación empezará un segundo después de que se aplique.

Es especialmente útil cuando queremos animar varios elementos de forma escalonada, por ejemplo, una lista de tarjetas que aparece una detrás de otra.

.card:nth-child(1) {
  animation-delay: 0ms;
}

.card:nth-child(2) {
  animation-delay: 120ms;
}

.card:nth-child(3) {
  animation-delay: 240ms;
}

Este recurso puede ayudar a crear una sensación de continuidad, siempre que no se abuse de él.

animation-iteration-count

animation-iteration-count define cuántas veces se repite la animación.

.elemento {
  animation-iteration-count: 3;
}

Si queremos que se repita indefinidamente, usamos infinite.

.loader {
  animation: girar 1s linear infinite;
}

Este valor se utiliza mucho en loaders, iconos animados o efectos decorativos en bucle.

Aun así, conviene usarlo con moderación. Una animación infinita puede ser útil cuando informa de que algo está cargando, pero puede resultar molesta si se utiliza solo como recurso decorativo.

animation-direction

animation-direction indica la dirección en la que se reproduce la animación.

.elemento {
  animation-direction: alternate;
}

Algunos valores posibles son:

  • normal: la animación va de principio a fin.
  • reverse: la animación se reproduce al revés.
  • alternate: alterna entre ida y vuelta.
  • alternate-reverse: alterna, pero empieza al revés.

Esto resulta muy útil para animaciones que deben ir y volver, como un elemento flotando suavemente.

animation-fill-mode

animation-fill-mode controla qué estilos conserva el elemento antes o después de la animación.

.elemento {
  animation-fill-mode: forwards;
}

El valor forwards hace que el elemento conserve el estado final de la animación.

Por ejemplo, si una tarjeta entra desde abajo y termina en su posición normal, forwards permite que se quede en esa posición al terminar.

@keyframes subir {
  from {
    transform: translateY(40px);
    opacity: 0;
  }

  to {
    transform: translateY(0);
    opacity: 1;
  }
}

.tarjeta {
  animation: subir 600ms ease-out forwards;
}

Sin forwards, el elemento podría volver a su estado inicial al finalizar la animación, algo que muchas veces no queremos.

Ejemplo práctico de @keyframes CSS

Veamos un ejemplo completo. Imagina que queremos animar una tarjeta para que aparezca suavemente desde abajo.

<div class="card">
  <h2>Animación con CSS</h2>
  <p>Esta tarjeta aparece con un movimiento suave.</p>
</div>
.card {
  max-width: 320px;
  padding: 24px;
  border-radius: 16px;
  background: #ffffff;
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.12);

  animation: entradaTarjeta 600ms ease-out forwards;
}

@keyframes entradaTarjeta {
  0% {
    opacity: 0;
    transform: translateY(32px);
  }

  100% {
    opacity: 1;
    transform: translateY(0);
  }
}

En este caso, la tarjeta empieza con opacity: 0, por lo que no se ve. Además, tiene transform: translateY(32px), así que aparece ligeramente desplazada hacia abajo.

Al llegar al 100%, la tarjeta ya es visible y vuelve a su posición natural.

Este tipo de animación es muy útil para mejorar la percepción de fluidez en una interfaz. No es una animación decorativa sin sentido: ayuda a que el contenido aparezca de una forma más amable y menos brusca.

Si estás creando interfaces con componentes reutilizables, este mismo enfoque puede combinarse con metodologías de diseño más ordenadas, como explico en el artículo sobre metodologías de desarrollo de software, especialmente cuando trabajas en proyectos donde diseño, desarrollo y experiencia de usuario deben avanzar de forma coordinada.

Usar porcentajes intermedios en @keyframes

Una de las ventajas de @keyframes CSS es que no estamos limitados a un inicio y un final. Podemos añadir tantos puntos intermedios como necesitemos.

@keyframes rebote {
  0% {
    transform: translateY(0);
  }

  30% {
    transform: translateY(-30px);
  }

  60% {
    transform: translateY(10px);
  }

  100% {
    transform: translateY(0);
  }
}

Este ejemplo crea una animación de rebote. El elemento sube, baja un poco y vuelve a su posición original.

.boton {
  animation: rebote 700ms ease-in-out;
}

Los porcentajes intermedios permiten construir animaciones más expresivas. Sin embargo, conviene usarlos con criterio. Cuantos más pasos añadimos, más compleja se vuelve la animación y más fácil es que el resultado parezca exagerado.

Cuándo usar varios pasos

Usar varios porcentajes tiene sentido cuando queremos crear una secuencia clara. Por ejemplo:

  • Un icono que rebota.
  • Un loader con varios estados.
  • Una ilustración que cambia de posición.
  • Un elemento que entra, se agranda y vuelve a su tamaño normal.
  • Un aviso que llama la atención con un pequeño movimiento.

Cuándo evitar demasiados pasos

No siempre hace falta complicar una animación. Si solo queremos suavizar un cambio entre dos estados, puede bastar con una transición o con un @keyframes muy sencillo.

La clave está en hacerse una pregunta antes de añadir movimiento: ¿esta animación ayuda a entender mejor la interfaz o solo añade ruido visual?

Diferencia entre transition y @keyframes

Una duda muy común cuando se empieza a trabajar con animaciones en CSS es cuándo usar transition y cuándo usar @keyframes.

La diferencia principal es esta:

transition suaviza el cambio entre dos estados.
@keyframes permite crear una secuencia de animación con uno o varios pasos.

Por ejemplo, si queremos que un botón cambie de color al pasar el ratón por encima, lo más lógico es usar transition.

.boton {
  background: #753a88;
  transition: background 200ms ease;
}

.boton:hover {
  background: #cc2b5e;
}

Aquí solo hay dos estados: normal y hover. Por eso transition es suficiente.

En cambio, si queremos que un icono pulse constantemente, necesitamos una animación con @keyframes.

.icono {
  animation: pulso 1.5s ease-in-out infinite;
}

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

  50% {
    transform: scale(1.12);
  }

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

Aquí no estamos simplemente pasando de un estado a otro por una interacción del usuario. Estamos creando una secuencia que se repite en el tiempo.

Regla rápida para elegir

Una forma sencilla de decidir es esta:

Si hay dos estados, usa transition.
Si hay una secuencia, repetición o control avanzado, usa @keyframes.

Esta regla no cubre todos los casos posibles, pero ayuda mucho cuando estás empezando.

También es útil relacionarlo con el diseño de experiencia de usuario. El movimiento no debería añadirse solo porque “queda bonito”, sino porque ayuda a comunicar mejor una acción o un cambio de estado. Esta idea conecta directamente con temas como el Efecto Patito de Goma aplicado al desarrollo: muchas veces, explicar qué queremos que haga una interfaz nos ayuda a elegir mejor la solución técnica.

Animaciones útiles con keyframes CSS

Las animaciones con keyframes pueden aplicarse a muchos elementos de una web. Lo importante es que tengan una intención clara.

Animación de aparición suave

@keyframes fadeIn {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

.elemento {
  animation: fadeIn 400ms ease forwards;
}

Es una de las animaciones más sencillas y más utilizadas. Sirve para mostrar contenido sin que aparezca de golpe.

Animación de entrada lateral

@keyframes slideIn {
  from {
    opacity: 0;
    transform: translateX(-40px);
  }

  to {
    opacity: 1;
    transform: translateX(0);
  }
}

.menu {
  animation: slideIn 500ms ease-out forwards;
}

Puede funcionar bien en menús, paneles, banners o bloques de contenido.

Loader giratorio

.loader {
  width: 40px;
  height: 40px;
  border: 4px solid #eeeeee;
  border-top-color: #cc2b5e;
  border-radius: 50%;
  animation: girar 800ms linear infinite;
}

@keyframes girar {
  to {
    transform: rotate(360deg);
  }
}

Este ejemplo es muy habitual para indicar que una acción está en proceso. La animación es infinita porque el loader debe seguir girando mientras se carga el contenido.

Efecto flotante

@keyframes flotar {
  0% {
    transform: translateY(0);
  }

  50% {
    transform: translateY(-12px);
  }

  100% {
    transform: translateY(0);
  }
}

.ilustracion {
  animation: flotar 3s ease-in-out infinite;
}

Este tipo de animación suele usarse en ilustraciones, iconos decorativos o elementos destacados. Debe ser suave para no cansar al usuario.

Buenas prácticas para usar @keyframes en CSS

Las animaciones pueden mejorar mucho una interfaz, pero también pueden empeorarla si se usan sin criterio. Por eso es importante aplicar algunas buenas prácticas.

Usa transform y opacity siempre que puedas

Cuando animes elementos, intenta priorizar propiedades como transform y opacity.

.elemento {
  transform: translateY(20px);
  opacity: 0;
}

Estas propiedades suelen ser más eficientes para el navegador que animar valores como width, height, top, left o margin.

Por ejemplo, en lugar de mover un elemento con top, es preferible usar transform: translate().

@keyframes moverConTop {
  from {
    top: 0;
  }

  to {
    top: 100px;
  }
}

@keyframes moverConTransform {
  from {
    transform: translateY(0);
  }

  to {
    transform: translateY(100px);
  }
}

Esto ayuda a que la animación sea más fluida y tenga mejor rendimiento.

No abuses de las animaciones infinitas

Las animaciones infinitas pueden ser útiles, pero también pueden distraer. Un loader giratorio tiene sentido porque informa al usuario de que algo está cargando. Un icono que no deja de moverse sin motivo puede resultar molesto.

Antes de usar infinite, pregúntate si la animación realmente necesita repetirse todo el tiempo.

.elemento {
  animation-iteration-count: infinite;
}

Si no aporta información o contexto, quizá es mejor evitarlo.

Cuida la accesibilidad

No todas las personas perciben el movimiento de la misma manera. Algunas animaciones pueden causar incomodidad, mareo o dificultad para concentrarse.

Por eso es buena práctica respetar la preferencia del usuario con prefers-reduced-motion.

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

También puedes desactivar animaciones concretas:

@media (prefers-reduced-motion: reduce) {
  .ilustracion {
    animation: none;
  }
}

Esto demuestra cuidado por la experiencia de todas las personas usuarias.

La accesibilidad no debería tratarse como un extra, sino como parte del propio proceso de diseño y desarrollo. Igual que cuidamos la estructura, los textos o la jerarquía visual, también deberíamos cuidar cómo se comporta el movimiento en pantalla.

Mantén nombres claros

El nombre de una animación debe explicar qué hace.

@keyframes fadeIn {
}

@keyframes slideUp {
}

@keyframes pulse {
}

Evita nombres poco descriptivos como animacion1, movimiento2 o efectoFinal.

En proyectos grandes, una nomenclatura clara ayuda mucho a mantener el CSS ordenado.

Evita animar demasiados elementos a la vez

Una página con muchas animaciones simultáneas puede parecer desordenada y afectar al rendimiento. Además, si todo se mueve, nada destaca.

La animación debe guiar la atención, no competir por ella.

Una buena práctica es reservar las animaciones para momentos concretos:

  • Entrada de contenido importante.
  • Confirmación de una acción.
  • Estados de carga.
  • Feedback visual.
  • Microinteracciones relevantes.

Errores comunes al trabajar con @keyframes CSS

Aunque @keyframes es bastante fácil de entender, hay errores frecuentes que pueden hacer que la animación no funcione como esperamos.

El nombre de la animación no coincide

.caja {
  animation: aparecerCaja 1s ease;
}

@keyframes aparecer {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

En este caso, la animación no se aplicará porque el elemento llama a aparecerCaja, pero el @keyframes se llama aparecer.

La solución es usar exactamente el mismo nombre.

.caja {
  animation: aparecer 1s ease;
}

Falta la duración

.caja {
  animation-name: aparecer;
}

Si no indicamos una duración, la animación no tendrá tiempo para ejecutarse como esperamos. Por eso siempre conviene añadir animation-duration o usar el shorthand completo.

.caja {
  animation: aparecer 1s ease;
}

El elemento vuelve a su estado inicial

Esto ocurre cuando la animación termina y no se conserva el estado final.

.caja {
  animation: subir 500ms ease;
}

Si queremos que el elemento conserve el último estado de la animación, podemos añadir forwards.

.caja {
  animation: subir 500ms ease forwards;
}

Usar animaciones donde bastaría una transición

No todo necesita @keyframes. Si solo quieres suavizar un hover, un cambio de color o una apertura sencilla, probablemente transition sea suficiente.

Usar la herramienta adecuada hace que el CSS sea más limpio y fácil de mantener.

Este mismo criterio también se puede aplicar a otros aspectos del desarrollo frontend. Por ejemplo, cuando eliges entre una solución sencilla o una más compleja en React, conviene pensar primero en el problema que quieres resolver. Si estás en esa fase de aprendizaje, puede ayudarte esta guía sobre cómo aprender React desde cero.

Ejemplo completo: botón con efecto de pulso

Veamos ahora un ejemplo completo de un botón que llama la atención con un pulso suave.

<button class="cta-button">
  Ver proyecto
</button>
.cta-button {
  padding: 14px 24px;
  border: 0;
  border-radius: 999px;
  background: #cc2b5e;
  color: #ffffff;
  font-size: 1rem;
  font-weight: 600;
  cursor: pointer;

  animation: pulsoSuave 2s ease-in-out infinite;
}

@keyframes pulsoSuave {
  0% {
    transform: scale(1);
    box-shadow: 0 0 0 0 rgba(204, 43, 94, 0.35);
  }

  70% {
    transform: scale(1.04);
    box-shadow: 0 0 0 14px rgba(204, 43, 94, 0);
  }

  100% {
    transform: scale(1);
    box-shadow: 0 0 0 0 rgba(204, 43, 94, 0);
  }
}

Este efecto puede ayudar a destacar una llamada a la acción, pero debe usarse con moderación. Si todos los botones de una web tienen animaciones infinitas, el efecto deja de ser útil y puede resultar invasivo.

Una alternativa más equilibrada sería activar la animación solo en momentos concretos o aplicarla a un único CTA principal.

@keyframes y diseño de interfaces: no todo es decoración

Uno de los errores más habituales al hablar de animaciones CSS es pensar que solo sirven para “hacer bonito”. En realidad, el movimiento puede tener una función muy importante dentro de una interfaz.

Una buena animación puede:

  • Ayudar a entender que un elemento ha aparecido o desaparecido.
  • Indicar que una acción está en progreso.
  • Guiar la atención hacia una zona concreta.
  • Reforzar una interacción.
  • Hacer que los cambios de estado sean más naturales.

Por ejemplo, cuando se abre un menú lateral, una animación de entrada puede ayudar a entender de dónde viene ese panel. Cuando aparece un mensaje de confirmación, una pequeña transición puede hacer que el cambio sea más claro. Cuando se carga contenido, un loader evita que el usuario piense que la página se ha quedado bloqueada.

La clave está en usar las animaciones con keyframes como parte de la comunicación visual, no como un adorno añadido al final.

Esto también tiene relación con el diseño UI/UX. Una herramienta como Figma puede ayudarte a pensar y prototipar estos comportamientos antes de llevarlos a código. Si te interesa esa parte del proceso, puedes ampliar con el artículo sobre pros y contras de usar Figma como herramienta de diseño UI/UX.

Cómo organizar keyframes en un proyecto CSS

En proyectos pequeños, puedes escribir los @keyframes cerca del componente o bloque donde se utilizan. Pero en proyectos más grandes, conviene mantener cierto orden.

Agrupar animaciones reutilizables

Si tienes animaciones que se repiten en varias partes del sitio, puedes crear una sección específica para ellas.

@keyframes fadeIn {
  from {
    opacity: 0;
  }

  to {
    opacity: 1;
  }
}

@keyframes slideUp {
  from {
    opacity: 0;
    transform: translateY(24px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Después puedes aplicarlas en distintos componentes.

.card {
  animation: slideUp 500ms ease-out forwards;
}

.modal {
  animation: fadeIn 300ms ease forwards;
}

Crear clases utilitarias

Otra opción es crear clases reutilizables.

.animate-fade-in {
  animation: fadeIn 400ms ease forwards;
}

.animate-slide-up {
  animation: slideUp 500ms ease-out forwards;
}

Esto puede ser útil si trabajas con una metodología de estilos más modular o si quieres aplicar animaciones de forma consistente.

Documentar las animaciones importantes

Si una animación tiene una función concreta dentro del diseño, merece la pena documentarla. No hace falta escribir una novela, pero sí dejar claro para qué sirve.

@keyframes cardEntrance {
  from {
    opacity: 0;
    transform: translateY(32px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Este tipo de organización ayuda a que otras personas del equipo entiendan por qué existe esa animación.

@keyframes en CSS y rendimiento web

El rendimiento es otro aspecto importante cuando hablamos de animaciones. Una animación puede verse muy bien en un ordenador potente, pero funcionar peor en dispositivos más antiguos o en móviles con menos recursos.

Por eso, al trabajar con @keyframes, conviene tener en cuenta tres ideas básicas.

Prioriza animaciones ligeras

Las propiedades transform y opacity suelen ser las mejores candidatas para animar porque permiten movimientos fluidos sin forzar tantos recálculos visuales.

En cambio, animar propiedades relacionadas con el layout, como width, height, top, left, margin o padding, puede generar más trabajo para el navegador.

No animes todo al cargar la página

Animar demasiados elementos al mismo tiempo puede ralentizar la experiencia inicial. Si todo entra, rebota, gira y aparece a la vez, la página pierde claridad.

Es mejor seleccionar algunos elementos clave y usar el movimiento para reforzar la jerarquía visual.

Comprueba la experiencia en móvil

Muchas veces diseñamos y probamos animaciones en escritorio, pero gran parte del tráfico llega desde móvil. Una animación que parece sutil en una pantalla grande puede resultar excesiva en una pantalla pequeña.

Por eso conviene probar siempre cómo se siente la animación en diferentes tamaños de pantalla.

Preguntas frecuentes sobre @keyframes en CSS

¿Qué diferencia hay entre @keyframes y animation en CSS?

@keyframes define los pasos de la animación, mientras que animation aplica esa animación a un elemento y controla aspectos como la duración, la repetición, el retraso o la curva de movimiento.

Dicho de otra forma: @keyframes describe qué ocurre y animation indica cómo y cuándo se ejecuta.

¿Puedo usar @keyframes para animar cualquier propiedad CSS?

Técnicamente, muchas propiedades CSS pueden animarse, pero no todas son igual de recomendables. Para obtener mejores resultados, suele ser preferible animar transform y opacity, porque ofrecen mejor rendimiento y suelen generar movimientos más fluidos.

Animar propiedades como width, height, top, left o margin puede ser más costoso para el navegador, sobre todo si se aplica a muchos elementos a la vez.

¿Cuándo debería usar @keyframes en lugar de transition?

Conviene usar @keyframes cuando necesitas una secuencia, una repetición o varios pasos intermedios. Por ejemplo, un loader giratorio, un efecto de pulso, una entrada elaborada o una animación que se repite.

En cambio, si solo quieres suavizar el cambio entre dos estados, como un hover o un menú que se abre y se cierra, probablemente sea mejor usar transition.

Cuando el movimiento también comunica

Aprender cómo funciona @keyframes en CSS es mucho más que memorizar una sintaxis. Es entender que el movimiento forma parte del diseño de una interfaz.

Una animación bien planteada no está ahí para llamar la atención porque sí. Está ahí para acompañar al usuario, explicar un cambio, suavizar una transición o reforzar una acción. Por eso, antes de añadir un efecto, conviene preguntarse qué aporta.

@keyframes CSS te da mucho control: puedes definir estados, crear secuencias, repetir movimientos y construir efectos visuales complejos sin necesidad de JavaScript. Pero ese control también requiere criterio.

Si estás empezando, quédate con esta idea: usa keyframes CSS cuando necesites controlar una animación paso a paso. Para cambios simples entre dos estados, una transition suele ser suficiente. Para secuencias, repeticiones y movimientos más elaborados, @keyframes es la herramienta adecuada.

Al final, animar bien no significa mover más cosas. Significa moverlas mejor. Y cuando el movimiento tiene intención, la interfaz se siente más clara, más fluida y mucho más cuidada.

Cómo hacer emails responsive sin volverte loca con tablas HTML

Crear emails responsive puede parecer una especie de castigo técnico si vienes del desarrollo web moderno. Estás acostumbrada a trabajar con flexbox, grid, componentes reutilizables, estilos organizados y layouts que responden con bastante elegancia. Pero, de repente, entras en el mundo del email marketing y todo cambia: aparecen las tablas HTML para email, los estilos inline, las limitaciones de Outlook y ese miedo constante a que algo se vea bien en Gmail pero se rompa en otro cliente de correo.

Y sí, es normal preguntarse: ¿de verdad seguimos usando tablas HTML para maquetar emails en pleno 2026? La respuesta es que sí, aunque con matices. Las tablas no se usan porque sean la opción más moderna ni la más cómoda, sino porque siguen siendo una de las formas más fiables de conseguir compatibilidad entre distintos clientes de correo.

La buena noticia es que no necesitas volverte loca escribiendo veinte niveles de tablas anidadas sin criterio. Hoy puedes crear emails responsive con tablas HTML de forma más ordenada, predecible y mantenible si entiendes qué papel cumple cada capa, qué CSS puedes usar con seguridad y cuándo conviene apoyarte en herramientas como MJML.

Si estás empezando en este tema, puede venirte bien complementar este artículo con la guía sobre qué es MJML y por qué facilita la maquetación de emails responsive, porque te ayudará a entender cómo simplificar parte del trabajo sin perder de vista lo que ocurre por debajo.

Por qué los emails responsive siguen usando tablas HTML

Cuando hablamos de tablas HTML en email, no hablamos de una recomendación estética. Hablamos de una solución práctica ante un entorno bastante irregular. El problema principal es que los clientes de correo no se comportan como los navegadores modernos. Gmail, Outlook, Apple Mail, Yahoo Mail y otros clientes interpretan el HTML y el CSS con diferencias importantes.

En una página web puedes crear un layout responsive con display: grid, display: flex, gap, clamp() o incluso container queries. En email, en cambio, muchas de esas decisiones pueden fallar o no comportarse igual en todos los entornos. Por eso las tablas siguen teniendo tanto peso: permiten crear una estructura base relativamente estable.

No son cómodas, no son bonitas y no son semánticamente ideales para maquetar diseño visual, pero ayudan a que el email mantenga su forma en clientes que todavía no interpretan CSS moderno de manera consistente.

La diferencia entre maquetar una web y maquetar un email

El error más común al empezar con emails responsive es intentar aplicar la misma mentalidad que usarías en una web. Pero un email no es una landing page. No tienes el mismo control sobre el entorno, no puedes asumir que todo el CSS será respetado y tampoco puedes depender de archivos externos como harías en un proyecto frontend tradicional.

En email, la pregunta no es solo: “¿este diseño queda bonito?”. La pregunta real es: “¿este diseño se mantiene suficientemente bien en la mayor cantidad posible de clientes de correo?”

Ese cambio de enfoque modifica por completo la forma de trabajar. En lugar de perseguir una maquetación perfecta al píxel, conviene pensar en sistemas robustos: una estructura sencilla, una anchura máxima razonable, columnas que puedan apilarse, botones legibles y una versión móvil que no obligue al usuario a hacer zoom.

No se trata de amar las tablas, sino de usarlas con estrategia

Las tablas HTML en email son una herramienta. Nada más. No hace falta defenderlas como si fueran modernas ni odiarlas como si fueran el enemigo absoluto. Lo importante es entender cuándo cumplen una función útil.

Una tabla puede servir como contenedor principal del email. Otra puede organizar una sección de dos columnas. Otra puede asegurar que un botón se vea correctamente en distintos clientes. El problema aparece cuando se usan tablas sin estructura, sin nombres de clases claros y sin una lógica de componentes.

Ahí es cuando el email se convierte en una maraña difícil de mantener. Pero si trabajas con una arquitectura clara, incluso una plantilla basada en tablas puede ser relativamente limpia.

La estructura base de un email responsive con tablas HTML

Antes de entrar en trucos responsive, necesitas una base sólida. Un buen email HTML suele tener tres niveles principales: el fondo general, el contenedor central y los bloques de contenido.

La idea más habitual es trabajar con un contenedor de unos 600 px de ancho máximo, porque históricamente ha sido una medida segura para muchas newsletters, campañas comerciales y emails informativos. Aunque hoy se pueden crear diseños más amplios, ese ancho sigue siendo una referencia práctica.

Ejemplo básico de estructura con tablas HTML

<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
  <tr>
    <td align="center">
      <table role="presentation" width="600" cellspacing="0" cellpadding="0" border="0">
        <tr>
          <td>
            Contenido del email
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Este ejemplo no pretende ser una plantilla final, sino mostrar la idea: una tabla exterior ocupa el ancho completo y centra una tabla interior de anchura controlada.

El contenedor exterior

El contenedor exterior suele ocupar el 100% del ancho. Sirve para definir el fondo general del email y para centrar el contenido. Esta capa es importante porque muchos clientes de correo necesitan estructuras explícitas para respetar alineaciones y fondos.

Aquí puedes aplicar un color de fondo general, por ejemplo un gris claro, y luego colocar dentro el contenido principal sobre fondo blanco. Es una estructura sencilla, pero efectiva.

El contenedor interior

El contenedor interior es el cuerpo real del email. Normalmente se define con un ancho fijo, como 600, y se complementa con estilos que permitan cierta flexibilidad en móvil.

En emails responsive es habitual combinar atributos HTML antiguos, como width="600", con CSS inline y reglas en el bloque <style>. Puede parecer redundante, pero en email la redundancia muchas veces es una forma de defensa.

Las secciones internas

Dentro del contenedor principal puedes crear secciones: cabecera, bloque hero, texto, columnas, llamada a la acción, pie de email, etc.

La clave está en no meter todo en una única tabla gigante sin separación lógica. Aunque el HTML final use tablas, tú puedes pensar en componentes: header, hero, bloque de texto, bloque de dos columnas, botón y footer.

Esa forma de pensar te ayudará a mantener el código más limpio y a reutilizar patrones. Si además estás comparando formas de trabajar, te puede interesar el artículo sobre MJML vs HTML tradicional para emails: ventajas y limitaciones, donde se ve mejor cuándo compensa escribir HTML manual y cuándo conviene automatizar parte del proceso.

Cómo hacer que las tablas HTML funcionen en móvil

El gran reto no es crear un email con tablas. El reto es conseguir que ese email sea responsive. Para eso necesitas combinar varias técnicas: anchuras fluidas, imágenes adaptables, columnas que se apilan y media queries cuando el cliente de correo las soporte.

Lo importante es no depender de una sola técnica. Una buena plantilla de email debe seguir siendo legible incluso aunque una media query no se aplique correctamente.

Usa una estructura fluida siempre que puedas

Una estrategia bastante segura es no depender exclusivamente de una media query. Puedes definir tablas con width="100%" en determinados bloques y limitar el ancho máximo del contenedor principal.

Las imágenes deberían incluir una combinación de atributo HTML y CSS inline similar a esta:

<img src="imagen.jpg" width="600" style="display:block; width:100%; max-width:600px; height:auto;" alt="Descripción de la imagen">

Esto permite que la imagen se reduzca en pantallas pequeñas sin deformarse. El atributo width ayuda a algunos clientes de correo, mientras que el CSS aporta flexibilidad.

Apila columnas en pantallas pequeñas

Uno de los patrones más habituales en emails responsive es el bloque de dos columnas. En escritorio puedes mostrar imagen y texto lado a lado. En móvil, lo más cómodo es apilar ambos elementos.

Con tablas HTML, esto suele hacerse creando dos celdas o dos tablas internas que, mediante clases y media queries, pasan a ocupar el 100% del ancho en móvil.

@media only screen and (max-width: 600px) {
  .column {
    display: block !important;
    width: 100% !important;
    max-width: 100% !important;
  }
}

Este tipo de regla permite que una estructura pensada para escritorio se adapte mejor a pantallas pequeñas. Aun así, conviene diseñar siempre con una base sencilla. Si el email solo funciona cuando todo el CSS se aplica perfectamente, probablemente sea demasiado frágil.

No dependas de una única solución responsive

Una buena plantilla de email responsive no debería romperse si una media query falla. Este es uno de los cambios de mentalidad más importantes respecto al desarrollo web tradicional.

En web solemos confiar bastante en CSS. En email, conviene diseñar para la imperfección. Eso significa que el diseño base debe ser legible incluso antes de aplicar mejoras responsive.

Si tu versión sin media queries ya es aceptable, las media queries se convierten en una mejora progresiva, no en una condición de supervivencia.

CSS en emails responsive: lo justo, lo compatible y lo necesario

El CSS en email merece un capítulo aparte. Aquí no se trata de escribir menos CSS porque sí, sino de escribir el CSS que realmente aporta valor y tiene posibilidades razonables de funcionar.

Muchas propiedades modernas pueden ser útiles en determinados clientes, pero no todas son fiables para construir la estructura principal de un email. Por eso conviene trabajar con un criterio muy claro: usar CSS moderno solo cuando haya fallback o cuando el fallo no comprometa la lectura del contenido.

Para profundizar en este punto, puedes leer también qué partes de CSS funcionan realmente en email marketing, donde se explica qué propiedades conviene usar con más prudencia.

Estilos inline: incómodos, pero necesarios

Los estilos inline siguen siendo habituales porque muchos clientes de correo los respetan mejor que los estilos externos. Esto hace que el código sea más verboso, pero también más resistente.

<td style="font-family: Arial, sans-serif; font-size:16px; line-height:24px; color:#222222;">
  Texto del email
</td>

¿Es elegante? No demasiado. ¿Es práctico? Sí.

Una forma de no volverte loca es no escribir todo a mano en producción. Puedes trabajar con herramientas que automaticen el CSS inline o con frameworks que generen el HTML final.

Media queries: útiles, pero con fallback

Las media queries son muy útiles para ajustar tamaños de fuente, apilar columnas, modificar paddings o centrar elementos en móvil. Pero no conviene usarlas como única garantía.

Un uso razonable sería:

@media only screen and (max-width: 600px) {
  .mobile-padding {
    padding-left: 20px !important;
    padding-right: 20px !important;
  }

  .mobile-center {
    text-align: center !important;
  }

  .fluid {
    width: 100% !important;
    max-width: 100% !important;
  }
}

El uso de !important es bastante común en email porque las reglas inline pueden tener más peso que las reglas declaradas en el bloque <style>. No es una práctica que trasladaríamos alegremente a una web moderna, pero en email responde a una necesidad real.

Evita CSS demasiado moderno si no tienes alternativa

Puedes usar CSS moderno en algunos contextos, pero siempre con cuidado. Flexbox, grid, variables CSS, filtros, posicionamiento complejo o animaciones pueden funcionar en algunos clientes y fallar en otros.

Si decides usarlos, que sea como mejora progresiva, no como base estructural. Para layouts principales, las tablas siguen siendo más fiables. Para detalles visuales secundarios, puedes experimentar un poco más.

Accesibilidad en emails con tablas HTML

Uno de los puntos más importantes, y a veces olvidados, es la accesibilidad. Si usas tablas para maquetar, debes evitar que los lectores de pantalla interpreten esas tablas como datos tabulares.

Para eso se utiliza role="presentation" en las tablas que cumplen una función puramente visual.

Cuándo usar role=»presentation»

Si una tabla solo sirve para colocar una imagen junto a un texto, centrar un botón o estructurar el layout del email, puedes usar:

<table role="presentation" cellspacing="0" cellpadding="0" border="0">

Esto ayuda a que la experiencia sea más limpia para personas que usan tecnologías de asistencia.

Cuándo no usarlo

Si la tabla contiene datos reales, como precios, horarios, comparativas o resultados, entonces no deberías usar role="presentation". En ese caso, la tabla sí tiene significado semántico y debe conservarlo.

La diferencia es sencilla: si la tabla organiza diseño, es presentación. Si la tabla organiza datos, es contenido.

No olvides el texto alternativo

Las imágenes en emails suelen tener mucho peso visual, pero no siempre cargan por defecto. Por eso el atributo alt es fundamental.

Un buen texto alternativo debe describir la función de la imagen, no rellenarse con palabras clave sin sentido.

<img src="newsletter-responsive.jpg" alt="Ilustración de una newsletter responsive adaptándose a móvil">

El SEO importa, pero la accesibilidad y la claridad también. Una imagen puede reforzar la comprensión del mensaje, pero el contenido esencial debería seguir siendo accesible aunque esa imagen no cargue.

Cómo simplificar el trabajo con MJML

Si tu objetivo es crear emails responsive sin pelearte constantemente con tablas HTML, MJML puede ser una gran ayuda. MJML permite escribir emails con una sintaxis más sencilla y después compilar ese código a HTML compatible con clientes de correo.

La idea es trabajar con etiquetas como <mj-section>, <mj-column>, <mj-text> o <mj-image>, en lugar de escribir manualmente toda la estructura de tablas.

Qué problema resuelve MJML

MJML no elimina las tablas del resultado final. Lo que hace es evitar que tengas que escribirlas tú manualmente en cada plantilla.

Por ejemplo, en lugar de construir una sección de dos columnas con varias tablas anidadas, puedes escribir algo más parecido a esto:

<mj-section>
  <mj-column>
    <mj-image src="imagen.jpg" alt="Imagen descriptiva" />
  </mj-column>
  <mj-column>
    <mj-text>
      Texto del email
    </mj-text>
  </mj-column>
</mj-section>

Después, MJML genera el HTML final con las tablas, estilos y ajustes necesarios.

Si quieres verlo desde un enfoque más práctico, puedes continuar con la guía sobre cómo crear tu primera newsletter responsive con MJML, donde el proceso se entiende mejor paso a paso.

Cuándo te conviene usar MJML

MJML es especialmente útil si vas a crear varias newsletters, plantillas transaccionales o campañas con estructuras repetidas. También es una buena opción si quieres mantener una lógica de componentes y evitar que cada email se convierta en un archivo imposible de leer.

No obstante, sigue siendo importante entender cómo funcionan las tablas HTML en email. Aunque uses MJML, tarde o temprano tendrás que revisar el HTML generado, corregir un comportamiento concreto o adaptar una sección a las limitaciones de un cliente de correo.

Buenas prácticas para no volverte loca con tablas HTML en email

La mejor forma de sobrevivir al desarrollo de emails responsive con tablas HTML es trabajar con método. No improvises cada plantilla desde cero.

Crea una plantilla base reutilizable

Ten una estructura inicial con contenedor exterior, contenedor central, header, bloque de contenido, botón, footer, clases responsive básicas y estilos de texto definidos.

Esto te permitirá empezar cada email desde una base probada, no desde una página en blanco. Además, te ayudará a detectar antes los errores, porque sabrás qué partes de la plantilla ya funcionan correctamente.

Trabaja por bloques, no por pantallas completas

En lugar de pensar “voy a maquetar todo el email”, piensa en bloques independientes: bloque hero, bloque texto más imagen, bloque CTA, bloque testimonios, bloque de producto o bloque footer.

Cada bloque debería poder moverse, duplicarse o eliminarse sin romper toda la plantilla. Esta forma de trabajar se parece más a una lógica de componentes, aunque el resultado final esté construido con tablas.

Prueba antes de enviar

No basta con abrir el HTML en el navegador. Un email puede verse perfecto en Chrome y fallar en Outlook. Siempre que sea posible, prueba en distintos clientes o utiliza herramientas específicas de testing.

Como mínimo, revisa Gmail en escritorio, Gmail en móvil, Apple Mail, Outlook, modo oscuro, imágenes bloqueadas y vista móvil real.

Reduce la ambición visual

Un email no necesita comportarse como una web completa. A veces, cuanto más complejo es el diseño, más posibilidades hay de que algo falle.

En email marketing, la claridad suele ganar a la sofisticación. Un buen email responsive debe ser legible, rápido de escanear, accesible y fácil de accionar. Si además es bonito, mejor. Pero la belleza no debería depender de una estructura frágil.

Errores comunes al crear emails responsive con tablas HTML

Uno de los errores más frecuentes es usar demasiadas columnas. Un diseño de tres o cuatro columnas puede verse bien en escritorio, pero convertirse en un problema en móvil. Si el contenido es importante, asegúrate de que se pueda leer cómodamente en una sola columna.

Otro error habitual es olvidar los paddings móviles. Un email que se ve perfecto en escritorio puede quedar pegado a los bordes en móvil si no defines espaciados adaptados.

También conviene evitar imágenes con texto incrustado. Si el texto importante está dentro de una imagen, puede no ser accesible, no escalar bien o perderse si la imagen no carga.

Y, por último, cuidado con los botones falsos hechos solo con imágenes. Un botón debería ser texto HTML dentro de una estructura clicable, no una imagen que desaparece si el cliente bloquea recursos externos.

Preguntas frecuentes sobre tablas HTML y emails responsive

¿Es obligatorio usar tablas HTML para crear emails responsive?

No es obligatorio en todos los casos, pero sí sigue siendo una de las opciones más compatibles para estructuras principales. Puedes apoyarte en CSS moderno como mejora progresiva, pero para layouts robustos las tablas HTML siguen siendo muy utilizadas en email.

¿Puedo usar flexbox o grid en emails HTML?

Puedes usarlos en algunos contextos, pero no deberías depender de ellos para la estructura principal si necesitas compatibilidad amplia. El soporte de flexbox y grid en clientes de correo no es tan consistente como en navegadores modernos, así que conviene usarlos solo con fallback o en elementos secundarios.

¿MJML evita tener que aprender tablas HTML para email?

MJML reduce muchísimo la necesidad de escribir tablas manualmente, pero no elimina la conveniencia de entenderlas. Es una herramienta muy útil para crear emails responsive de forma más cómoda, aunque el HTML final seguirá usando estructuras compatibles con clientes de correo.

Emails más simples, menos quebraderos de cabeza

Hacer emails responsive con tablas HTML no tiene por qué convertirse en una pesadilla. Es verdad que el desarrollo de emails tiene reglas propias, limitaciones incómodas y decisiones que pueden parecer anticuadas si vienes del desarrollo web moderno. Pero también es cierto que, con una buena estructura base, algunos patrones reutilizables y una mentalidad de compatibilidad, el proceso se vuelve mucho más llevadero.

La clave está en dejar de pelearte con las tablas como si fueran una anomalía y empezar a verlas como una capa de compatibilidad. No necesitas escribir el email más sofisticado del mundo. Necesitas crear una pieza que se lea bien, se adapte al móvil, respete la accesibilidad y funcione en los clientes de correo más importantes.

En email, menos suele ser más. Menos columnas, menos dependencias, menos CSS experimental y menos obsesión por el píxel perfecto. A cambio, más claridad, más consistencia y más tranquilidad.

Porque al final, un buen email responsive no es el que demuestra todo lo que sabes de CSS moderno. Es el que llega, se entiende, se lee cómodamente y consigue que la persona haga lo que tiene que hacer sin obstáculos. Y si para eso hay que usar tablas HTML, que al menos sean tablas bien pensadas.