Optimización de imágenes

TL;DR — La optimización de imágenes consiste en hacer que tus imágenes sean más pequeñas para que las páginas carguen rápido, sin que se vean mal. Usa un formato moderno como WebP, comprime el archivo y no sirvas una imagen mucho más grande de lo que se muestra en pantalla. La regla que más se incumple: la imagen grande en la parte superior de tu página debe cargar de inmediato — nunca apliques “carga diferida” a esa. Hacerlo bien no aumenta mágicamente tu posicionamiento ni garantiza una puntuación de velocidad aprobatoria — solo hace que tus páginas sean rápidas, y la velocidad es lo que cuenta, así que verifica tus resultados reales antes y después.

Qué hace realmente la optimización de imágenes

Las imágenes son casi siempre lo más pesado de una página web. Los propios documentos de Google dicen que las imágenes son “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traducción) «a menudo el mayor contribuyente al tamaño total de la página, lo que puede hacer que las páginas sean lentas y costosas de cargar». Así que optimizarlas se trata realmente de una cosa: reducir los bytes que tu visitante tiene que descargar, para que tu página se muestre rápidamente.

Lo que sorprende a la gente: el formato en sí no es una mejora de posicionamiento. Cambiar tus JPEG a WebP no elevará tus posiciones por sí solo. Lo que hace es reducir los archivos, lo que acelera la página, y la velocidad es lo que ayuda. Este artículo complementa el centro más amplio de SEO de imágenes: aquel cubre el texto alternativo, los nombres de archivo y la búsqueda de imágenes; este es la guía práctica para acelerar la carga.

Las pocas cosas que importan

• Usa un formato moderno. WebP y AVIF hacen que los archivos sean mucho más pequeños que los JPEG y PNG antiguos sin que se vean peor. WebP es el estándar seguro hoy en día.
• Compresión. Incluso un WebP puede ser demasiado grande. Pasa las imágenes por un compresor y encuentra el punto donde el archivo es pequeño pero sigue viéndose bien.
• No sirvas una imagen gigante en un espacio pequeño. Si una imagen solo se muestra a 500 píxeles de ancho, no necesitas un archivo de 3 000 píxeles — eso es descarga desperdiciada.
• Carga diferida para imágenes más abajo en la página. Añadir loading="lazy" le dice al navegador que espere hasta que te desplaces cerca de una imagen antes de cargarla. Ideal para imágenes debajo del pliegue.
• Nunca apliques carga diferida a la imagen grande superior. La imagen más grande que la gente ve cuando la página carga por primera vez es contra la que Google mide tu velocidad. Esa debería cargar de inmediato.

Lo que la mayoría de la gente entiende mal

Aplican carga diferida a todo — incluida la imagen principal en la parte superior. Suena inteligente (“¡carga menos cosas!”) pero es al revés: la imagen superior es contra la que se mide tu puntuación de velocidad de página, así que retrasarla empeora tu puntuación. Cárgala de forma inmediata y dile al navegador que es importante. Explico exactamente cómo en la pestaña Avanzado.

¿Quieres la versión precisa — las citas exactas de Google, las ventajas y desventajas de WebP frente a AVIF, los cálculos de tamaño y el truco de fetchpriority? Cambia a la pestaña Avanzado.

TL;DR — La optimización de imágenes es una disciplina de velocidad de página / Core Web Vitals, no un factor directo de posicionamiento. La elección del formato (WebP, AVIF) reduce bytes pero no aporta ningún beneficio SEO — Mueller lo ha dicho de tres maneras distintas; también hay que sopesar la transparencia, la animación, y el soporte actual del navegador, no solo la tasa de compresión. La regla más valiosa: nunca apliques carga diferida a tu imagen LCP (normalmente la imagen principal); eso retrasa la misma métrica que estás optimizando. Dale loading="eager" + fetchpriority="high", aunque las sugerencias de prioridad solo ayudan con un cuello de botella de descubrimiento o tiempo de descarga, no con todos los problemas de LCP. El loading="lazy" nativo es para imágenes fuera del área visible inicial, no para una línea fija «debajo del pliegue». La compresión no tiene una calidad universal correcta: prueba por tipo de imagen. Las dimensiones correctas = tamaño del contenedor renderizado × relación de píxeles del dispositivo, y ese tamaño de contenedor cambia con el diseño responsivo, así que entrega un rango srcset/sizes (un valor sizes incorrecto descarga silenciosamente una imagen sobredimensionada) con un respaldo <picture>. Las imágenes son el elemento LCP más común en la web, por eso este artículo también pertenece a Rendimiento web; pero nada de esto garantiza una puntuación aprobatoria en Core Web Vitals, un cambio de posicionamiento o más tráfico; mide antes y después.

Para qué optimiza la optimización de imágenes (desmonta el mito desde el principio)

Déjame matar el mito más grande antes que nada: el formato de imagen es una palanca de velocidad, no una palanca de posicionamiento. Convertir a WebP o AVIF no mejora directamente el posicionamiento. Te da archivos más pequeños, que te dan una página más rápida, que alimenta Core Web Vitals — y esa es la parte que usan los sistemas de búsqueda. La cadena es real pero indirecta, y colapsarla en “los formatos de nueva generación rankean mejor” es donde la mayoría de las guías de la competencia fallan.

Los documentos de Google son contundentes sobre por qué las imágenes importan para la velocidad: son “often the largest contributor to overall page size, which can make pages slow and expensive to load,” (traducción) «a menudo el mayor contribuyente al tamaño total de la página, lo que puede hacer que las páginas sean lentas y costosas de cargar», y el consejo es “apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience” (traducción) «aplicar las últimas técnicas de optimización de imágenes y de imágenes responsive para proporcionar una experiencia de usuario rápida y de alta calidad» (Google Search Central — Images). Nota el encuadre: experiencia de usuario rápida, no una recompensa de posicionamiento por el formato de archivo.

Para el qué/por qué del SEO de imágenes en general — texto alternativo, nombres de archivo, sitemaps de imágenes, datos estructurados y posicionamiento en la búsqueda de imágenes: eso corresponde al centro principal de SEO de imágenes. Este artículo es el cómo canónico: formatos, compresión, dimensiones y estrategia de carga.

Empieza con la regla que todos rompen: nunca apliques carga diferida a tu imagen LCP

Si te llevas una cosa de esta página, que sea esta. El elemento Largest Contentful Paint (LCP) — la cosa más grande pintada en el viewport al cargar — es “either an image or a web font,” (traducción) «o una imagen o una fuente web», según web.dev (Optimize LCP), y en la mayoría de las páginas es una imagen: la principal, la destacada o la foto del producto. web.dev pone la regla tan contundentemente como Google suele expresar cualquier cosa:

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traducción) «Nunca apliques carga diferida a tu imagen LCP, porque siempre provocará una demora innecesaria en la carga del recurso y perjudicará el LCP».

Este es el matiz que la mayoría de los consejos de “solo usa lazy loading” pasan por alto por completo. El lazy-loading es genial — para imágenes debajo del pliegue. Aplícalo a la imagen LCP y retrasas activamente la única métrica que intentas mejorar. La guía de lazy-loading de web.dev dice lo mismo desde la otra dirección: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (traducción) «No cargues con lazy-load imágenes que probablemente estén en el viewport cuando la página cargue, especialmente imágenes LCP» (Browser-level lazy loading).

He argumentado lo mismo en mi artículo sobre LCP en Ahrefs: el elemento más grande “suele ser una imagen destacada o quizás la etiqueta <h1>”, y las soluciones se derivan de eso. “Si no necesitas la imagen, la solución más impactante es simplemente deshacerte de ella. Si debes tener la imagen, sugiero optimizar el tamaño y la calidad para mantenerla lo más pequeña posible.” Deberías “cargar de forma diferida cualquier imagen que no necesites de inmediato” — pero la otra cara es una regla estricta que puse en mayúsculas por una razón: “¡No cargues de forma diferida las imágenes que están en la parte superior de la página!”

fetchpriority="high" en la imagen LCP

No cargar de forma diferida la imagen principal es necesario pero no suficiente. Para asegurarte de que la imagen LCP se cargue lo antes posible, indica su prioridad al navegador. De web.dev:

“Puedes indicar al navegador qué recursos son los más importantes usando el atributo fetchpriority… Es una buena idea establecer fetchpriority=\"high\" en un elemento <img> si crees que es probable que sea el elemento LCP de tu página.”

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

En mi artículo sobre LCP describo fetchpriority="high" de la misma manera — “se puede usar en las etiquetas <img> o <link> y le dice a los navegadores que obtengan la imagen temprano” — y lo combino con Early Hints (una respuesta 103) como una forma complementaria de comenzar la descarga antes de que llegue el HTML principal. Así que la receta para LCP es: carga inmediata + fetchpriority="high" (+ Early Hints si tu infraestructura los soporta). Todo lo demás en la página puede cargarse de forma diferida.

Trata fetchpriority y la precarga como herramientas específicas para cuellos de botella, no como una solución garantizada. Ayudan cuando la imagen LCP se descubre o se descarga tarde; no hacen nada por una respuesta lenta del servidor, un recurso que bloquea el renderizado antes de la imagen, o un archivo genuinamente demasiado grande. Confirma cuál es el cuello de botella que realmente tienes (PageSpeed Insights o Lighthouse desglosan LCP en sus subpartes) antes de asumir que una pista de prioridad por sí sola moverá el número.

loading="lazy" nativo — gratis, simple y correcto debajo del pliegue

Para cada imagen que no esté en el viewport inicial, la carga diferida nativa es la victoria más fácil en rendimiento. web.dev: “Puedes usar el atributo loading para cargar imágenes de forma diferida sin necesidad de escribir código personalizado de carga diferida o usar una biblioteca de JavaScript separada.”

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

Dos cosas mantienen esto seguro:

• Básalo en el viewport inicial, no en una línea fija de “debajo del pliegue”. “El pliegue” no es un número fijo de píxeles — se desplaza con el tamaño del viewport y el diseño. La prueba real es si la imagen es probable que sea visible cuando la página se pinta por primera vez. Cualquier cosa que lo sea — y especialmente la imagen LCP — recibe loading="eager" (el valor predeterminado), nunca lazy.
• Prefiere el atributo nativo sobre los trucos de JavaScript. Los cargadores diferidos de JavaScript que ocultan la URL real en data-src y nunca exponen un src corren el riesgo de no ser indexados en absoluto. El loading="lazy" nativo (o un IntersectionObserver limpio) mantiene el src visible para los rastreadores. El hub principal de SEO de imágenes cubre esa advertencia de indexación en detalle.

Formatos modernos: WebP vs. AVIF vs. JPEG/PNG

Los formatos son donde más importa desmentir mitos, así que seamos precisos sobre lo que cada uno te dá — que son bytes, no rankings.

• WebP — “a menudo tiene mejor compresión que JPEG, PNG o GIF, ofreciendo tanto compresión con pérdida como sin pérdida” (web.dev — Rendimiento de imágenes). Aproximadamente 25–35 % más pequeño que JPEG con soporte casi universal en navegadores. El valor predeterminado seguro para fotos hoy en día.
• AVIF — “soporta tanto compresión con pérdida como sin pérdida, y las pruebas han mostrado un ahorro de más del 50 % en comparación con JPEG en algunos casos.” Compresión de primera clase, soporte ligeramente menos universal, así que combínalo con un respaldo WebP o JPEG.
• JPEG — el respaldo universal para fotografías.
• PNG — cuando necesitas transparencia o gráficos con bordes nítidos.
• SVG — logotipos e iconos: vectorial, escala infinitamente, diminuto.

El formato que elijas también depende de lo que la imagen necesita hacer, no solo de cuál comprime más: la transparencia, la animación y la consistencia con la que un navegador o herramienta admite esa combinación específica influyen en la elección junto con el ahorro de tamaño bruto anterior: comprueba la compatibilidad actual de la función exacta que necesitas, especialmente para cualquier cosa animada, antes de comprometerte con un formato como defecto.

Google Search admite “BMP, GIF, JPEG, PNG, WebP, SVG y AVIF” referenciados en un src de <img>. Sirve el formato moderno con una alternativa elegante usando <picture>:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

El <img src> al final es tu red de seguridad: los navegadores y rastreadores más antiguos recurren a él, y es la URL que Google realmente indexa.

¿El formato afecta al ranking? (No, y Mueller lo ha dicho de tres maneras)

Este es el único hilo de desmentidos que vale la pena seguir en todo el tema. Tres declaraciones separadas e independientes en el tiempo de John Mueller llegan a la misma conclusión: el formato afecta a la mecánica de rastreo/indexación y al peso de la página, nunca directamente al ranking:

1. AVIF no da un impulso SEO. Después de que Google añadiera soporte nativo para AVIF, Mueller confirmó que no hay “impulso SEO” por usar AVIF sobre otros formatos admitidos (cobertura de SE Roundtable).
2. WebP está “bien”. “WebP images are fine for Image Search” (traducción) «Las imágenes WebP están bien para la Búsqueda de Imágenes» — “bien”, notablemente, no “mejor” (cobertura de SE Roundtable).
3. Las peculiaridades de indexación de WebP no son específicas del formato. Cuando la gente vio archivos WebP mostrados como “Rastreado – actualmente no indexado” en GSC, el punto de Mueller era que los archivos de imagen no se indexan como páginas HTML, y no creía que el fenómeno se limitara a WebP en absoluto (cobertura de SEJ).

Compresión y calidad: no hay un ajuste “correcto” universal

El consejo malo más común en las guías de imágenes es una sola viñeta de “comprimir al 80%”. web.dev es claro en que no existe tal número mágico:

“When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (traducción) «Al comprimir no hay un ajuste universal adecuado para todos los casos. Lo recomendable es probar distintos niveles de compresión hasta encontrar un buen equilibrio entre calidad de imagen y tamaño de archivo».

En la práctica: prueba por tipo de imagen. Las fotografías toleran bien la compresión con pérdida agresiva; los gráficos, logotipos y capturas de pantalla con texto muestran artefactos rápidamente y a menudo quieren sin pérdida o un ajuste de calidad más alto. En lugar de confiar en un solo control deslizante, exporta la misma imagen a dos o tres niveles de calidad y míralos a tamaño de visualización: el más pequeño que no puedas distinguir visualmente del original es tu respuesta. Eso es un flujo de trabajo real, no “pásalo por TinyPNG y espera”.

Dimensiones correctas: tamaño del contenedor × relación de píxeles del dispositivo

“Solo hazlo más pequeño” no es la regla: coincidir con el tamaño renderizado × la relación de píxeles del dispositivo (DPR) lo es. De web.dev:

“An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (traducción) «Una imagen mostrada en un contenedor de 500 píxeles por 500 píxeles tendría un tamaño óptimo de 500 píxeles por 500 píxeles.»

“If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (traducción) «Si el dispositivo tiene un DPR de 2 y la imagen se muestra en un contenedor de 500 por 500 píxeles, entonces una imagen cuadrada de 1000 píxeles es el tamaño óptimo».

Así que un contenedor de 500×500 en una pantalla de 2× (clase Retina) quiere una fuente de 1 000×1 000. Ve más grande que eso y desperdicias bytes sin ganancia perceptible; ve más pequeño y se ve suave en pantallas de alto DPR. Por eso sirves una gama de tamaños y dejas que el navegador elija, usando srcset + sizes:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

El navegador lee el ancho del contenedor (sizes) y su propio DPR, y luego elige el candidato correcto de srcset — la versión de entrega responsiva de las matemáticas de DPR anteriores. Google recomienda <picture> o srcset para imágenes responsivas y dice que hay que “always specify a fallback URL using the src attribute.” (traducción) «especificar siempre una URL de respaldo mediante el atributo src».

Si te equivocas con sizes, nada te lo advierte. Si el valor que declaras no coincide con el ancho real al que se renderiza la imagen — un error común después de un cambio de diseño o CSS — el navegador no tiene forma de saberlo y simplemente elige un candidato basándose en el número inexacto que le diste, lo que normalmente significa que descarga un archivo más grande de lo que el diseño necesita. Eso deshace silenciosamente el trabajo de formato y compresión anterior. La única forma fiable de detectarlo: abre el panel de Red de DevTools, busca la solicitud de la imagen y compara las dimensiones del archivo entregado con el ancho real renderizado del contenedor.

Ese ejemplo de 500×500 anterior es ilustrativo, no un número para todo el sitio que debas codificar de forma fija — la misma imagen principal puede renderizarse a un ancho diferente en móvil que en escritorio, por lo que el “tamaño del contenedor” se mueve con tu diseño responsivo en lugar de permanecer fijo. Es exactamente por eso que entregas un rango de srcset en lugar de exportar un tamaño “óptimo” y dar por terminado el trabajo.

Por qué todo esto se relaciona con Core Web Vitals

El hilo conductor que conecta cada técnica anterior es LCP. Las imágenes son el elemento LCP más común en la web, y LCP es una de las tres Core Web Vitals. El objetivo de Google: “LCP should occur within 2.5 seconds” (traducción) «LCP debería ocurrir dentro de 2,5 segundos» en el percentil 75 de las cargas de página en móvil y escritorio (web.dev — Vitals). Core Web Vitals “apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traducción) «se aplican a todas las páginas web, deberían ser medidas por todos los propietarios de sitios y se mostrarán en todas las herramientas de Google».

Así que la optimización de imágenes no es un factor de clasificación discreto — es un contribuyente a una señal de experiencia de página (Core Web Vitals) que los sistemas de clasificación sí utilizan. Esa distinción es el marco preciso, y es por eso que este artículo vive tanto en el clúster de SEO de Imágenes como en el clúster de Rendimiento Web. Para profundizar en la métrica en sí, consulta Core Web Vitals y LCP en Rendimiento Web.

Una advertencia más que vale la pena expresar claramente: ninguna de las correcciones en esta página garantiza nada. Los bytes de imagen son solo un componente posible de LCP — el propio desglose de web.dev de las subpartes de LCP incluye cosas como el tiempo de respuesta del servidor y los recursos que bloquean el renderizado antes de la imagen, ninguno de los cuales el formato o la compresión tocan — y las dimensiones de la imagen son solo una entrada en CLS, no una garantía de una puntuación particular. Reducir una imagen principal puede ayudar de forma medible, no hacer nada, o (si otra cosa es el verdadero cuello de botella) apenas mover el número. Optimizar imágenes tampoco garantiza por sí mismo una evaluación aprobatoria de Core Web Vitals, un cambio en la clasificación, más tráfico, más conversiones o una cita en la búsqueda con IA — esos dependen de mucho más que los bytes de imagen. Trata cada corrección de imagen como una hipótesis, no como un hecho consumado: mide LCP y CLS antes y después, en el laboratorio y en el campo, y deja que esos datos — no la suposición de que la optimización “funcionó” — te digan si movió algo.

Errores comunes de implementación

• Las imágenes de fondo CSS no se indexan. A veces los desarrolladores cambian un <img> por una background-image por conveniencia de diseño. Google “puede encontrar imágenes en el atributo src del elemento <img> (incluso cuando es hijo de otros elementos, como el elemento <picture>)” pero “no indexa imágenes CSS.” Si quieres que la imagen aparezca en la búsqueda de imágenes, mantenla en un <img>. (Esto está relacionado con el rendimiento, pero el error es lo bastante común como para señalarlo.)
• No renombres en masa archivos existentes para un “refresco” de rendimiento/SEO. Mueller ha dicho que los sistemas de Google tardan “mucho tiempo” en reprocesar imágenes renombradas y el efecto es mínimo si tu contexto ya es bueno: el hub principal de SEO de imágenes lo cubre en detalle.
• Faltan width/height. Siempre establece width y height intrínsecos (o aspect-ratio en CSS) para que el navegador pueda reservar espacio antes de que la imagen se cargue; esto reduce el desplazamiento de diseño causado por imágenes, pero es solo una entrada entre varias en el CLS, no una garantía de una puntuación concreta.

Receta rápida

• Imagen hero / LCP: formato moderno, tamaño correcto, loading="eager", fetchpriority="high".
• Todo lo que esté por debajo del pliegue: loading="lazy".
• Sirve WebP/AVIF con un respaldo src en <picture>.
• Ajusta el tamaño al contenedor × DPR; entrega un rango de srcset con sizes.
• Comprime según el tipo de imagen: prueba 2–3 niveles de calidad, no confíes en un solo control deslizante.
• Siempre establece width/height.

Para el resto del SEO de imágenes — texto alternativo, nombres de archivo, sitemaps de imágenes, datos estructurados y clasificación en la búsqueda de imágenes — vuelve al hub de SEO de imágenes.

Resumen de IA

Una versión condensada de la versión avanzada:

• La optimización de imágenes = velocidad, no una palanca de clasificación. La elección del formato (WebP/AVIF) reduce los bytes → página más rápida → mejores Core Web Vitals. No hay un impulso directo de clasificación por el formato en sí: Mueller lo confirmó de tres maneras distintas (AVIF “sin impulso SEO,” WebP “bien,” las peculiaridades de indexación de WebP no son específicas del formato).
• La regla número 1: nunca cargues de forma diferida tu imagen LCP. La imagen que probablemente sea visible cuando la página se pinta por primera vez (normalmente la hero) marca tu LCP; cargarla de forma diferida retrasa exactamente la métrica que estás corrigiendo. Dale loading="eager" + fetchpriority="high" (opcionalmente Early Hints) — aunque las sugerencias de prioridad solo solucionan un cuello de botella de descubrimiento/tiempo de fetch, no todos los problemas de LCP (revisa las subpartes del LCP antes de asumir que una sugerencia por sí sola ayudará).
• El loading="lazy" nativo es gratuito y correcto — para imágenes fuera del viewport inicial, no una línea de píxeles fija “por debajo del pliegue”. Evita los cargadores diferidos en JS que ocultan la URL en data-src.
• Formatos: WebP es el valor predeterminado seguro (~25–35 % más pequeño que JPEG); AVIF comprime más (50 %+ en algunas pruebas) con un respaldo. La elección también depende de la transparencia, la animación y la compatibilidad actual del navegador/herramienta, no solo de la relación de compresión. Sirve mediante <picture> con un respaldo <img src> que Google indexe.
• Compresión: no hay una calidad “correcta” universal: prueba según el tipo de imagen (las fotos comprimen mucho; el texto/gráficos se degradan rápido).
• Tamaño: el tamaño correcto = tamaño del contenedor renderizado × relación de píxeles del dispositivo (contenedor de quinientos píxeles a 2× DPR = fuente de 1 000 px) — y ese tamaño de contenedor a su vez cambia con el diseño responsivo, así que entrega un rango mediante srcset + sizes en lugar de una exportación fija. Un valor incorrecto de sizes hace que el navegador descargue silenciosamente un candidato sobredimensionado.
• Por qué importa: las imágenes son el elemento LCP más común; el objetivo de LCP es 2,5 s en el percentil 75. Por eso esto se cruza con Web Performance — pero el LCP tiene otras subpartes (tiempo de respuesta del servidor, recursos que bloquean el renderizado) que los bytes de imagen por sí solos no solucionan.
• Sin garantías: optimizar imágenes no garantiza por sí mismo una puntuación aprobatoria en Core Web Vitals, un cambio de clasificación, más tráfico, más conversiones o una cita en la búsqueda de IA. Mide LCP/CLS antes y después, en el laboratorio y en el campo.
• Errores comunes: background-image en CSS no se indexa; no renombres archivos en masa; siempre establece width/height — puede reducir el desplazamiento de diseño pero no garantiza una puntuación CLS concreta.

Documentación oficial

Documentación de fuentes primarias de los motores de búsqueda y del equipo de Chrome.

Google / web.dev

• Rendimiento de imágenes (web.dev “Aprende rendimiento”) — formatos, el punto de “no hay un ajuste universal de compresión” y las matemáticas de dimensionado DPR.
• Carga diferida de imágenes a nivel de navegador (web.dev) — cómo funciona el loading="lazy" nativo y la excepción de “no cargar diferidamente imágenes en el viewport / imágenes LCP”.
• Optimiza LCP (web.dev) — fetchpriority, el recurso LCP es una imagen o fuente, y “nunca cargues diferidamente tu imagen LCP”.
• API de Fetch Priority (web.dev) — el explicador completo de fetchpriority="high" para imágenes LCP.
• Web Vitals (web.dev) — definiciones de Core Web Vitals y el umbral de LCP ≤ 2,5 s / percentil 75.
• Prácticas recomendadas de Google Images — formatos compatibles, indexación de <img>/<picture> (no fondos CSS), imágenes responsivas y la recomendación de src de respaldo.

Bing / Microsoft

• Bing no publica una guía técnica específica de optimización de imágenes tan detallada como la de Google; la orientación relevante se encuentra dentro de las Directrices generales para webmasters de Bing, que tratan la velocidad de página (incluido el peso de las imágenes) como una consideración. Lo señalo honestamente en lugar de inventar una “cita” de Bing que no existe.
• Búsqueda visual de Bing — búsqueda visual a nivel de objeto; relevante para el descubrimiento de imágenes, separada de los efectos de velocidad de página del formato/compresión.

Citas de la fuente

Declaraciones oficiales del equipo de Chrome de Google y de los defensores de búsqueda. Cuando una página expone el texto, el enlace es un enlace profundo que salta al pasaje citado.

web.dev (equipo de Chrome de Google) — las reglas de LCP

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traducción) «Nunca cargues diferidamente tu imagen LCP, ya que eso siempre provocará un retraso innecesario en la carga del recurso y tendrá un impacto negativo en el LCP.» Ir a la cita
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (traducción) «No cargues diferidamente imágenes que probablemente estén en el viewport cuando la página se cargue, especialmente imágenes LCP.» Ir a la cita
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (traducción) «Es una buena idea establecer fetchpriority=\"high\" en un elemento <img> si crees que es probable que sea el elemento LCP de tu página.» — web.dev, Optimiza LCP.

web.dev (equipo de Chrome de Google) — formatos, compresión, dimensionado

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (traducción) «WebP a menudo tiene mejor compresión que JPEG, PNG o GIF, ofreciendo compresión tanto con pérdida como sin pérdida.» Ir a la cita
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (traducción) «AVIF admite compresión tanto con pérdida como sin pérdida, y las pruebas han mostrado ahorros superiores al 50 % en comparación con JPEG en algunos casos.» — web.dev, Rendimiento de imágenes.
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (traducción) «Al comprimir, no hay un ajuste universal adecuado para todos los casos. El enfoque recomendado sería experimentar con diferentes niveles de compresión hasta encontrar un buen compromiso entre calidad de imagen y tamaño de archivo.» — web.dev, Rendimiento de imágenes.
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” (traducción) «Una imagen mostrada en un contenedor de 500 píxeles por 500 píxeles tendría un tamaño óptimo de 500 píxeles por 500 píxeles.» … «Si el dispositivo tiene un DPR de 2 … entonces una imagen cuadrada de 1000 píxeles … es ahora el tamaño óptimo.» — web.dev, Rendimiento de imágenes.

Google Search Central — por qué las imágenes importan para la velocidad

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traducción) «las imágenes suelen ser el mayor contribuyente al tamaño total de la página, lo que puede hacer que las páginas sean lentas y costosas de cargar». Ir a la cita

web.dev — Métricas web principales

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traducción) «Core Web Vitals son el subconjunto de Web Vitals que se aplican a todas las páginas web, deberían ser medidos por todos los propietarios de sitios y se mostrarán en todas las herramientas de Google». Ir a la cita

John Mueller, Google — el formato no es una palanca de clasificación

• Sobre AVIF: no hay “impulso SEO” por usar archivos AVIF. Cobertura
• Sobre WebP: “WebP images are fine for Image Search.” (traducción) «Las imágenes WebP están bien para la Búsqueda de imágenes». Cobertura

Lista de verificación de optimización de imágenes

Ejecuta esta pasada en cualquier página sensible al rendimiento:

• Identificada la imagen LCP (normalmente la imagen principal / destacada / la primera foto del producto).
• La imagen LCP no se carga de forma diferida — usa loading="eager" (el valor predeterminado).
• La imagen LCP tiene fetchpriority="high" (considera Early Hints si tu stack lo soporta).
• Cada imagen debajo del pliegue tiene loading="lazy".
• Se sirve un formato moderno (WebP por defecto, AVIF donde se soporte) con un respaldo src en <picture>.
• Cada imagen está dimensionada a su contenedor × la relación de píxeles del dispositivo — sin archivos de 3 000 px en espacios de quinientos píxeles.
• Entrega responsiva mediante srcset + sizes donde las imágenes se renderizan a diferentes anchos.
• Compresión probada por tipo de imagen (2–3 niveles de calidad comparados al tamaño de visualización), no un ajuste único.
• width y height intrínsecos (o aspect-ratio en CSS) establecidos en cada imagen para reducir el cambio de diseño (CLS) — no es una garantía de una puntuación específica.
• Ninguna imagen de contenido vive solo en un background-image de CSS (esas no se indexan).
• La carga diferida usa el atributo nativo (o un IntersectionObserver limpio), no un truco de JS que oculta la URL en data-src.
• LCP verificado en el campo (CrUX / PageSpeed Insights), apuntando a ≤ 2,5 s en el percentil 75.

Hoja de referencia de optimización de imágenes

Las palancas — qué hace cada una y la mejor práctica

Datos rápidos

• El formato es una palanca de velocidad, no de ranking — Mueller: no hay “impulso SEO” con AVIF; WebP “está bien”.
• WebP ≈ 25–35 % más pequeño que JPEG; AVIF a menudo más de 50 % más pequeño en pruebas.
• La regla de mayor valor: nunca cargues de forma diferida tu imagen LCP.
• Objetivo de LCP: ≤ 2,5 s en el percentil 75 (móvil y escritorio).
• Formatos compatibles: BMP, GIF, JPEG, PNG, WebP, SVG, AVIF.
• El tamaño correcto = tamaño del contenedor renderizado × relación de píxeles del dispositivo.

El error que te cuesta tu puntuación de LCP

Cargar de forma diferida la imagen principal es el error más costoso cubierto en este artículo, y es el que merece destacarse por sí solo antes del resto.

• Incorrecto: aplicar loading="lazy" (o un cargador diferido en JS) a la imagen más grande visible sin desplazamiento — normalmente la principal, la destacada o la primera foto de producto. Por qué es incorrecto: esa imagen casi siempre es tu elemento LCP, y web.dev es explícito al decir que cargarla de forma diferida “will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traducción) «siempre provocará un retraso innecesario en la carga de recursos y tendrá un impacto negativo en el LCP». Terminas retrasando la métrica exacta que intentabas mejorar. En su lugar: dale a la imagen LCP loading="eager" (el valor predeterminado) además de fetchpriority="high", y reserva loading="lazy" para todo lo que esté debajo del pliegue.

Confiar en un único ajuste de compresión genérico

• Incorrecto: pasar cada imagen por el mismo ajuste predefinido de “comprimir al 80 %” sin importar el contenido. Por qué es incorrecto: web.dev dice claramente que “there isn’t a universal setting suitable for all cases” (traducción) «no existe un ajuste universal adecuado para todos los casos» — un ajuste predefinido para fotografías comprimirá en exceso logotipos, capturas de pantalla y gráficos con mucho texto, creando artefactos visibles. En su lugar: exporta la misma imagen en dos o tres niveles de calidad y compáralos al tamaño de visualización real; elige el más pequeño que no puedas distinguir del original, según el tipo de imagen.

Dimensionar las imágenes según el archivo que tienes, no el contenedor

• Incorrecto: servir la resolución que tenga el archivo original (o un único tamaño fijo para cada diseño), en lugar de ajustar la imagen a donde realmente se renderiza. Por qué es incorrecto: según los propios cálculos de web.dev, el tamaño correcto es el tamaño del contenedor renderizado × la relación de píxeles del dispositivo — un contenedor de 500×500 a 2× DPR necesita una fuente de 1 000×1 000, no 500×500 ni 3 000×3 000. Si vas más grande, desperdicias bytes sin ganancia visible; si vas más pequeño, se ve borroso en pantallas de alta DPR. En su lugar: entrega un rango de srcset con sizes para que el navegador pueda elegir el candidato correcto para el contenedor y el dispositivo.

Ocultar imágenes de contenido real detrás de CSS

• Incorrecto: cambiar un <img> por un background-image por conveniencia de diseño. Por qué es incorrecto: Google “doesn’t index CSS images” (traducción) «no indexa imágenes CSS» — una imagen de contenido que solo existe como background-image es invisible para la búsqueda de imágenes incluso si está completamente optimizada por lo demás. En su lugar: mantén las imágenes de contenido en un <img> (o como el respaldo <img> dentro de un <picture>), y reserva los fondos CSS para tratamientos puramente decorativos.

Omitir width/height para “ahorrar marcado”

• Incorrecto: dejar fuera los atributos intrínsecos width y height (o un aspect-ratio en CSS) de las etiquetas <img>. Por qué es incorrecto: el navegador no puede reservar espacio de diseño antes de que la imagen se cargue, así que la página salta a medida que llega cada imagen — perjudicando el CLS, la Core Web Vital que acompaña al LCP. En su lugar: establece siempre width/height (o aspect-ratio) en cada imagen, incluso en las que también estés optimizando en formato y tamaño.

Los modelos mentales

1. Nunca cargues de forma diferida tu imagen LCP. La regla de mayor valor en todo el tema. El elemento más grande visible sin desplazamiento — normalmente una imagen — es contra el que se mide tu LCP. Cargarlo de forma diferida no ahorra nada; solo retrasa la métrica que estás optimizando. Todo lo demás en la página es candidato para loading="lazy"; la imagen LCP nunca lo es.

2. No existe un ajuste de compresión universal. Trata “¿a qué calidad debo comprimir?” como una pregunta por imagen, no como una política para todo el sitio. Las fotografías toleran una compresión con pérdida agresiva; los gráficos con mucho texto y las capturas de pantalla no. El flujo de trabajo es comparativo: exporta a dos o tres niveles de calidad y revísalos visualmente al tamaño de visualización, no un único control deslizante que configuras una vez y olvidas.

3. El tamaño correcto = tamaño del contenedor × relación de píxeles del dispositivo. “Más pequeño es mejor” no es la regla; coincidir lo es. Las dimensiones óptimas del origen son el tamaño al que la imagen realmente se renderiza, multiplicado por la relación de píxeles del dispositivo: un contenedor de 500×500 a 2× DPR quiere un origen de 1 000×1 000. Esta es la única fórmula que debería decidir el tamaño de exportación de cada imagen, y es por eso que entregas un rango mediante srcset en lugar de un único archivo fijo.

4. El formato es una palanca de velocidad, no una palanca de posicionamiento. Desglosa correctamente esta cadena: elección del formato → archivos más pequeños → página más rápida → mejores Core Web Vitals → una señal que los sistemas de posicionamiento sí utilizan. Saltar directamente a “los formatos de nueva generación posicionan mejor” es la forma más común en que las guías de la competencia se equivocan en este tema: Mueller ha dicho que no hay un beneficio SEO directo por el formato en sí, en tres ocasiones distintas.

Los KPI permanentes para la velocidad de página impulsada por imágenes

Estos son los números continuos que te indican si tu trabajo de optimización de imágenes realmente está dando resultados, independientemente de cualquier imagen individual que redimensiones o conviertas esta semana.

Ponte a prueba: Optimización de imágenes

Cinco preguntas rápidas sobre formatos, compresión, dimensiones y estrategia de carga. Elige una respuesta para cada una y luego comprueba.

Registro de cambios