Diseño web responsivo, probado en dispositivos reales

En español circulan varios nombres para algo muy parecido, y conviene separarlos antes de seguir, porque la diferencia técnica existe aunque casi nadie la respete al hablar.

El diseño responsivo parte de una maquetación fluida. Los anchos se expresan en proporciones, no en píxeles fijos, y la página se recalcula de forma continua según el espacio que tiene. Entre un móvil de 360 puntos de ancho y otro de 430 no hay un salto, hay una transición.

El diseño adaptativo, en sentido estricto, hace otra cosa: define unas cuantas maquetaciones fijas, una por umbral, y sirve la que toca. Dentro de cada umbral nada se mueve, y el cambio ocurre de golpe al pasar de uno al siguiente.

En la conversación diaria, en cambio, se usan como sinónimos, y el anglicismo responsive convive con ellos sin molestar a nadie: mucha gente escribe diseño web adaptable o diseño web responsive y espera lo mismo. Nosotros también los alternamos al hablar con un cliente, pero por dentro no son iguales, y la diferencia se nota en los anchos intermedios, esos que nadie mira en la presentación.

Lo que entregamos es fluido con puntos de corte: se adapta de forma continua y, en unos pocos anchos, cambia de estructura.

Una lista de modelos envejece. Cada año aparecen pantallas nuevas, plegables que cambian de ancho a mitad de sesión y navegadores que reservan más o menos espacio para sus barras. Un punto de corte sacado del contenido no envejece: describe cuándo se rompe tu página, no qué teléfono estaba de moda el año pasado.

El método es poco glamuroso: se estrecha la ventana despacio y se mira qué falla primero. Las señales suelen ser estas.

La línea de texto se pasa de largo. Por encima de unos ochenta caracteres el ojo pierde el renglón al volver al principio, así que ahí hay un límite natural para el cuerpo de texto.

Las tarjetas se aprietan. Tres columnas que caben bien a 1200 puntos se vuelven ilegibles a 900, y toca bajar a dos.

Algo se desborda: una tabla, un bloque de código, una imagen con ancho mínimo o un botón con un texto largo que no parte.

El menú deja de caber en una línea. Ese es el momento de plegarlo, no un ancho fijo copiado de otro proyecto.

Salen normalmente tres o cuatro puntos de corte por proyecto, y no tienen por qué ser los mismos en toda la web. Hay componentes que se miden contra su contenedor y no contra la ventana, y así la misma tarjeta se comporta distinto en la portada y en una columna lateral estrecha.

El error más caro de una web en móvil casi nunca es el diseño, es una imagen de 2400 píxeles de ancho encogida por CSS hasta ocupar 380. En la pantalla se ve correcta. En los datos que consume el visitante, y en lo que tarda en aparecer el contenido principal, se ve otra cosa.

Lo que hacemos al construir la web: generar varios tamaños reales de cada imagen al subirla, declararlos para que el navegador elija el que necesita según el ancho y la densidad de pantalla, servir formatos modernos con alternativa para los navegadores que no los admiten, y fijar las proporciones de cada hueco para que el texto no salte cuando la imagen carga. La carga diferida se aplica a lo que está por debajo de la primera pantalla, nunca a la imagen principal, que es justo la que se mide.

En un catálogo como el de Zelviro, una tienda online con más de 13.000 productos integrada con eMAG, Trendyol y Temu, esto deja de ser un detalle de purista: una página de listado enseña decenas de miniaturas a la vez y cada kilobyte de más se multiplica por todas ellas.

El icono de tres líneas no es el problema. El problema es lo que se mete dentro sin pensarlo.

No se esconden nunca las cosas por las que alguien entra desde el teléfono: el número de contacto, el buscador si vendes catálogo, el carrito con su contador y el selector de idioma si la web está en varios. Todo eso se ve sin abrir nada.

Dentro del menú plegado va lo demás: secciones secundarias, páginas legales, subcategorías profundas. El botón se etiqueta con la palabra Menú al lado del icono y con un área de pulsación cómoda.

Un detalle que se paga caro: el menú tiene que existir en el código de la página, no construirse solo cuando alguien lo pulsa. Si los enlaces aparecen únicamente tras la interacción, los rastreadores pueden no verlos.

Cuando una web cambia de naturaleza, el menú cambia con ella. Climatizare.net era una web de servicios de climatización y la convertimos en tienda online completa, sin reescribir el código y con un despliegue sin caída del servicio. Un sitio que antes solo explicaba servicios pasa a necesitar buscador, carrito y categorías a la vista.

Una tabla es el contenido que peor se porta en un móvil, y la salida depende de qué hace el lector con ella.

Lo que no funciona es reducir el tamaño de letra hasta que todo entre. Tampoco vale un desplazamiento lateral sin pista visual: si no se ve que la tabla sigue, la mitad de los lectores no descubre que hay más columnas a la derecha.

Cuando la tabla se convierte en fichas, cada dato se queda con su etiqueta delante: la cabecera ha desaparecido y sin ella los números no significan nada.

Los proyectos con datos densos son los que más obligan a decidir aquí. Helix Trading es una plataforma de trading educativo con simulador propio y el flujo completo de challenges, construida en Next.js y PostgreSQL, con autenticación separada por rol. En una plataforma así, cada pantalla con cifras exige elegir qué columnas son imprescindibles y cuáles se consultan una vez al mes.

El simulador del navegador cambia el tamaño de la ventana y finge ser otro navegador. Es útil y lo usamos todos los días, pero hay problemas que solo aparecen con el aparato en la mano.

La altura útil cambia sola. La barra del navegador se oculta y reaparece al desplazarse, así que la altura de la pantalla no es la que dice la hoja de estilos. De ahí sale el botón que en el móvil queda medio tapado.

El teclado del sistema tapa el campo que estás rellenando. En un formulario largo, eso decide si alguien lo termina o lo abandona.

La zona segura existe. Las esquinas redondeadas, la muesca superior y la barra de gestos inferior se comen espacio que hay que respetar.

El dedo no es el ratón. No hay estado de paso por encima y lo que en el escritorio se resuelve con un puntero fino, en el móvil necesita un objetivo grande.

Y el rendimiento. Un teléfono de gama media con cobertura normal tarda bastante más que tu ordenador con fibra, y así es como entra la mayor parte del tráfico.

La comprobación antes de publicar es siempre la misma: el recorrido completo en un aparato real, el formulario enviado, un pedido de prueba si hay tienda y la pantalla girada.

Google indexa la versión móvil de tu web. No la de escritorio con la móvil como apéndice: la móvil es la que se guarda y la que se valora. De ahí salen tres consecuencias prácticas.

Lo que no está en el móvil, no cuenta. Si un bloque de texto, un listado de servicios o un pie con los datos de la empresa se esconde por completo en pantallas pequeñas, para el buscador es como si no existiera. Plegado y accesible sí vale; eliminado del código, no.

Las señales tienen que coincidir. Mismos títulos, mismos encabezados, mismas imágenes con su texto alternativo y los mismos datos estructurados en las dos versiones.

Y la velocidad se mide con usuarios reales, en sus teléfonos, no en una prueba de laboratorio. Esa parte, con las Core Web Vitals y todo lo que las condiciona, está desarrollada en la página de SEO técnico.

Dicho sin adornos: una web que funciona bien en móvil no sube puestos por sí sola, y nadie controla el orden de los resultados de Google. Lo que hace es quitar de en medio un motivo para no subir.

Páginas relacionadas: velocidad y Core Web Vitals en móvil