LOS NÚMEROS QUE IMPORTAN
68 %
48 %
9 de 9
21 MB
En septiembre audité una web de hostelería con tienda online. La portada pesaba 21 MB y un móvil tardaba unos 27 segundos en enseñar lo principal. La web era responsive: en el móvil todo encajaba, nada se salía de la pantalla y el menú se convertía en hamburguesa. Y aun así, 12,5 de esos 21 MB eran un vídeo de fondo que cada móvil se descargaba entero.
LOS DATOS DEL CASO
Peso de la portada antes y después de decidir qué descarga cada dispositivo
Web de hostelería con tienda online. Antes: auditoría de septiembre de 2026, igual en móvil y en escritorio. Después: PageSpeed Insights, 17 de octubre de 2026. Las imágenes todavía están pendientes de optimizar.
El problema no era el diseño. Era que nadie había decidido qué necesitaba cada dispositivo. El diseño responsive decide cómo se coloca lo que llega a la pantalla. El adaptativo decide qué llega. Aquella portada resolvía muy bien lo primero y no se había planteado lo segundo.
En los últimos meses he auditado catorce webs: tiendas online, una clínica, una fundación, un software para empresas, un organismo público, un alojamiento turístico, una firma de inversión, un DJ de bodas y mi propia web. En casi todas, la versión móvil iba por detrás de la de escritorio. No porque estuvieran mal maquetadas, sino por lo que se descargaba, por dónde cortaban los tamaños y por lo que quedaba escondido o diminuto al llegar al móvil.
Esta es la guía que uso yo. Qué es de verdad cada enfoque (y por qué la pregunta «¿responsive o adaptativo?» casi siempre está mal planteada), por qué importa más que nunca, cómo decidir, cómo hacerlo bien en WordPress y Elementor, cómo comprobarlo y los diez errores que más encuentro. Con el código listo para copiar, la ruta de cada menú y seis herramientas para probar tu propia web.
01 — LA BASE
Qué es el diseño responsive, qué es el adaptativo (y qué no son)
El diseño responsive es una sola página, con un solo HTML y una sola URL, que se recoloca para encajar en cualquier ancho de pantalla. No tiene una versión para el móvil y otra para el ordenador: tiene una maqueta que fluye y unos puntos en los que cambia de forma cuando el contenido ya no cabe.
El término lo acuñó Ethan Marcotte en A List Apart el 25 de mayo de 2010 y lo apoyó en tres ingredientes: una rejilla fluida (medidas relativas en lugar de píxeles fijos), imágenes flexibles (que nunca se salen de su caja) y media queries (reglas de CSS que se aplican según el ancho de la pantalla). Dieciséis años después, las herramientas han cambiado, pero la idea es la misma.
El diseño adaptativo es otra cosa, y el problema es que la palabra se usa con dos sentidos distintos:
- El sentido original. Aaron Gustafson lo popularizó en 2011 con su libro Adaptive Web Design, y para él significaba mejora progresiva: una base que funciona en cualquier navegador y capas que se añaden cuando el dispositivo las soporta. Es una filosofía, no una técnica de maquetación.
- El sentido de uso común. Varias maquetas cerradas, cada una pensada para un tamaño concreto (360, 768, 1.024, 1.280 px…), y algo que decide cuál se sirve: el servidor, mirando qué navegador pide la página, o el propio CSS, saltando de una maqueta fija a la siguiente.
En este artículo uso «adaptativo» en el segundo sentido, que es el que encontrarás en casi todas partes. Pero quédate con una idea: ya en 2011, Jeffrey Zeldman escribía que la maquetación adaptativa no es una alternativa al diseño responsive, sino «una forma de diseño responsive, aunque menos robusta». La discusión «uno u otro» lleva quince años mal planteada.
ASÍ NO SE ENTIENDE
«Responsive es que la web se vea en el móvil»
«Adaptativo es más moderno o más profesional»
«Con un tema responsive ya está todo hecho»
«Ocultar un bloque en móvil es adaptar la web»
ASÍ SÍ
Responsive es un solo HTML que fluye a cualquier ancho, también a los que no has previsto
Las webs m. y las maquetas fijas por tamaños son anteriores al responsive; Google recomienda este último
El tema pone la base; lo que rompe el móvil suele ser lo que se monta encima
Ocultar con CSS esconde, pero en muchos casos el navegador lo sigue descargando
Las diferencias, una al lado de la otra
| Responsive | Adaptativo | |
|---|---|---|
| Cuántas maquetas | Una que fluye | Varias cerradas, una por tamaño |
| HTML y URL | Uno y una para todos | Puede variar el HTML (mismo dominio) o la URL (m.dominio.com) |
| Quién decide | El navegador, según el espacio disponible | El servidor, según el navegador que pide la página, o el CSS por tramos |
| Anchos que no habías previsto | Se recoloca sin más | Se quedan márgenes vacíos o aparece scroll lateral |
| Mantenimiento | Un solo diseño, más difícil de afinar | Varios diseños que hay que mantener a la vez |
| Control de lo que se descarga | Hay que planificarlo (srcset, carga condicional) | Alto: cada versión lleva solo lo suyo |
| Riesgo para el SEO | Bajo: es lo que Google recomienda | Medio: contenido distinto, redirecciones y caché mal configuradas |
Diferencias prácticas entre diseño responsive y adaptativo. Cuando digo «adaptativo» me refiero a maquetas fijas por tamaño o a HTML distinto según el dispositivo.
¿Y «mobile first»?
Es una tercera expresión que se mezcla con las otras dos y que tiene, a su vez, dos significados. Como forma de diseñar, mobile first es empezar por la pantalla pequeña, donde no cabe lo que sobra, y añadir después lo que permite una pantalla grande. En CSS, es escribir los estilos base para el móvil y ampliarlos con min-width. La indexación mobile-first de Google es otra cosa: que Google rastrea y valora tu web con un robot que se presenta como un móvil. Lo vemos en el capítulo siguiente.
02 — EL CONTEXTO
Por qué importa más que nunca
En España, el 68 % de las visitas a webs se hacen desde un móvil, según StatCounter (septiembre de 2026). En todo el mundo, el 59 %. Pero la media engaña en las dos direcciones: en un software para empresas que gestiono, el 65 % de los clics de Google Ads llegan desde el móvil, aunque cualquiera habría apostado por el ordenador de oficina. Antes de decidir nada, mira tus datos: en Analytics, Informes → Usuario → Tecnología → Detalles técnicos, con la dimensión «Categoría de dispositivo».
Google mira primero el móvil
- Abril de 2015. Google empieza a premiar en los resultados móviles a las webs adaptadas al móvil. La prensa lo bautizó «Mobilegeddon».
- Noviembre de 2016. Anuncia la indexación mobile-first: usará la versión móvil de cada web para indexarla y posicionarla.
- Marzo de 2024. INP sustituye a FID como métrica de respuesta en las Core Web Vitals.
- 5 de julio de 2024. Google rastrea e indexa todas las webs solo con Googlebot Smartphone. En sus palabras: si el contenido de una web no es accesible con un móvil, «dejará de poder indexarse». El robot de escritorio queda para casos concretos, como fichas de producto y ofertas de empleo.
La consecuencia práctica: lo que no está en tu versión móvil, para Google no existe. Si escondes un bloque de texto en el móvil para que la página sea más corta, lo estás quitando también del índice. Google lo dice expresamente en su guía: el contenido principal tiene que ser equivalente en móvil y en escritorio. Puedes reorganizarlo con pestañas o desplegables, pero no quitarlo.
La experiencia se mide por dispositivo
Las Core Web Vitals son las tres métricas con las que Google mide la experiencia de carga: LCP (cuánto tarda en verse lo principal; bueno, hasta 2,5 s), INP (cuánto tarda la página en responder cuando tocas algo; bueno, hasta 200 ms) y CLS (cuánto se mueve el contenido mientras carga; bueno, hasta 0,1). Google las mide con datos de usuarios reales, en el percentil 75 y por separado en móvil y en escritorio. Una web puede aprobar en el ordenador y suspender en el móvil, y es lo más habitual.
EL CONTEXTO
Porcentaje de webs con resultado bueno en cada métrica, móvil frente a escritorio
HTTP Archive, Web Almanac 2025, capítulo de rendimiento (datos del Chrome UX Report, julio de 2025). INP y el total de Core Web Vitals, por web; LCP y CLS, por página. El CLS es la única métrica en la que el móvil sale mejor.
El móvil suspende más por una razón física: menos procesador, peor conexión y la misma web. En la mitad de las webs, el tiempo de bloqueo (lo que el navegador pasa ocupado ejecutando JavaScript sin poder responder) supera los 1.916 ms en móvil; en escritorio, los 92 ms, según el mismo informe. Por eso «se ve bien en mi móvil» no significa nada: tu móvil es probablemente mejor que el de la mayoría de tus visitas y tu wifi, mejor que su 4G.
Las pantallas ya no caben en tres casillas
Móvil, tableta y ordenador era una división razonable en 2012. Hoy hay móviles de 360 a 440 px de ancho, plegables que cambian de tamaño al abrirse, tabletas en horizontal más anchas que muchos portátiles y portátiles que, por el escalado de Windows, muestran la web a 1.280 o 1.536 px aunque la pantalla sea de 1.920. Justo en ese tramo, entre la tableta y el escritorio, es donde más webs encuentro rotas.
Y desde el 28 de junio de 2025 hay además una razón legal: la Ley 11/2023 de accesibilidad obliga a muchas tiendas online y servicios a que su web sea usable para todo el mundo, y varias de sus exigencias tocan de lleno el diseño responsive. Lo cuento en el capítulo 09.
03 — EL MECANISMO
Cómo funciona cada uno por dentro
Para decidir con criterio hay que saber qué hace el navegador en cada caso. Empiezo por el responsive, porque es la base de casi todo lo demás.
1. La etiqueta viewport: sin ella no hay responsive
Los navegadores móviles, si nadie les dice lo contrario, dibujan la página como si la pantalla midiera unos 980 px y luego la encogen para que quepa. Por eso las webs antiguas se ven diminutas en el móvil. Esta línea en el <head> le dice al navegador que use el ancho real del dispositivo:
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Mal: impide hacer zoom con los dedos. Lo encuentro en muchas webs -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0">WordPress no la pone por sí solo: la pone el tema. Astra, Hello, GeneratePress y casi todos los temas modernos la incluyen bien. Lo que encuentro a menudo es la segunda versión, con el zoom bloqueado, que añade algún tema antiguo o algún plugin. Bloquear el zoom es un problema de accesibilidad (capítulo 09). Casi siempre se añade para que el iPhone no amplíe la página al tocar un campo de formulario, y eso tiene otro arreglo: poner los campos a 16 px. Safari, además, ignora esa orden desde hace años; muchos Android no.
2. Rejilla fluida: medidas que dependen del espacio
En lugar de decir «esta columna mide 380 px», se dice «esta columna ocupa un tercio» o «caben tantas columnas de al menos 280 px como quepan». Hoy eso se hace con flexbox y grid, que en Elementor son los contenedores. La regla que más uso para tarjetas, porque no necesita ni un punto de corte:
.tarjetas {
display: grid;
/* Tantas columnas de 280 px como quepan; si no cabe ninguna, una al 100 % */
grid-template-columns: repeat(auto-fit, minmax(min(280px, 100%), 1fr));
gap: clamp(16px, 3vw, 32px);
}
.contenedor {
/* Nunca más de 1.200 px, y siempre 20 px de aire a cada lado */
width: min(100% - 40px, 1200px);
margin-inline: auto;
}3. Imágenes flexibles: que quepan y que no pesen de más
La primera mitad es fácil: max-width: 100% y la imagen nunca se sale de su caja. La segunda es la que casi nadie hace: que el móvil no se descargue la misma imagen de 1.920 px que el ordenador. Para eso están los atributos srcset y sizes: le das al navegador varias versiones de la imagen y le dices qué ancho va a ocupar en pantalla, y él elige la que necesita según el ancho y la densidad de píxeles de cada pantalla. WordPress genera srcset automáticamente para las imágenes de la biblioteca de medios; lo que suele estar mal es sizes. Lo vemos en el manual.
4. Media queries y puntos de corte
Una media query aplica unas reglas solo cuando se cumple una condición: «si la pantalla mide menos de 768 px, pon las columnas una debajo de otra». Los anchos en los que cambian las reglas son los puntos de corte (en Elementor, «puntos de interrupción»). La pregunta clave no es qué puntos de corte usar, sino dónde se rompe tu contenido. Pero si trabajas con Elementor, hay una regla que no se negocia: tus puntos de corte de CSS tienen que coincidir con los de Elementor (capítulo 05).
5. Lo que ha llegado después: clamp(), container queries y las unidades del visor
clamp()fija un mínimo, un valor que crece con la pantalla y un máximo. Con una línea, un titular pasa de 28 a 48 px sin saltos y sin puntos de corte. Es la base de la tipografía fluida.- Container queries: en lugar de preguntar cuánto mide la pantalla, un componente pregunta cuánto mide su caja. Una tarjeta puede ponerse en horizontal cuando su columna es ancha, esté donde esté. Según web.dev, están disponibles en todos los navegadores principales de forma amplia desde agosto de 2025.
- Unidades
dvh,svhylvh: arreglan el problema histórico de100vhen el móvil, que no tiene en cuenta la barra del navegador que aparece y desaparece. Lo vemos en el capítulo 08.
Herramienta · Simulador
Responsive frente a adaptativo, ancho a ancho
La misma página con los dos enfoques. Arrastra el ancho de la pantalla de 320 a 1.600 px o elige un dispositivo, y mira qué pasa en los anchos que nadie ha previsto.
Responsive
Una maqueta que fluyeAdaptativo
Maquetas fijas de 360, 768, 1.024 y 1.280 pxY el adaptativo, ¿cómo decide?
Hay tres formas, y conviene distinguirlas porque sus riesgos son muy distintos:
| Forma | Cómo funciona | Lo que hay que vigilar |
|---|---|---|
| Servicio dinámico | Misma URL; el servidor mira la cabecera User-Agent del navegador y devuelve un HTML u otro | Enviar la cabecera Vary: User-Agent para que las cachés no mezclen versiones; que el contenido sea equivalente |
| URL separadas | Una web para ordenador y otra para móvil (m.dominio.com), con redirecciones según el dispositivo | Etiquetas rel="alternate" y rel="canonical" entre versiones, redirecciones correctas y el doble de mantenimiento |
| Maquetas fijas en CSS | Un solo HTML, pero el CSS salta entre anchos cerrados (360, 768, 1.024…) en lugar de fluir | Los anchos intermedios: márgenes vacíos o scroll lateral |
Las tres formas de hacer adaptativo y lo que implica cada una.
Google admite las tres, pero lo dice sin rodeos en su guía para webs móviles: recomienda el diseño responsive «porque es el patrón más fácil de implementar y mantener». Con el servicio dinámico y las URL separadas, cada error de configuración (una redirección que manda al móvil a la portada, una caché que sirve la versión equivocada, una etiqueta noindex solo en la versión móvil) es un problema de indexación.
04 — EL CRITERIO
Responsive, adaptativo o híbrido: cómo decidir
Con lo anterior, la pregunta cambia. No es «¿responsive o adaptativo?», sino «¿qué parte de mi web necesita algo distinto en cada dispositivo?». La base es responsive casi siempre. Lo adaptativo son decisiones concretas que se toman encima, bloque a bloque.
Cuándo tiene sentido una decisión adaptativa
- Lo pesado. Vídeos de fondo, carruseles y fotos de cabecera. El móvil no necesita lo mismo en pequeño: necesita otra cosa. Una imagen fija en lugar del vídeo, una foto en lugar del carrusel.
- Una foto que no aguanta el recorte. Una panorámica horizontal que, recortada en vertical, se queda en un trozo de pared. En una tienda de vinos propuse una versión vertical solo para el móvil con
<picture>: misma página, otra foto. - Una tarea distinta. En la página de aterrizaje de un software para empresas, el 65 % de los clics de anuncios llegaba desde el móvil. En la versión móvil pusimos el formulario justo después del titular y un botón fijo de «Solicitar demo». En escritorio, la página sigue su orden. Misma URL, mismo contenido, distinto orden.
- Una web m. heredada. Aquí la decisión adaptativa correcta suele ser desmontarla y migrar a responsive, con redirecciones 301 de cada URL móvil a su equivalente.
LA BRECHA
Tiempo hasta ver lo principal (LCP) en cuatro webs responsive, móvil frente a escritorio
Datos de laboratorio de PageSpeed Insights: móvil emulado con 4G lenta, escritorio con conexión rápida. Mi web y la de hostelería, 17 de octubre de 2026; las otras dos, en su auditoría de 2026. Un LCP es bueno hasta 2,5 s.
Las cuatro webs del gráfico son responsive y las cuatro se ven bien en un móvil. La diferencia no viene del enfoque, viene de lo que envían: un vídeo, una imagen de fondo de 314 KB como imagen principal, un carrusel pesado o, en mi caso, demasiado JavaScript para la primera pantalla. Ningún cambio de enfoque arregla eso. Lo arreglan las decisiones adaptativas bien tomadas.
MI CRITERIO
Cómo lo decido yo
01
02
03
04
05
Herramienta · Decisión
¿Responsive, adaptativo o híbrido?
Cinco preguntas como máximo. Es una orientación según tu web, tu tráfico y tu equipo; con tus datos delante, mejor.
El diseño responsive decide cómo se coloca lo que llega. El adaptativo decide qué llega. Casi todas las webs que audito necesitan las dos cosas, y casi ninguna ha decidido la segunda.
05 — EL MANUAL
Hacerlo bien en WordPress y Elementor, paso a paso
Este es el orden en el que reviso y arreglo una web en WordPress con Elementor. Sirve igual para una web nueva que para una que ya está publicada. Las rutas de menú son las de Elementor en español; en otras versiones pueden cambiar de sitio, pero los nombres se parecen.
Paso 1 · Comprueba la etiqueta viewport
Abre el código fuente de la portada (Ctrl + U en Windows, Cmd + Opción + U en Mac) y busca viewport. Tiene que haber una sola etiqueta y tiene que decir width=device-width, initial-scale=1. Si lleva maximum-scale=1 o user-scalable=0, averigua quién la pone: desactiva plugins en la copia de pruebas hasta que cambie; si no cambia, viene del tema y se corrige en el tema hijo.
Paso 2 · Unifica los puntos de corte
Es el error más silencioso que encuentro, y el que más webs rompe entre la tableta y el ordenador. Elementor tiene sus puntos de corte, el tema tiene los suyos y el CSS que alguien añadió a mano tiene otros. Si no coinciden, aparecen tramos en los que conviven dos maquetas: el menú ya es hamburguesa pero el contenido sigue en tres columnas, o al revés.
Los de Elementor están en Ajustes del sitio → Diseño → Puntos de interrupción (desde el editor, en el menú de la esquina superior izquierda). Los valores por defecto son estos:
| Dispositivo | Valor por defecto | Se aplica |
|---|---|---|
| Móvil vertical | 767 px | Hasta 767 px |
| Móvil horizontal | 880 px | Hasta 880 px |
| Tableta vertical | 1.024 px | Hasta 1.024 px |
| Tableta horizontal | 1.200 px | Hasta 1.200 px |
| Portátil | 1.366 px | Hasta 1.366 px |
| Escritorio | — | Lo que no cubren los demás (es la base) |
| Pantalla ancha | 2.400 px | Desde 2.400 px |
Puntos de corte de Elementor y su valor por defecto. Todos se aplican «hasta» su valor, salvo pantalla ancha, que se aplica «desde».
Mi punto de partida: móvil a 767, tableta a 1.024 y, solo si la cabecera o las rejillas lo piden, portátil a 1.366. Cada punto de corte que activas es una vista más que revisar en cada bloque y algo más de CSS en cada página. Después, el CSS propio con exactamente los mismos números:
/* Móvil: hasta 767 px (igual que Elementor) */
@media (max-width: 767px) { }
/* Tableta: de 768 a 1.024 px */
@media (min-width: 768px) and (max-width: 1024px) { }
/* Portátil, solo si lo tienes activado en Elementor: de 1.025 a 1.366 px */
@media (min-width: 1025px) and (max-width: 1366px) { }
/* Escritorio: desde 1.025 px (desde 1.367 px si usas el de portátil) */
@media (min-width: 1025px) { }Y una comprobación más: en el widget de menú de tu cabecera hay una opción que decide a partir de qué punto de corte aparece la hamburguesa. Tiene que caer en el mismo punto en el que la cabecera deja de caber. Si a 1.100 px los elementos del menú ya saltan a una segunda fila, la hamburguesa tiene que aparecer antes, aunque eso obligue a activar el punto de corte de portátil.
Herramienta · Puntos de corte
Mapa de puntos de corte
Marca los puntos de corte que tienes activos en Elementor y escribe los de tu CSS propio. El mapa te enseña dónde no coinciden y qué pantallas reales caen justo en medio.
Tramos de ElementorZona en la que conviven dos maquetasTu CSSPantallas reales
Diagnóstico
Pantallas que caen en una zona mixta
Paso 3 · Contenedores fluidos, sin anchos fijos
El ancho máximo del contenido se fija una vez en Ajustes del sitio → Diseño → Ancho del contenido. Dentro, nada debería tener un ancho fijo en píxeles mayor que el móvil más estrecho: anchos en porcentaje o «completo», márgenes y rellenos más pequeños en tableta y móvil, y cuidado con las posiciones absolutas, que no se recolocan. En mi web, una sola barra de 640 px en el pie provocaba scroll lateral en todas las páginas (caso 2, en el capítulo 10).
/* 1. Textos largos (URL, correos, palabras alemanas) que empujan el ancho */
.elementor-widget-text-editor,
.elementor-heading-title { overflow-wrap: break-word; }
/* 2. Hijos de una fila flexible que se niegan a encoger */
.fila-flexible > * { min-width: 0; }
/* 3. Ninguna imagen, vídeo o iframe más ancho que su caja */
img, video, iframe { max-width: 100%; height: auto; }Paso 4 · Tipografía fluida con clamp()
El cuerpo de texto, a 16 px como mínimo en todos los dispositivos: es lo que he decidido para todas las entradas de mi web y lo que pido en cada proyecto. Lo que crece con la pantalla son los titulares. En Elementor puedes fijarlos en Ajustes del sitio → Tipografía global con un tamaño por dispositivo, o usar clamp() para que crezcan sin saltos. En las versiones recientes, el selector de unidades del tamaño de letra tiene la opción «personalizado», donde se puede pegar la fórmula; si la tuya no la tiene, usa variables de CSS:
:root {
--texto: 1rem; /* 16 px en todas las pantallas */
--h1: clamp(1.75rem, 1.2609rem + 2.1739vw, 3rem); /* 28 px a 360 px → 48 px a 1.280 px */
--h2: clamp(1.5rem, 1.2554rem + 1.087vw, 2.125rem); /* 24 px → 34 px */
--h3: clamp(1.25rem, 1.1033rem + 0.6522vw, 1.625rem); /* 20 px → 26 px */
}
body { font-size: var(--texto); line-height: 1.7; }
h1 { font-size: var(--h1); line-height: 1.2; }
h2 { font-size: var(--h2); line-height: 1.3; }
h3 { font-size: var(--h3); line-height: 1.4; }La parte en rem no es un capricho: si la fórmula fuera solo vw, el texto no crecería cuando alguien sube el tamaño de letra de su navegador. Con rem + vw, crece con la pantalla y con las preferencias de quien lee.
Herramienta · Tipografía
Calculadora de tipografía fluida
Elige el tamaño en el móvil y en el escritorio, y entre qué anchos tiene que crecer. Te doy el clamp() listo para copiar, con una parte en rem para que respete el zoom de quien lee.
Tu proyecto, visible en cualquier dispositivo
Tamaño en cada pantalla
| Ancho | Pantalla | Tamaño |
|---|
Paso 5 · Imágenes: el tamaño justo para cada pantalla
Aquí está el ahorro más grande de casi todas las auditorías. Cuatro reglas:
- Elige bien el tamaño en el widget. En el widget Imagen de Elementor, el campo «Tamaño de la imagen» decide la versión base. WordPress genera las demás y las ofrece en
srcset, pero también escribe unsizesque dice «esta imagen ocupa toda la pantalla hasta su ancho». Si eliges «Completo» para un logo que se ve a 146 px, el móvil puede descargar una versión de más de 1.000 px. Lo encontré tal cual: un logo de 1.919 px mostrado a 146. - La imagen principal, nunca en diferido. La primera imagen grande de la página (la que suele ser el LCP) tiene que cargarse con prioridad: sin
loading="lazy"y confetchpriority="high". WordPress lo intenta hacer solo desde la versión 6.3, pero los optimizadores y los fondos de Elementor se lo saltan a menudo. Excluye esa imagen de la carga diferida de tu plugin de caché. - Ancho y alto siempre. Con
widthyheighten la etiqueta, oaspect-ratioen CSS, el navegador reserva el hueco y el contenido no salta mientras carga. Sin ellos, el CLS se dispara. - Fondos distintos por dispositivo. En un contenedor de Elementor, Estilo → Fondo → Imagen, cambia a la vista móvil con el icono de dispositivo junto al campo y pon otra imagen. Elementor lo escribe con media queries, así que cada dispositivo descarga solo la suya. Es adaptativo bien hecho.
Si la imagen principal es un fondo de CSS o la añade una plantilla, el navegador la descubre tarde. La solución es precargarla. En una clínica online, precargarla y ordenar el JavaScript bajó el LCP del móvil de 11,1 a 2,3 s (caso 3):
add_action( 'wp_head', function () {
if ( ! is_front_page() ) {
return;
}
// Una sola imagen:
// echo '<link rel="preload" as="image" href="https://tudominio.com/wp-content/uploads/portada-800.webp" fetchpriority="high">' . "\n";
// Mejor, con versiones por ancho (el navegador elige la misma que usará la página):
echo '<link rel="preload" as="image" fetchpriority="high"'
. ' imagesrcset="https://tudominio.com/wp-content/uploads/portada-480.webp 480w,'
. ' https://tudominio.com/wp-content/uploads/portada-800.webp 800w,'
. ' https://tudominio.com/wp-content/uploads/portada-1600.webp 1600w"'
. ' imagesizes="100vw">' . "\n";
}, 1 );Y cuando el móvil necesita otra foto (dirección de arte), <picture>. En Elementor va en un widget HTML:
<picture>
<!-- Hasta 767 px: versión vertical -->
<source media="(max-width: 767px)"
srcset="/wp-content/uploads/portada-vertical-600.webp 600w,
/wp-content/uploads/portada-vertical-1000.webp 1000w"
sizes="100vw" width="1000" height="1250">
<!-- Resto: versión horizontal -->
<img src="/wp-content/uploads/portada-1600.webp"
srcset="/wp-content/uploads/portada-1000.webp 1000w,
/wp-content/uploads/portada-1600.webp 1600w,
/wp-content/uploads/portada-2400.webp 2400w"
sizes="100vw" width="2400" height="1350"
alt="Describe aquí la foto" fetchpriority="high">
</picture>Herramienta · Imágenes
Calculadora de imágenes responsive
Dime cuánto ocupa la imagen en cada pantalla. Te digo qué anchos generar, el sizes que tienes que escribir y cuánto se ahorra frente al que pone WordPress por defecto.
Tramos de Elementor por defecto: móvil hasta 767 px y tableta hasta 1.024 px. Las densidades de pantalla son las habituales: 3× en móviles, 2× en tabletas y 1× o 2× en ordenadores.
Lo que necesita cada pantalla
| Pantalla | Se ve a | Necesita | Con el sizes de WordPress |
|---|
Anchos que conviene generar
Desde WordPress 6.7, las imágenes con carga diferida llevan además sizes="auto", que permite al navegador calcular solo el ancho real. Ayuda, pero no lo arregla todo: solo afecta a las imágenes en diferido y no todos los navegadores lo soportan todavía.
Paso 6 · Vídeo y lo pesado: que el móvil no lo descargue
Ocultar un vídeo en el móvil con Avanzado → Adaptable → Ocultar en móvil lo esconde con CSS, pero la etiqueta sigue en la página y, con reproducción automática, el navegador puede descargarlo igual. En el fondo de vídeo de un contenedor, Elementor tiene una opción para no reproducirlo en móvil y un campo de imagen de respaldo; úsalos. Pero compruébalo siempre en la pestaña Red, porque el comportamiento cambia según el widget y la versión. Si el vídeo va en un widget HTML, este patrón solo le da la fuente al navegador cuando la pantalla es ancha:
<video class="video-portada" muted loop playsinline preload="none"
poster="/wp-content/uploads/portada-video-poster.jpg"
width="1280" height="720" aria-hidden="true"></video>
<script>
(function () {
var v = document.querySelector('.video-portada');
if (!v) return;
var ancho = window.matchMedia('(min-width: 768px)').matches;
var sinMovimiento = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
var ahorroDatos = navigator.connection && navigator.connection.saveData;
// En el móvil, con movimiento reducido o con ahorro de datos: solo el póster
if (!ancho || sinMovimiento || ahorroDatos) return;
v.innerHTML =
'<source src="/wp-content/uploads/portada-720.webm" type="video/webm">' +
'<source src="/wp-content/uploads/portada-720.mp4" type="video/mp4">';
v.load();
v.play().catch(function () {});
})();
</script>Para el ordenador, el vídeo también tiene que pesar poco: 720p, sin pista de audio si va silenciado, unos pocos segundos en bucle y un póster que sea una imagen optimizada. En la web de hostelería del principio, el vídeo pasó de 12,5 a 2,7 MB así. Lo mismo vale para los carruseles: en el móvil, casi siempre es mejor una foto fija.
Paso 7 · Botones, menús y formularios hechos para el dedo
- Áreas táctiles de 44 × 44 px en botones, enlaces del menú e iconos. Es lo que recomienda Apple; Android pide 48. El mínimo de las pautas de accesibilidad es 24 (capítulo 09), pero 24 es un mínimo, no un objetivo.
- Lo importante, en la primera pantalla. El botón principal tiene que verse sin hacer scroll en un móvil de 390 × 700 px. Si la página es larga, un botón fijo abajo en el móvil funciona muy bien.
- Teléfonos y correos que se pueden tocar: con
tel:ymailto:. - Formularios a 16 px, con el tipo de campo correcto para que salga el teclado adecuado y con
autocompletepara que el móvil los rellene solo. - Nada que dependa de pasar el ratón por encima. Los submenús que solo se abren con hover no existen en un móvil.
/* Botones y enlaces de menú: al menos 44 × 44 px de zona táctil */
.elementor-button,
.elementor-nav-menu a {
min-height: 44px;
display: inline-flex;
align-items: center;
}
/* Iconos sueltos (redes, carrito, cerrar): amplía la zona sin cambiar el dibujo */
.icono-tactil {
min-width: 44px;
min-height: 44px;
display: inline-grid;
place-items: center;
}
/* Campos a 16 px: el iPhone deja de ampliar la página al tocarlos */
input, select, textarea { font-size: max(16px, 1rem); }<a href="tel:+34600000000">600 000 000</a>
<a href="mailto:hola@tudominio.com">hola@tudominio.com</a>
<input type="email" name="email" autocomplete="email">
<input type="tel" name="telefono" autocomplete="tel">
<input type="text" name="cp" inputmode="numeric" autocomplete="postal-code">Paso 8 · Componentes que se adaptan a su caja: container queries
Cuando una misma tarjeta aparece en una columna estrecha (la barra lateral) y en una ancha (la portada), los puntos de corte de la pantalla no sirven: la pantalla mide lo mismo en los dos casos. Para eso están las container queries. En Elementor, pon una clase al contenedor que hace de caja (Avanzado → Clases CSS) y el CSS en Apariencia → Personalizar → CSS adicional o en el CSS personalizado del sitio, si tienes Elementor Pro:
/* La caja: el contenedor de Elementor con la clase «tarjetas-cq» */
.tarjetas-cq { container-type: inline-size; }
/* Si la caja mide 520 px o más, imagen a la izquierda y texto a la derecha */
@container (min-width: 520px) {
.tarjetas-cq .tarjeta {
display: grid;
grid-template-columns: 180px 1fr;
gap: 20px;
align-items: start;
}
}Paso 9 · Usa «Ocultar en» con mucho cuidado
La opción Avanzado → Adaptable → Ocultar en escritorio / tableta / móvil es la forma rápida de hacer «una versión para cada dispositivo»: duplicas una sección, ocultas una en el móvil y la otra en el escritorio. Funciona a la vista, pero las dos versiones siguen en el HTML. Google las lee las dos, los lectores de pantalla pueden leer las dos y el navegador descarga lo de las dos. En la web de una fundación conté 15 encabezados H1 en el HTML de la portada por bloques duplicados así y un carrusel que clonaba diapositivas. Úsala para detalles (un salto de línea, un icono), no para duplicar secciones enteras.
06 — LA COMPROBACIÓN
Cómo revisar una web en todos los tamaños
Una web no está bien en el móvil porque se vea bien en el tuyo. Esta es la rutina que sigo, de lo más fiable a lo más manual.
LA RUTINA
Cómo reviso yo una web, en este orden
01
02
03
04
05
06
07
| Ancho | Qué representa |
|---|---|
| 320 px | El mínimo de las pautas de accesibilidad: equivale a 1.280 px con zoom al 400 % |
| 360 px | Android pequeño o antiguo; sigue teniendo mucho tráfico |
| 375 px | iPhone SE y modelos mini |
| 390–440 px | iPhone actuales, según modelo, y Android de gama media y alta |
| 768 px | El primer ancho de tableta en vertical (y el primero de tableta en Elementor) |
| 820–834 px | iPad Air e iPad Pro de 11" en vertical |
| 1.024 px | iPad en horizontal; el último ancho de tableta en Elementor |
| 1.280 px | Portátil con pantalla de 1.920 al 150 % de escalado |
| 1.366 px | Portátil básico; el valor por defecto de «Portátil» en Elementor |
| 1.440–1.536 px | MacBook Air de 13"; pantalla de 1.920 al 125 % de escalado |
| 1.920 px | Monitor Full HD |
Los anchos que reviso y por qué. Son anchos de CSS, no la resolución física de la pantalla.
// 1. ¿Qué elementos se salen por los lados? (los que provocan scroll lateral)
// Ignora los menús que viven fuera de la pantalla hasta que se abren.
(function () {
var ancho = document.documentElement.clientWidth;
document.querySelectorAll('body *').forEach(function (el) {
var r = el.getBoundingClientRect();
if (r.width && (r.right > ancho + 1 || r.left < -1)) {
console.log(Math.round(r.width) + ' px', el);
}
});
})();
// 2. Elementos táctiles de menos de 44 × 44 px
// Los enlaces dentro de un párrafo están exentos: es normal que salgan.
document.querySelectorAll('a, button, input, select, textarea, [role="button"]').forEach(function (el) {
var r = el.getBoundingClientRect();
if (r.width && r.height && (r.width < 44 || r.height < 44)) {
console.log(Math.round(r.width) + ' × ' + Math.round(r.height), el);
}
});
// 3. Imágenes que se descargan mucho más grandes de lo que se ven
document.querySelectorAll('img').forEach(function (img) {
if (!img.naturalWidth || !img.clientWidth) return;
var necesita = img.clientWidth * window.devicePixelRatio;
if (img.naturalWidth > necesita * 1.5) {
console.log(img.naturalWidth + ' px descargados para ' + Math.round(necesita) + ' necesarios', img.currentSrc);
}
});
// 4. La etiqueta viewport y el tamaño de letra del cuerpo
console.log((document.querySelector('meta[name="viewport"]') || {}).content,
getComputedStyle(document.body).fontSize);07 — LOS ERRORES
Los diez errores que más encuentro en auditorías
Todos salen de webs reales que he revisado este año. Ninguno da un error visible en el escritorio. Casi todos los ve cualquiera que abra la web en el móvil con un poco de paciencia.
01
Puntos de corte que no coinciden
02
Duplicar bloques para cada dispositivo
03
Imágenes de escritorio en el móvil
04
Un vídeo que el móvil descarga aunque no lo necesite
05
Botones que no se pueden tocar
06
Texto pequeño y zoom bloqueado
user-scalable=0, que impide ampliar para leerlos. 07
Portadas interminables
08
Lo importante, escondido
tel:. En mi propia web, el botón principal aparecía a unos 730 px, fuera de la primera pantalla, y el globo del chat tapaba el subtítulo. 09
Capas que tapan la pantalla
10
La primera pantalla, vacía
Y uno que no está en la lista porque lo encontré solo una vez, en mi propia web, aunque es el más fácil de ver: el scroll lateral. Un elemento de ancho fijo basta para que todas las páginas se muevan de lado en el móvil. Las otras tres webs en las que revisé la versión móvil a fondo no lo tenían, y ese es el problema: si tu prueba es «no hay scroll lateral», puede que estés aprobando una web con los otros diez errores.
«Se ve bien en el móvil» no es una prueba. Es una frase que dice alguien con un iPhone reciente, buena cobertura y la web ya en la caché.
08 — MÁS ALLÁ DEL ANCHO
Altura, orientación, dedos y preferencias
El ancho es la variable que todo el mundo revisa. Estas son las que casi nadie mira y que, en el móvil, cambian la experiencia tanto como el ancho.
La altura también cuenta
Un móvil en horizontal tiene entre 360 y 440 px de alto. Con una cabecera fija, un banner de cookies y la barra del navegador, puede quedar una rendija de 150 px para el contenido. Si tu cabecera es fija, que deje de serlo cuando falta altura:
@media (orientation: landscape) and (max-height: 500px) {
.cabecera-fija { position: static; }
}100vh no es el alto de la pantalla en el móvil
En el móvil, la barra de direcciones aparece y desaparece al hacer scroll, y 100vh se calcula con la barra escondida. Resultado: la portada «a pantalla completa» corta el botón por abajo justo cuando la página se abre. Las unidades nuevas lo resuelven: svh es el alto con la barra visible (el más pequeño), lvh con la barra escondida y dvh el que haya en cada momento. Todos los navegadores principales las soportan desde finales de 2022. Para una portada, uso svh: el contenido cabe siempre y no salta al hacer scroll.
.portada {
min-height: 100vh; /* para navegadores antiguos */
min-height: 100svh; /* alto con la barra del navegador visible */
}Las zonas seguras
En los móviles sin marco, la isla de la cámara y la barra de inicio ocupan parte de la pantalla. Si tu tema usa viewport-fit=cover para pintar hasta los bordes, una barra fija abajo necesita respetar esa zona, o el botón queda debajo de la barra de inicio:
.barra-fija-movil {
position: fixed;
inset-inline: 0;
bottom: 0;
padding: 12px 16px calc(12px + env(safe-area-inset-bottom));
}Dedo o ratón
El ancho no dice si hay ratón. Una tableta de 1.024 px no tiene hover, y un portátil con pantalla táctil, a veces sí y a veces no. Para los efectos que dependen de pasar el ratón por encima, pregunta por el dispositivo de entrada, no por el ancho:
@media (hover: hover) and (pointer: fine) {
.tarjeta:hover { transform: translateY(-4px); }
}
/* Con dedo: zonas táctiles algo más generosas */
@media (pointer: coarse) {
.enlaces-pie a { padding-block: 12px; }
}Movimiento reducido y ahorro de datos
Quien activa «reducir movimiento» en su sistema lo hace por algo: mareos, migrañas o simple preferencia. Las animaciones de entrada de Elementor, los vídeos de fondo y los carruseles automáticos deberían pararse. Y en los navegadores basados en Chromium, quien activa el ahorro de datos lo comunica a la web: es una buena señal para no cargar el vídeo, como en el código del paso 6.
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}Plegables, ventanas divididas y anchos raros
Un plegable abierto, una tableta con dos aplicaciones en pantalla o un portátil con la ventana a medias dan anchos que no aparecen en ninguna lista: 540, 680, 912 px. Ahí se ve la diferencia entre una maqueta que fluye y una que salta entre tamaños fijos. No hay que probarlos todos: basta con arrastrar el ancho despacio, como en el simulador del capítulo 03.
09 — LO LEGAL
Accesibilidad: lo que exige la ley y lo que tiene que ver con el responsive
La Ley 11/2023, de 8 de mayo, traslada a España el Acta Europea de Accesibilidad (Directiva (UE) 2019/882). Sus requisitos se aplican desde el 28 de junio de 2025 a una lista de productos y servicios en la que están, entre otros, el comercio electrónico con consumidores, los servicios bancarios, el transporte de viajeros (sus webs y aplicaciones) y las comunicaciones electrónicas.
- Quién se libra. Las microempresas que prestan servicios: menos de 10 personas y un volumen de negocio o un balance anual que no supera los 2 millones de euros. La exención es para servicios, no para productos.
- Plazos de transición. Los contratos de servicios firmados antes del 28 de junio de 2025 pueden seguir hasta que venzan, con un máximo de cinco años. Y los servicios pueden seguir usando hasta el 28 de junio de 2030 los productos que ya usaban antes de esa fecha.
- Sanciones. Las de la normativa de cada sector y, si no las prevé, las de la ley general de derechos de las personas con discapacidad: hasta 30.000 € las leves, hasta 90.000 € las graves y hasta 1.000.000 € las muy graves.
- El sector público tiene su propia norma desde 2018, el Real Decreto 1112/2018, que remite a la norma técnica UNE-EN 301 549.
La referencia técnica de todo esto son las pautas WCAG del W3C. La norma europea incorpora el nivel AA de las WCAG 2.1, y las WCAG 2.2, de octubre de 2023, añaden algunos criterios más. Varios tocan de lleno el diseño responsive:
| Criterio | Qué pide | Qué significa en la práctica |
|---|---|---|
| 1.4.10 Reflow (AA) | Que el contenido se pueda usar a 320 px de ancho sin scroll en dos direcciones | Un responsive bien hecho. Equivale a 1.280 px con zoom al 400 %. Las tablas y los mapas tienen excepción |
| 1.4.4 Resize text (AA) | Que el texto se pueda ampliar al 200 % sin perder contenido ni funciones | No bloquear el zoom y no fijar alturas que corten el texto ampliado |
| 1.3.4 Orientation (AA) | Que la web no obligue a usar el móvil en vertical o en horizontal | Nada de «gira tu dispositivo», salvo que sea imprescindible |
| 1.4.12 Text spacing (AA) | Que se pueda aumentar el interlineado y el espaciado sin que se pierda texto | Cajas sin altura fija; que el texto pueda crecer |
| 2.5.8 Target size (minimum) (AA, WCAG 2.2) | Zonas táctiles de al menos 24 × 24 px, o separadas lo suficiente | El mínimo. Los enlaces dentro de un párrafo están exentos |
| 2.5.5 Target size (enhanced) (AAA) | Zonas táctiles de al menos 44 × 44 px | El objetivo que recomiendo, coincide con el de Apple |
| 1.3.2 Meaningful sequence y 2.4.3 Focus order (A) | Que el orden de lectura y del tabulador tenga sentido | Cuidado al reordenar bloques por dispositivo con CSS |
Criterios de las WCAG relacionados con el diseño responsive. Entre paréntesis, el nivel: A y AA son los exigibles; AAA, el recomendable.
La conclusión es práctica: casi todo lo que exige la accesibilidad en este terreno es lo mismo que pide un buen diseño responsive. Si tu web funciona a 320 px, se puede ampliar, se toca bien con el dedo y no esconde nada, tienes medio camino hecho. El otro medio (contraste, textos alternativos, formularios con etiquetas, navegación con teclado) da para otro artículo.
10 — LOS CASOS
Tres casos reales, con números
Anonimizados, salvo el mío, pero con los datos tal cual los encontré y, cuando ha sido posible, medidos otra vez hoy.
EL CASO 3, EN NÚMEROS
Tiempos de carga en el móvil de una clínica online, antes y después
PageSpeed Insights, móvil emulado con 4G lenta, junio de 2026. La puntuación de rendimiento pasó de 60 a 77 al ajustar el JavaScript y a 96 al precargar la imagen principal.
Caso 1 · Una web de hostelería: el vídeo que el móvil no necesitaba
Síntoma. Portada de 21 MB. En un móvil, unos 27 segundos hasta ver lo principal. La maquetación era correcta: nada se salía de la pantalla y todo se recolocaba bien.
Causa. Un vídeo de fondo de 12,5 MB que se descargaba igual en el móvil y en el ordenador. Y fotos de entre 600 KB y 1 MB cada una.
Arreglo. Vídeo nuevo a 720p, sin audio y con póster: 2,7 MB. En el móvil, una foto fija y un fragmento de código que impide que el móvil pida el vídeo. Comprobado a 390 px (no se pide el MP4) y a 1.280 px (se reproduce en bucle).
Resultado. Medido hoy en PageSpeed: el móvil no descarga ningún vídeo y la portada pesa unos 9 MB en el móvil frente a casi 12 en el ordenador: la diferencia es, casi al kilo, el vídeo. Rendimiento de 77 en el móvil y 90 en el ordenador, con un LCP de 3,5 s en el móvil. Las fotos siguen pendientes: PageSpeed calcula que se pueden ahorrar 1,3 MB más.
Lección. Esa web ya era responsive. Le faltaba la decisión adaptativa: qué descarga cada dispositivo. Y ojo con el orden de prioridades: lo que más pesaba en la portada no era el diseño, eran los archivos.
Caso 2 · Mi propia web: una barra de 640 px que rompía todas las páginas
Síntoma. Al auditar jjrblik.com en septiembre, todas las páginas se movían de lado en el móvil. PageSpeed daba 62 en el móvil y 79 en el ordenador, con un LCP de 5,3 s frente a 0,9. Y el botón principal de la portada quedaba a unos 730 px, fuera de la primera pantalla, con el globo del chat tapando el subtítulo.
Causa. La barra legal del pie medía 640 px de ancho fijo en pantallas de 390. En la página de artículos, además, una imagen de 700 px en las tarjetas y un buscador de 300 px. Tres elementos de ancho fijo en una web por lo demás responsive.
Arreglo. La barra del pie en columna en el móvil, con 24 px de margen (40 en la tableta), y la imagen y el buscador a todo el ancho disponible. Comprobado a 390 px en la portada, el contacto, los artículos, el curso y una entrada, y a 900 y 1.024 px en los artículos.
Resultado. Sin scroll lateral en ninguna página. Medido hoy: 68 en el móvil y 82 en el ordenador, con un LCP de 4,2 s frente a 1,3. Todavía no apruebo: el elemento principal del móvil es un párrafo de texto que tarda en pintarse, y el peso es casi todo JavaScript (unos 1.500 KB, con reCAPTCHA cargado tres veces y dos etiquetas de Google). Es mi siguiente tarea.
Lección. Un solo elemento de ancho fijo rompe todas las páginas que lo comparten, y el pie está en todas. Y en casa del herrero: mi web es responsive, y aun así el móvil sigue 14 puntos por detrás.
Caso 3 · Una clínica online: no era el peso, era el orden
Síntoma. 60 sobre 100 de rendimiento en el móvil con un plugin de caché bien configurado en apariencia. LCP de 11,1 s.
Causa. Unas 40 hojas de estilo del tema y de Elementor, más jQuery, bloqueaban el pintado de la página; PageSpeed calculaba unos 2,5 s de ahorro si dejaban de hacerlo. Y la imagen principal (450 × 450 px, WebP, 43 KB) se descubría tarde. No pesaba: llegaba la última.
Arreglo. Desactivar la combinación de archivos JavaScript (no compensa con HTTP/2), cargarlos en diferido y retrasar su ejecución: de 60 a 77. Después, precargar la imagen principal con fetchpriority="high" con el fragmento del paso 5: de 77 a 96. En total, el LCP pasó de 11,1 a 2,3 s.
Efecto secundario. El CLS pasó de 0 a 0,101, justo por encima del límite: al cargar tan rápido, la imagen no tenía ancho ni alto y empujaba el contenido. Se arregla con aspect-ratio o con las dimensiones en la etiqueta.
Lección. En el móvil, el orden en que llegan las cosas importa tanto como lo que pesan. Y cada mejora de velocidad hay que comprobarla también en estabilidad.
11 — PREGUNTAS FRECUENTES
Preguntas frecuentes sobre diseño responsive y adaptativo
¿Qué diferencia hay entre diseño responsive y adaptativo?
El diseño responsive usa una sola maqueta que fluye y se recoloca para encajar en cualquier ancho de pantalla. El adaptativo usa varias maquetas cerradas, una para cada tamaño, y elige cuál mostrar según el dispositivo, desde el servidor o desde el CSS. En la práctica, casi todas las webs actuales son responsive con algunas decisiones adaptativas encima.
¿Qué es mejor para el SEO, responsive o adaptativo?
Google recomienda el diseño responsive porque es el más fácil de implementar y mantener. Admite el servicio dinámico y las URL separadas, pero con ellos cada error de configuración (redirecciones, cachés, contenido distinto entre versiones) puede convertirse en un problema de indexación. Desde julio de 2024, Google indexa todas las webs con su robot para móviles.
¿Una web adaptativa es más rápida que una responsive?
No necesariamente. Lo que hace rápida una web en el móvil es lo que se descarga, no el enfoque. Una web responsive con imágenes bien dimensionadas, srcset y carga condicional del vídeo puede ser tan ligera como una adaptativa, sin mantener dos versiones.
¿Qué puntos de corte debo usar?
Los que pida tu contenido: allí donde algo deja de caber. Como punto de partida en Elementor, 767 px para el móvil y 1.024 px para la tableta, y 1.366 px para el portátil solo si la cabecera o las rejillas lo necesitan. Lo imprescindible es que el CSS propio use exactamente los mismos números que Elementor.
¿Elementor es responsive?
Sí. Los contenedores son flexibles y cada ajuste se puede cambiar por dispositivo. Pero Elementor parte del escritorio y los demás dispositivos heredan sus valores, así que hay que revisar cada vista. Y la opción de ocultar por dispositivo esconde con CSS: el contenido sigue en la página.
¿Es lo mismo mobile first que la indexación mobile-first?
No. Mobile first es una forma de diseñar y de escribir CSS empezando por la pantalla pequeña. La indexación mobile-first es la forma en que Google rastrea e indexa las webs: con un robot que se presenta como un móvil.
¿Cómo sé si mi web está bien en el móvil?
Mira primero los datos reales del informe de Core Web Vitals de Search Console y de PageSpeed Insights, por separado para el móvil. Después, revisa todos los anchos con el modo dispositivo del navegador y prueba en un iPhone y en un Android reales. La prueba de optimización para móviles de Google ya no existe desde diciembre de 2023.
¿Las container queries sustituyen a las media queries?
No, se complementan. Las media queries siguen siendo las adecuadas para la estructura general de la página. Las container queries sirven para componentes que aparecen en cajas de distinto ancho, como una tarjeta que puede estar en la barra lateral o en la portada. Están disponibles en todos los navegadores principales.
¿Necesito una app si mi web ya es responsive?
Para la mayoría de negocios, no. Una app tiene sentido cuando la gente vuelve muchas veces, necesita funciones del teléfono o trabaja sin conexión. Para que te encuentren, te conozcan y te contacten, una web responsive rápida es suficiente.
¿Es obligatorio por ley que mi web funcione bien en el móvil?
Para muchas tiendas online y servicios dirigidos a consumidores, sí, desde el 28 de junio de 2025, por la Ley 11/2023 de accesibilidad. Entre otras cosas, el contenido tiene que poder usarse a 320 px de ancho, ampliarse al 200 % y tocarse con zonas de al menos 24 × 24 px. Las microempresas que prestan servicios están exentas.
12 — EL RECURSO
La lista de comprobación completa
Todo el artículo en una lista que puedes ir marcando mientras diseñas, maquetas o auditas. Se guarda en tu navegador, así que puedes volver a ella.
Herramienta · Lista de comprobación
Diseño responsive, punto por punto
39 puntos en seis bloques. Lo que marques se guarda solo en este navegador.
RECURSO GRATUITO
Lista de comprobación de diseño responsive
FUENTES Y DOCUMENTACIÓN
- Ethan Marcotte · Responsive Web Design (A List Apart, 25 de mayo de 2010)
- Jeffrey Zeldman · Responsive design. I don't think that word means what you think it means (2011)
- Aaron Gustafson · Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement (2011)
- Google Search Central · Buenas prácticas para webs móviles e indexación mobile-first
- Google Search Central · Mobile-indexing vLast final final (junio de 2024)
- Search Engine Land · Google won’t index sites that do not work on mobile devices after July 5
- Search Engine Land · Google drops Mobile Usability report and Mobile-Friendly Test
- web.dev · Web Vitals
- web.dev · INP becomes a Core Web Vital on March 12
- web.dev · Baseline monthly digest, agosto de 2025 (container queries)
- HTTP Archive · Web Almanac 2025, capítulo de rendimiento
- StatCounter Global Stats · Desktop vs Mobile vs Tablet Market Share Spain
- Lighthouse · Network throttling and CPU throttling
- MDN · HTMLImageElement: srcset
- MDN · @container
- WordPress · Auto Sizes for Lazy Loaded Images in WordPress 6.7
- Elementor Developers · Additional Custom Breakpoints: technical details and gotchas
- W3C · Web Content Accessibility Guidelines (WCAG) 2.2
- W3C · Understanding 2.5.8 Target Size (Minimum)
- BOE · Ley 11/2023, de 8 de mayo, de accesibilidad de determinados productos y servicios
- Fieldfisher · Accesibilidad obligatoria: claves de la transposición española de la Accessibility Act
HISTORIAL DE CAMBIOS
- 17 octubre 2026
- Primera versión.
