Móvil primero significa que la web se diseña y se construye para la pantalla del celular, y solo después se amplía al escritorio. Tu web probablemente hace lo contrario: se maquetó en un monitor de 27 pulgadas y luego se comprimió para que «entrara» en el móvil. Eso no es móvil primero. Es escritorio encogido.

La diferencia no es filosófica, se ve en la factura. Deloitte y la consultora 55, en un estudio encargado por Google sobre más de 30 millones de sesiones en 37 marcas europeas y americanas, midieron qué pasa al mejorar la velocidad móvil solo 0,1 segundos: la conversión subió un 8,4% en las webs de retail y un 10,1% en las de viajes. Una décima de segundo. Si tu tráfico entra por celular desde Instagram y ahí es donde tu web va más lenta, estás pagando pauta para llevar gente a la peor versión de tu tienda.

Responsive no es móvil primero

Son dos cosas distintas y se confunden todo el tiempo.

Responsive es que el diseño se acomode a cualquier ancho de pantalla. Casi cualquier plantilla de Shopify o WordPress lo es desde hace años.

Móvil primero es que el móvil sea el caso base: la versión ligera es la que se manda por defecto, y el escritorio añade cosas encima. En CSS se nota en una línea. Una hoja de estilos móvil primero escribe las reglas para pantalla pequeña y luego amplía con @media (min-width: 768px). Una hecha al revés parte del escritorio y va tapando con @media (max-width: 768px).

Por qué importa: en el segundo caso el celular descarga igual todo lo que el escritorio (el carrusel, las tres tipografías, la imagen de 2400 px de ancho) y encima ejecuta reglas extra para esconderlo. display: none oculta el elemento, no evita la descarga. El teléfono paga el ancho de banda de algo que nunca se ve.

Cómo saber en 3 minutos si tu web lo cumple

No hace falta que nadie te audite nada para empezar. Haz esto:

1. Abre PageSpeed Insights y pega la URL de una ficha de producto, no la de la portada. Mira la pestaña Móvil. Es la única que importa.
2. Abre tu web en Chrome, pulsa F12, luego Ctrl+Shift+M para la vista de móvil. Elige un iPhone SE (375 px de ancho): si funciona ahí, funciona en todo.
3. En la pestaña Network, cambia la velocidad a «Slow 4G» y recarga con Ctrl+Shift+R. Cronometra. Lo que aparezca en los primeros 3 segundos es lo que ve el cliente real.
4. En esa misma pestaña, ordena por tamaño. Si una sola imagen pesa más de 200 KB, ya tienes el primer culpable.
5. Prueba a comprar algo con una sola mano, de pie. En serio. Ahí salen los fallos que ningún informe detecta.

Lo que suele estar roto

Estos son los fallos concretos que aparecen cuando una web se hizo de escritorio hacia abajo, y cómo se arreglan.

Ninguno de estos es un rediseño. Son arreglos de horas, y mueven la aguja. El marketplace argentino Agrofy documentó en un caso publicado por Google que, tras mejorar su LCP un 70% y su CLS un 72%, el abandono durante la carga de las fichas de producto pasó del 3,8% al 0,9%.

El checkout es donde se paga la factura

El Baymard Institute, promediando 50 estudios sobre abandono de carrito, sitúa la media documentada en un 70,22%. Una parte de eso es gente que compara precios y nunca iba a comprar. Otra parte es fricción pura, y en móvil la fricción se multiplica porque escribir en un teclado de pulgar es caro. El propio Baymard calcula, a partir de su investigación de usabilidad de checkout, que la tienda grande media puede mejorar su conversión un 35% solo arreglando esa experiencia.

Lo que revisas en tu propio checkout, campo por campo:

• Cuántos campos hay. Cada campo que no necesitas para despachar el pedido es una oportunidad de que se vaya. La fecha de nacimiento no la necesitas.
• Teclado correcto. El campo de email debe abrir el teclado con arroba (type="email"), el de teléfono el numérico. Si abre el alfabético completo, está mal puesto.
• Autocompletado activo. Con los atributos autocomplete bien puestos, el navegador rellena dirección y tarjeta de una vez. Sin ellos, el cliente escribe todo a mano.
• El botón de pagar visible sin hacer scroll en cuanto el resumen está completo.
• Que la pasarela sea local. Si el método de pago que usa tu cliente no está, no hay optimización que lo salve.

Qué hacer el lunes por la mañana

Una hora, por orden. No hace falta tocar el diseño.

1. Mide. PageSpeed Insights sobre tres URLs: portada, una ficha de producto y el carrito. Anota los tres números de móvil. Los umbrales «buenos» que Google publica en web.dev son LCP por debajo de 2,5 segundos, CLS por debajo de 0,1 e INP por debajo de 200 ms, medidos en el percentil 75 de las cargas.
2. Pesa las imágenes. En DevTools, pestaña Network, ordenadas por tamaño. Todo lo que pase de 200 KB se convierte a WebP y se le pone srcset. En una tienda, el elemento que marca el LCP casi siempre es la foto de producto o el banner: si adelgaza esa imagen, adelgaza la métrica entera, y es trabajo de un día.
3. Marca la imagen principal. La foto grande de arriba lleva fetchpriority="high" y no lleva loading="lazy". Las de más abajo, al revés.
4. Cuenta las capas. Cabecera fija, cookies, chat, popup de descuento. Deja una. Mide otra vez.
5. Compra en tu propia tienda desde el celular, con datos móviles y no con el wifi de la oficina. Apunta cada vez que dudes o falles al tocar. Esa lista es tu backlog.

Si al terminar el punto 1 el número de móvil sigue por encima de 4 segundos y el problema no son las imágenes, el tema está construido de escritorio hacia abajo y no se arregla optimizando: se arregla rehaciendo la capa de front. Es lo que resuelve nuestra tienda o landing express, mobile-first y por debajo de 3 segundos, desde US$350.

Preguntas frecuentes

¿Móvil primero y responsive son lo mismo?

No. Responsive es que el diseño se adapte a cualquier pantalla. Móvil primero es que la versión de móvil sea la que se diseña y se carga primero, y el escritorio la ampliación. Una web puede ser responsive y aun así mandarle al celular todo el peso de la versión de escritorio.

¿Cómo compruebo si mi web cumple móvil primero?

Abre PageSpeed Insights, pega tu URL y mira la pestaña Móvil, no la de escritorio. Después abre tu web en Chrome con F12, activa la vista de móvil (Ctrl+Shift+M), pon la red en «Slow 4G» y recarga. Lo que veas en los primeros 3 segundos es lo que ve tu cliente.

¿Qué tamaño mínimo debe tener un botón en móvil?

Apple recomienda 44x44 puntos y Material Design de Google 48x48 dp. El criterio 2.5.8 de las WCAG 2.2 pone el mínimo accesible en 24x24 píxeles CSS. Por debajo de eso el dedo falla y el usuario reintenta o se va.

Fuentes

• Deloitte y 55, por encargo de Google — Milliseconds Make Millions
• Google / web.dev — Agrofy Market: A 70% improvement in LCP correlated to a 76% reduction in load abandonment
• Baymard Institute — 50 Cart Abandonment Rate Statistics
• Baymard Institute — Checkout Usability Research
• Google / web.dev — Métricas web esenciales (Web Vitals)