Redimensiona al ancho real de visualización de tu sitio y luego comprime con la herramienta de arriba — los tamaños objetivo y el razonamiento de abajo te ayudan a elegir los números correctos para el rol de cada imagen en la página.
Tamaños objetivo por rol
- Imágenes de banner o cabecera (ancho completo, visibles sin bajar): menos de 200KB. Este suele ser el elemento de Largest Contentful Paint de la mayoría de las páginas, así que su tiempo de carga afecta directamente una métrica de Core Web Vitals que Google usa para posicionar.
- Fotos dentro del contenido o del blog: menos de 100KB. Cargan a medida que el usuario baja con el scroll, así que son menos críticas que la imagen de cabecera, pero una página con 10 o más de estas a 500KB cada una suma un peso que la vuelve genuinamente lenta.
- Miniaturas o imágenes de grilla de producto: menos de 50KB cada una. El tamaño pequeño de visualización hace que la compresión agresiva no tenga costo visual, y las grillas suelen mostrar una docena o más a la vez.
Son objetivos, no reglas rígidas — un sitio de portfolio fotográfico necesita legítimamente imágenes más grandes y fieles que un blog cargado de texto. La idea es ser deliberado con ese compromiso en vez de subir directamente lo que produjo la cámara o el celular por defecto.
Por qué esto afecta al posicionamiento, no solo a la experiencia del usuario
Las Core Web Vitals de Google incluyen el Largest Contentful Paint (LCP): el tiempo hasta que el elemento visible más grande — casi siempre una imagen de cabecera o un titular — termina de renderizarse. Es un factor de posicionamiento medido, no una referencia vaga a la “experiencia del usuario”. Una imagen de cabecera de varios megabytes sin optimizar puede empujar el LCP en celular bien más allá del umbral “bueno” de Google (2,5 segundos) en una conexión promedio, y eso alcanza para perjudicar visiblemente el posicionamiento sin importar qué tan bueno sea el contenido de la página.
Redimensiona antes de comprimir, no en lugar de comprimir
Compresión y redimensionado resuelven problemas distintos. La compresión reduce los bits usados para codificar cada píxel; el redimensionado reduce la cantidad de píxeles. Si la columna de contenido de tu sitio tiene 900px de ancho pero estás sirviendo una foto de 4000px de ancho (solo comprimida en peso), estás gastando bits codificando detalle que ningún navegador va a mostrar a ese ancho — el mismo presupuesto de archivo aplicado a una imagen ya redimensionada a 900px se ve notablemente más nítida. Redimensiona siempre primero al ancho máximo real de visualización.
WebP vs. JPEG para uso web
El WebP suele ganarle al JPEG entre un 25% y un 35% con calidad visual equivalente para contenido fotográfico, con soporte universal en navegadores modernos. Si tu CMS o plataforma lo soporta, convertir JPEGs ya comprimidos a WebP es casi una reducción de peso gratis. El ahorro suele ser todavía mayor para gráficos y capturas de pantalla convertidos desde PNG — mira la solución relacionada más abajo.
La carga diferida no reemplaza a la compresión
Postergar las imágenes fuera de pantalla con loading="lazy" mejora la carga inicial al no descargar todo de una vez, pero cada imagen igual se descarga en su peso completo apenas entra en pantalla — y tu imagen de cabecera o LCP es visible de inmediato, así que no debería tener carga diferida en absoluto. La compresión reduce los bytes realmente transferidos; la carga diferida solo cambia cuándo se transfieren.
Preguntas frecuentes
- ¿Qué peso de archivo debería tener realmente una imagen de una página web?
- Como regla práctica: imágenes de banner o cabecera (ancho completo, visibles sin bajar) por debajo de 200KB, fotos dentro del contenido o del blog por debajo de 100KB, y miniaturas o imágenes de grilla de producto por debajo de 50KB. No son límites estrictos — son objetivos que mantienen el peso total de imágenes de una página típica en un rango (más o menos 1-2MB en total) que carga rápido en una conexión móvil promedio, lo cual afecta directamente a las Core Web Vitals de Google y al posicionamiento en buscadores.
- ¿El peso de la imagen realmente afecta al SEO?
- Sí, de forma indirecta pero medible. Las Core Web Vitals de Google incluyen el Largest Contentful Paint (LCP) — el tiempo que tarda en renderizarse el elemento visible más grande, casi siempre una imagen de cabecera — como señal de posicionamiento. Una imagen de cabecera sin optimizar de 3-5MB puede por sí sola empujar el LCP de una página a la zona 'deficiente' en conexiones móviles, lo cual puede afectar el posicionamiento sin importar lo buena que sea el resto del contenido.
- ¿Debería redimensionar la imagen, comprimirla, o las dos cosas?
- Las dos, en ese orden. Redimensiona primero al ancho máximo real de visualización (el cuerpo de una entrada de blog rara vez supera los 800-1200px de ancho incluso en un monitor grande, por el max-width del CSS de la columna de contenido), y después comprime. Servir una foto de cámara de 4000px de ancho solo comprimida en peso desperdicia bits codificando detalle que ninguna pantalla va a mostrar, cuando ese mismo presupuesto de archivo aplicado a una imagen ya redimensionada a 1000px se ve visiblemente más nítida.
- ¿Cuándo conviene usar WebP en vez de JPEG para las imágenes del sitio?
- Casi siempre para fotos: el WebP suele generar archivos entre 25% y 35% más pequeños que el JPEG con calidad visual equivalente, y lo soporta todo navegador lanzado desde 2020. Usa JPEG solo si necesitas específicamente compatibilidad con software muy antiguo que procesa las imágenes del sitio fuera de un navegador (algunos plugins de CMS viejos, ciertos flujos de impresión desde la web). Consulta convertir PNG a WebP para el mismo compromiso partiendo de PNG.
- ¿Y la carga diferida (lazy loading)? ¿Eso significa que no necesito comprimir las imágenes?
- La carga diferida (el atributo nativo loading="lazy" o una librería JS) posterga las imágenes fuera de pantalla hasta que el usuario se acerca haciendo scroll, lo cual ayuda a la carga inicial pero no reduce el peso final de descarga — cada imagen se sigue descargando en su peso completo apenas entra en el área visible. Es un complemento a la compresión, no un sustituto, y no hace nada por tu imagen de LCP, que por definición es visible de inmediato y no debería tener carga diferida en absoluto.