Optimización de imágenes web: cómo reducir el peso en KB mejorando el SEO de tu sitio

Por qué las imágenes deciden tus Core Web Vitals

Los Core Web Vitals son tres métricas, y las imágenes están implicadas en las tres. Largest Contentful Paint mide cuánto tarda en dibujarse el elemento visible más grande: en un artículo es la imagen principal; en una ficha de producto, la fotografía protagonista. Cumulative Layout Shift mide el movimiento inesperado, y la causa clásica es una imagen sin dimensiones declaradas que empuja el texto hacia abajo al terminar de cargarse. Interaction to Next Paint mide la capacidad de respuesta y, aunque es sobre todo una historia de JavaScript, decodificar una pila de imágenes sobredimensionadas compite exactamente por el mismo hilo principal.

Qué premia realmente Google

Conviene ser preciso, porque este terreno atrae mucha exageración. La experiencia de página no es un factor de posicionamiento fuerte, y una página rápida no va a superar a otra más relevante. Lo que hace la velocidad es actuar como desempate entre resultados de relevancia comparable y — mucho más importante — determinar cuánta de la gente que hace clic se queda. Tres segundos de espera antes de que aparezca la imagen principal producen abandonos medibles, y el abandono es una señal que no necesita sutileza algorítmica para perjudicarte.

Datos de campo, no tu portátil

Los Core Web Vitals que usa la Búsqueda proceden del Chrome User Experience Report: mediciones reales de usuarios reales de Chrome. Lighthouse, ejecutándose en un laboratorio controlado en tu máquina, es una herramienta de diagnóstico, no la nota que cuenta. Un sitio puede sacar 98 en Lighthouse y suspender igualmente en campo porque los visitantes de verdad usan móviles Android de gama media en redes congestionadas. Optimiza para ese visitante y la puntuación de laboratorio llega sola.

Las cuatro palancas, por orden de rentabilidad

Casi todo el peso de las imágenes procede de cuatro decisiones. Aquí van en el orden que más kilobytes devuelve por minuto de esfuerzo, que no es el orden que usan la mayoría de guías.

1. Deja de servir píxeles que nadie ve

Esta es la grande, y casi siempre está presente. Una fotografía recién salida del móvil mide 4000 × 3000 píxeles. Mostrada en una columna de contenido de 800 píxeles de ancho, incluso contando con una pantalla retina de 2×, necesita 1600 píxeles de ancho. Los otros 2400 se descargan, se decodifican y se tiran: alrededor del 84 % de los datos de píxel desperdiciados antes siquiera de plantearse la compresión. Ningún formato ni ajuste de calidad se recupera de eso; redimensionar sí, y es el cambio más eficaz disponible.

2. Usa un formato moderno

WebP produce normalmente archivos entre un 25 y un 35 % más pequeños que un JPEG de calidad visual equivalente, y lo admiten todos los navegadores en uso. AVIF va más allá — a menudo entre un 40 y un 50 % más pequeño que JPEG — con un soporte ya amplio pero no universal, lo que lo convierte en una mejora progresiva más que en un sustituto total. Ninguno obliga a abandonar JPEG: servidos mediante un elemento picture, los navegadores modernos se llevan el archivo pequeño y los antiguos recurren al de reserva.

3. Ajusta la calidad por imagen, no por sitio

Los ajustes de calidad no son lineales en valor percibido. Para la mayoría de fotografías, una calidad JPEG de 75–82 o WebP de 75–80 es visualmente indistinguible del original al tamaño normal de visionado, mientras que la calidad 95 cuesta dos o tres veces más bytes por una diferencia que nadie ve. Las excepciones son las imágenes con grandes zonas planas, bordes duros o texto, que muestran artefactos mucho antes: capturas, logotipos y diagramas necesitan una calidad más alta o un formato sin pérdida.

4. Cárgalas en el orden correcto

Las ganancias que quedan son de planificación, no de tamaño. La imagen principal debe descubrirse y descargarse de inmediato; todo lo que esté por debajo del pliegue debe esperar. Hacerlo al revés — aplicar carga diferida a la imagen del LCP es un error genuinamente frecuente — puede costar un segundo de LCP en una página cuyas imágenes están por lo demás perfectamente optimizadas.

Formatos: la versión corta

• AVIF: los archivos más pequeños con contenido fotográfico, excelente a tasas bajas, más lento de codificar. Úsalo como primera fuente en un elemento picture.
• WebP: la opción por defecto sensata en 2026. Soporte universal, claramente más pequeño que JPEG, y admite transparencia y animación.
• JPEG: el formato de reserva que siempre funciona. Correcto para fotografías; nunca para capturas, logotipos ni nada con texto.
• PNG: sin pérdida, para color plano, bordes nítidos y transparencia. Correcto para logotipos y capturas de interfaz, derrochador para fotografías.
• SVG: vectorial, así que es independiente de la resolución y normalmente diminuto. La respuesta correcta para logotipos, iconos y diagramas sencillos; elimina los metadatos del editor antes de publicarlo, porque a menudo duplican el archivo.

El marcado que remata el trabajo

Unos archivos optimizados todavía tienen que pedirse bien. Cinco atributos hacen casi todo el trabajo, y ninguno exige un paso de compilación.

• Pon siempre width y height. El navegador reserva el espacio correcto antes de que llegue la imagen, lo que elimina el salto de maquetación. El CSS de aspect-ratio la mantiene adaptable; los atributos siguen siendo obligatorios.
• loading="lazy" en todo lo que esté por debajo del pliegue. Nativo, un atributo, sin librerías. Aplaza las peticiones de imágenes a las que el visitante quizá nunca llegue.
• Nunca difieras la carga de la imagen del LCP. Dale a la imagen principal fetchpriority="high" y asegúrate de que está en el HTML inicial y no la inyecta un script.
• Usa srcset y sizes para imágenes adaptables. Un móvil no debería descargar el archivo pensado para escritorio. Con tres o cuatro anchos se cubre casi cualquier maquetación.
• Escribe un alt de verdad. Es primero un requisito de accesibilidad y después una señal SEO: describe lo que la imagen comunica, no una lista de palabras clave. Las imágenes decorativas llevan un alt vacío para que los lectores de pantalla las ignoren.

Los nombres de archivo y el contexto también cuentan

Para la búsqueda de imágenes, el nombre del archivo, el texto alternativo, el pie y el párrafo que la rodea son lo que identifica a la imagen. «mesa-comedor-roble-140cm.webp» le dice algo a un rastreador; «IMG_20260714_113255.webp» no le dice nada. Esto no cuesta bytes ni tiempo, y es la parte del SEO de imágenes que más se omite por completo.

Presupuestos que merece la pena adoptar

• Imagen principal / LCP: menos de 200 KB. Es la que decide tu LCP. Trata la cifra como un límite duro.
• Imágenes dentro del artículo: menos de 100 KB cada una. Con 1200–1600 píxeles de ancho en WebP es perfectamente alcanzable para la mayoría de fotografías.
• Miniaturas y avatares: menos de 30 KB. Si una miniatura de 150 píxeles pesa 400 KB, es una imagen a tamaño completo que está escalando el navegador.
• Todas las imágenes de una página: menos de 1 MB en total. Por encima de eso, los visitantes móviles con conexión lenta empiezan a abandonar antes de que la página sea usable.

Medir el cambio

1. 1 Registra el punto de partida: PageSpeed Insights para la URL, anotando tanto la puntuación de laboratorio como los datos de campo si la página tiene tráfico suficiente para tenerlos.
2. 2 Abre las herramientas de desarrollo, filtra el panel de red por imágenes y ordena por tamaño. Los tres archivos más grandes son tu lista de trabajo.
3. 3 Arregla esos tres: redimensiona a las dimensiones de visualización, convierte a WebP, comprime y revisa el resultado a tamaño completo.
4. 4 Vuelve a medir en laboratorio de inmediato y espera 28 días para que los datos de campo reflejen el cambio: CrUX informa sobre una ventana móvil de 28 días, así que nada se mueve de un día para otro.
5. 5 Añade los presupuestos anteriores a tu lista de publicación, para que la mejora no se degrade con la siguiente tanda de subidas.

Por qué encaja aquí un flujo de trabajo en el navegador

La optimización de imágenes es un trabajo repetitivo y por lotes que no necesita servidor: redimensionar y recodificar es exactamente para lo que están la Canvas API y los Web Workers. Hacerlo en local significa no esperar a subir una carpeta de cincuenta fotografías, sin colas, sin límite de tamaño y sin copias de imágenes de producto sin publicar en el almacenamiento temporal de un tercero. También significa que puedes ejecutar todo el proceso en un tren sin cobertura, lo que resulta útil más a menudo de lo que parece.