Velocidad de página móvil: La lista de verificación de optimización de imágenes

Junio 28, 2026 · Editorial de JPG.now · Rendimiento web y SEO

Velocidad de página móvil: La lista de verificación de optimización de imágenes

Es viernes por la tarde y un cliente clave le acaba de enviar un correo a tu CEO quejándose de que la página del producto "tardó una eternidad en cargar" cuando intentaron compartirla con un compañero en el tren. Abres la página en tu Wi-Fi de oficina — 1.2 segundos, rápido. Abres la misma página conectada a tu teléfono afuera del edificio — 6.8 segundos, doloroso. La imagen principal pesa 3.4 MB. La versión de escritorio es invisible para este cliente; la experiencia móvil es toda la impresión de la marca. Esta es la conversación que convierte "deberíamos optimizar imágenes" en "debemos optimizar imágenes para el lunes".

El ancho de banda móvil es el cuello de botella. Incluso en una conexión 5G, el rendimiento medio real es de 30 a 60 Mbps con alta variabilidad de latencia, y una fracción significativa de las sesiones móviles aún funcionan en 3G o 4G congestionado a menos de 5 Mbps. El mayor contribuyente al peso de una página móvil, en la mayoría de los sitios, son las imágenes. Aquí está la lista completa que logra que tu página móvil cargue en menos de 2 segundos, en orden del mayor impacto al menor detalle.

Antecedentes: por qué el móvil es el peor caso

Los dispositivos móviles acumulan cuatro limitaciones que los de escritorio evitan en su mayoría: ancho de banda variable, alta latencia, CPU limitada para decodificar imágenes y pantallas pequeñas que castigan los cambios de diseño. Una imagen principal de 2 MB tarda 200 ms en descargarse en una conexión por cable y 4+ segundos en un enlace LTE inestable. Lighthouse y Search Console informan una puntuación "Móvil" por separado del escritorio, y la ponderación de clasificación de Google prefiere los datos de campo móvil en la mayoría de las categorías.

Paso a paso: la secuencia de optimización móvil

  1. Audita en un teléfono real usando la depuración remota de Chrome o BrowserStack. Las métricas de laboratorio subestiman el dolor móvil.
  2. Identifica el elemento LCP a través de la vista móvil de PageSpeed Insights.
  3. Redimensiona las fuentes a aproximadamente 2x el ancho de viewport objetivo más pequeño.
  4. Convierte formatos mediante JPG a WebP y JPG a AVIF.
  5. Comprime mediante Comprimir JPG con una calidad adecuada para móvil.
  6. Implementa srcset con 3 puntos de interrupción.
  7. Carga diferida de todo lo que esté debajo del primer viewport.
  8. Precarga y prioriza la imagen principal.

1. Redimensiona las imágenes de origen a dimensiones móviles

El error más común es servir una imagen de 2,400 px a una pantalla de teléfono de 380 px de ancho. El teléfono descarga todos los 2,400 px de datos, los decodifica y renderiza una versión de 380 px. Una descarga de 400 KB se convierte en una de 12 KB si envías una imagen del tamaño adecuado. Para diseño responsive móvil primero:

  • Imágenes principales: de 800 a 1,200 px de ancho
  • Imágenes de contenido del cuerpo: de 600 a 800 px de ancho
  • Miniaturas: de 300 a 400 px de ancho

Usa srcset para enviar diferentes tamaños a diferentes viewports. El navegador elige el más pequeño que cumpla con el requisito de visualización.

2. Convierte a WebP o AVIF

WebP reduce el tamaño del archivo entre un 30 y un 40 por ciento en comparación con JPG con una calidad visual equivalente. AVIF reduce otro 20 a 30 por ciento adicional. Safari y Chrome móvil admiten ambos formatos en 2026. Convierte tus imágenes principales y de cuerpo mediante JPG a WebP y JPG a AVIF, y sírvelas a través de una etiqueta <picture> con una alternativa JPG.

Ahorros por imagen en una imagen principal móvil típica: de 380 KB JPG a 240 KB WebP a 150 KB AVIF. En 10 imágenes en una página, eso son 2.3 MB de ancho de banda móvil.

3. Comprime agresivamente

Las pantallas móviles ocultan muchos artefactos de compresión. Un JPG que se ve granuloso con calidad 65 en un monitor de escritorio se ve bien en una pantalla de teléfono de 6 pulgadas. Objetivos de calidad práctica para móvil:

  • JPG principal: calidad 78 a 82
  • JPG cuerpo: calidad 72 a 78
  • WebP todo: calidad 75 a 80
  • AVIF todo: calidad 65 a 75

Prueba una muestra con Comprimir JPG en estos objetivos y mírala en un teléfono real antes de confirmar.

4. Define puntos de interrupción srcset

Tres puntos de interrupción cubren el 90 por ciento de los dispositivos:

<img srcset="hero-400.webp 400w,
             hero-800.webp 800w,
             hero-1600.webp 1600w"
     sizes="(max-width: 600px) 100vw,
            (max-width: 1200px) 50vw,
            800px"
     src="hero-800.webp"
     alt="..." width="800" height="500">

El navegador calcula qué tamaño descargar según el ancho del viewport y la relación de píxeles del dispositivo. Una pantalla de 380 px con DPR 2x obtendrá la variante de 800w, no la de 1.600w.

5. Carga diferida de imágenes debajo del pliegue

Agrega loading="lazy" a cada imagen que no esté en el primer viewport. La carga diferida nativa del navegador es compatible con todos los navegadores móviles principales en 2026. La imagen principal sobre el pliegue se carga ansiosamente — nunca apliques carga diferida al elemento LCP.

Impacto concreto: en una página con 25 imágenes y un primer viewport de 5 imágenes, la carga diferida evita 20 descargas de imágenes para los visitantes que rebotan. Eso puede ahorrar de 4 a 8 MB por sesión rebotada.

6. Precarga la imagen LCP

Agrega al encabezado del documento:

<link rel="preload" as="image" href="hero-800.webp"
      imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
      imagesizes="(max-width: 600px) 100vw, 50vw">

Esto inicia la descarga del hero antes de que el navegador termine de analizar el resto del HTML. Mejora típica de LCP: de 200 a 600 ms.

7. Establece fetchpriority en la imagen LCP

<img fetchpriority="high"> le indica al navegador que priorice esta descarga sobre otros recursos. Combínalo con precarga para obtener las mayores mejoras en móvil, donde el ancho de banda de descarga paralela es limitado.

8. Establece ancho y alto explícitos

Cada imagen necesita los atributos width y height. El navegador los usa para calcular la relación de aspecto y reservar espacio de diseño antes de que llegue la imagen. Sin ellos, la página se mueve al cargar las imágenes, un golpe de CLS (Cumulative Layout Shift) que Google reporta por separado del LCP.

Usa la calculadora de relación de aspecto para confirmar que las proporciones ancho/alto coincidan con las dimensiones reales de la imagen si tu CMS no las autocompleta.

9. Elimina los metadatos EXIF

Los archivos de cámara llevan de 30 a 80 KB de metadatos: coordenadas GPS, número de serie de la cámara, información del lente. La mayoría es inútil en la web y un riesgo de privacidad en algunos casos. Elimínalos con jpegoptim --strip-all o Comprimir JPG (la mayoría de los compresores web los eliminan por defecto). Ahorro por imagen: 30 a 80 KB. En 10 imágenes: 300 a 800 KB ahorrados.

10. Sirve desde un CDN

Los usuarios móviles suelen estar físicamente más lejos de tu servidor de origen que los de escritorio. Un CDN con nodos globales (Cloudflare, Fastly, BunnyCDN) reduce la latencia de 100 a 400 ms en una solicitud móvil típica. Combinado con HTTP/3 (QUIC), que maneja mejor la pérdida de paquetes en conexiones móviles inestables, esto supone una mejora del 5 al 15 por ciento en la carga total de la página.

11. Usa Save-Data y carga según la conexión

El encabezado Save-Data: on lo establecen los usuarios que han activado el modo de ahorro de datos en Chrome o Edge. Detéctalo en el servidor y sirve imágenes de menor calidad:

if ($http_save_data = "on") {
    rewrite ^(.*)\.jpg$ $1-lowq.jpg break;
}

Para usuarios con conexiones lentas, esto puede ser la diferencia entre una página utilizable y un tiempo de espera agotado.

12. Audita el resultado móvil real

Abre Chrome DevTools, ve a Lighthouse, ejecuta una auditoría Móvil. La sección Oportunidades enumera exactamente qué imágenes son demasiado grandes, no están comprimidas o están en formatos antiguos. Corrige los 3 elementos principales, vuelve a auditar, repite. Dos iteraciones suelen llevar una página de una puntuación de 40 a 90+.

El informe de Core Web Vitals de Search Console muestra datos de campo de usuarios móviles reales: esta es la puntuación que Google usa para el ranking. Los datos de laboratorio y los de campo pueden diferir de 1 a 2 segundos; confía en los datos de campo.

Errores comunes y cómo solucionarlos

  • Error: probar solo en Wi-Fi de escritorio. Solución: limita DevTools a "Slow 3G" o prueba en un teléfono real conectado a LTE.
  • Error: usar un solo tamaño de imagen para todos los viewports. Solución: implementa srcset con al menos tres puntos de interrupción.
  • Error: lazy-loading de la imagen hero. Solución: establece loading="eager" en la imagen LCP y añade fetchpriority="high".
  • Error: ignorar CLS mientras optimizas LCP. Solución: establece ancho/alto en cada imagen para reservar espacio de diseño.
  • Error: confiar en Lighthouse por encima de los datos de campo de Search Console. Solución: monitorea los números de CrUX; son los que Google usa para el ranking.
  • Error: no respetar Save-Data. Solución: sirve imágenes de menor calidad cuando el encabezado está establecido.

Ejemplos reales

Las páginas de listados móviles de Airbnb sirven una secuencia de WebPs con dimensiones adecuadas mediante srcset, lazy-load de imágenes de galería bajo el pliegue y precargan el primer hero. La mediana de LCP móvil es inferior a 2.0 segundos a nivel global.

Las páginas de artículos de The Guardian usan AVIF para las imágenes hero en Safari 16+ y WebP en el resto, todo servido a través de Fastly. Su promedio de puntuación Lighthouse móvil en 1,000 artículos muestreados es 91.

Un minorista estadounidense (anonimizado) pasó de un LCP móvil de 5.4 segundos a 1.7 segundos al completar 10 de los 12 elementos de la lista. La tasa de conversión móvil subió un 18 por ciento en el trimestre siguiente.

Comparativa de listas para móvil

OptimizaciónEsfuerzoImpacto en LCP móvilRiesgo si se omite
Redimensionar fuentesBajoGrandeAncho de banda desperdiciado
Conversión a WebP/AVIFMediaGrandeArchivos 30-50% más grandes
Compresión agresivaBajoMediaArchivos 10-30% más grandes
Puntos de interrupción srcsetMediaMediaDescargas móviles sobredimensionadas
Carga diferidaBajoPequeño (LCP)Bytes desperdiciados en TTI
Precarga + fetchpriorityBajoMediaPérdida de 200–600 ms en LCP
CDN + HTTP/3MediaPequeñoLatencia de 100–400 ms

La lista de verificación de menos de 2 segundos

  1. Imágenes de origen redimensionadas a 2x la pantalla
  2. WebP y AVIF generados con convertidor de imágenes
  3. Calidad JPG de 78 a 82, calidad WebP de 75 a 80
  4. srcset en 3 puntos de interrupción
  5. loading=lazy en contenido bajo el pliegue
  6. preload + fetchpriority=high en LCP
  7. width y height en cada imagen
  8. EXIF eliminado mediante Comprimir JPG
  9. Servido por CDN con HTTP/3
  10. Encabezado Save-Data respetado
  11. Puntuación de Lighthouse móvil superior a 90
  12. Confirmación de datos de campo en Search Console después de 28 días

Consejos avanzados

  1. Genera marcadores de posición de color dominante mediante la paleta de colores como fondos CSS antes de que llegue la imagen.
  2. Usa content-visibility: auto en secciones bajo el pliegue para saltarte el trabajo de maquetación en páginas largas.
  3. Subconjunto de fuentes web junto con imágenes: una fuente de 200 KB puede costar tanto como una imagen principal.
  4. Almacena en caché las imágenes principales de forma agresiva con un max-age largo y busting de caché mediante hash del nombre de archivo.
  5. Incluye una vista previa de baja calidad como base64 en el HTML para una primera renderización instantánea.
  6. Usa la calculadora de tamaño de archivo de imagen para presupuestar tus recuentos de bytes de antemano.
  7. Prueba con CPU limitada en DevTools (ralentización 4x) para simular un Android de gama media.

Preguntas frecuentes

¿Por qué mi página se siente más lenta en móvil de lo que sugiere mi puntuación de Lighthouse?

Lighthouse usa un perfil de laboratorio que puede no coincidir con la red real de tu audiencia. Revisa los datos de campo de CrUX.

¿Debería servir AVIF a Safari móvil?

Sí: Safari 16+ admite AVIF. Usa una etiqueta <picture> con detección de formato.

¿Qué tamaño deberían tener las imágenes principales en móvil?

De 800 a 1,200 px de ancho es suficiente para los teléfonos más grandes actuales con 3x DPR.

¿Funciona la carga diferida en iOS Safari?

Sí, desde Safari 15.4.

¿Qué pasa con las imágenes HEIC subidas desde iPhone?

Conviértelas mediante HEIC a JPG al recibirlas. La mayoría de las CDN no entienden HEIC.

¿Debería servir imágenes diferentes a usuarios de 5G vs 3G?

El encabezado Save-Data es un buen indicador. Para un control más fino, la API Network Information expone effectiveType.

¿Optimizar imágenes afectará mi posicionamiento en búsquedas orgánicas?

Sí: Core Web Vitals es una señal de ranking, y el peso de las imágenes domina el LCP móvil en la mayoría de los sitios.

Números reales de una auditoría móvil

Antes: 8.2 MB de peso de página, LCP 5.1 s, Lighthouse móvil 38.
Después: 1.4 MB de peso de página, LCP 1.7 s, Lighthouse móvil 94.

Las mejoras se acumularon: ningún cambio por sí solo lo explicaba todo. Redimensionar redujo un 60 por ciento, WebP redujo otro 30 por ciento de lo que quedaba, AVIF redujo otro 20 por ciento. La carga diferida redujo los bytes iniciales en un 70 por ciento para la primera representación. La precarga recortó 400 ms del LCP. Cada cambio fue pequeño. Juntos llevaron la página de «el usuario se rinde» a «el usuario no lo nota».

Elige los tres elementos principales de la lista que aún no hayas hecho. Pasa una imagen por comprimir imagen con la configuración deseada, verifica el resultado en un teléfono y luego automatiza el resto en tu pipeline de compilación o CDN. La lista completa te lleva una tarde y da dividendos cada vez que alguien abre el sitio en móvil. Combínala con el convertidor de imágenes y Comprimir JPG para el mantenimiento continuo.

La consideración del viewport móvil primero

«Móvil primero» en diseño significa que el viewport más pequeño es el diseño canónico. El mismo principio se aplica a las imágenes: diseña para el teléfono de 380 px de ancho y escala hacia escritorio. Si tu hero tiene 800 px de ancho en el diseño móvil, ese es el tamaño para el que optimizas. Los visitantes de escritorio reciben variantes srcset más grandes, pero el caso base es el móvil.

Esto invierte el flujo de trabajo tradicional donde los diseñadores producían un master de 1,920 px para escritorio y el ingeniero escalaba hacia abajo para móvil. El resultado de la inversión es que las imágenes móviles se dimensionan intencionalmente en lugar de reducirse a regañadientes, y el presupuesto de bytes en móvil es la línea base en lugar de una ocurrencia tardía. Los sitios que adoptan imágenes móviles primero suelen ver su LCP móvil caer entre un 30 y un 50 por ciento solo por el cambio de diseño, independientemente de cualquier cambio de código.

Calidad de imagen adaptativa a la conexión

La API Network Information expone el tipo de conexión efectiva del visitante (4g, 3g, 2g, slow-2g) mediante navigator.connection.effectiveType. Las páginas pueden leer esto y servir diferente calidad de imagen según corresponda. Para visitantes en slow-2g, sirve JPG de calidad 60 y omite AVIF; para visitantes en 4g, sirve WebP o AVIF de calidad 80.

La implementación es JavaScript en el cliente eligiendo la fuente srcset correcta, o del lado del servidor basándose en el encabezado Save-Data. De cualquier manera, la ganancia en la cola lenta es grande — a veces de 2 a 3 segundos de LCP para visitantes con conexiones débiles. La cola media y rápida no ven cambios porque ya reciben la versión de alta calidad.

Advertencias sobre apps en WebView

Una fracción significativa del tráfico móvil proviene de navegadores dentro de aplicaciones como Facebook, Instagram, TikTok, Twitter y LinkedIn. Estos WebViews están basados en Chromium o WebKit pero con comportamientos sutilmente diferentes: versiones más antiguas, APIs restringidas, a veces soporte HTTP/3 roto. Prueba tu sitio móvil explícitamente dentro de estos contextos; las pruebas de Lighthouse en laboratorio se ejecutan en un Chrome limpio y pasan por alto problemas específicos de WebView.

Errores comunes en WebView: el soporte de AVIF va por detrás del Chrome real entre 6 y 12 meses, la carga diferida nativa a veces no se activa correctamente, y ciertas características de diseño CSS recurren a rutas más lentas. La solución es elegir formatos conservadores (WebP + fallback a JPG) y verificar el rendimiento dentro del WebView mediante depuración remota desde un Mac conectado al dispositivo.

Latencia táctil y velocidad percibida en móvil

La latencia táctil — el tiempo entre un toque y la retroalimentación visible — es un factor oculto en la percepción de velocidad móvil. Una página que termina de descargarse en 1.5 segundos pero tarda 300 ms en responder al primer toque se siente lenta. La decodificación intensiva de imágenes puede monopolizar el hilo principal durante esa primera interacción crítica.

Mitígalo difiriendo la decodificación de imágenes no críticas para LCP mediante decoding="async", dividiendo los paquetes de JavaScript para que el análisis inicial se mantenga por debajo de 100 ms, y evitando tareas de larga duración durante los primeros 2 segundos después de cargar la página. La API Long Task en Chrome DevTools muestra bloqueos del hilo principal de más de 50 ms; procura que no haya ninguno entre la carga de la página y la primera interacción del usuario.

Particularidades de iOS Safari

iOS Safari tiene peculiaridades históricas en la representación de imágenes que las herramientas de escritorio pasan por alto. Background-attachment: fixed en imágenes hero causa un molesto scroll jank. El soporte de WebP animado llegó en iOS 14 pero con errores de bucle que persistieron hasta iOS 16. CSS aspect-ratio funciona desde iOS 15.4 pero tiene diferencias sutiles de representación con Chrome.

Prueba cada cambio en un iPhone real, no solo en el simulador de Xcode. El simulador ejecuta el WebKit de escritorio y no detecta comportamientos específicos de iOS. Si no puedes probar en hardware, usa BrowserStack o Sauce Labs para pruebas en dispositivos reales en CI. El costo es unos pocos dólares por ejecución de prueba; el valor es detectar errores que el QA de escritorio nunca ve.

Limitaciones de batería y térmicas

Los teléfonos modernos reducen el rendimiento de la CPU cuando la batería está baja o térmicamente caliente. Un sitio que funciona bien en un teléfono nuevo puede ir lento en el mismo teléfono después de 30 minutos de uso. Las páginas con muchas imágenes agravan esto porque cada decodificación de imagen impacta la GPU y calienta el dispositivo.

Prueba en un dispositivo térmicamente estresado: deja el teléfono en una habitación cálida, ejecuta un juego 3D durante 5 minutos, luego carga tu página. La diferencia de rendimiento frente a un dispositivo frío puede ser del 50 por ciento o más. Optimizar para el peor caso (teléfono caliente, batería baja, red congestionada) te da un sitio que se siente rápido incluso cuando las condiciones son malas.

← Todos los artículos