Optimizar imágenes para la velocidad web y los Core Web Vitals
Las imágenes son la causa más común de webs lentas. Veamos cómo su peso arruina el LCP y los Core Web Vitals, cómo afecta al posicionamiento en Google y a la conversión, y cómo aligerar una galería en tres pasos.
Una web carga despacio y la primera sospecha suele recaer en el alojamiento o en un tema "pesado". Sin embargo, en la mayoría de los casos el culpable es de lo más banal: las imágenes. Una sola foto recién salida de la cámara puede pesar tanto como todo el código de una página, y bastan unas pocas en la portada para que quien visita la web espere varios segundos por algo que debería aparecer al instante.
Esto no es un problema puramente estético. El peso de las imágenes repercute directamente en los Core Web Vitals — el conjunto de métricas con las que Google mide la experiencia real de uso de una página. Esas métricas influyen en el posicionamiento y, de forma aún más tangible, en si el visitante se queda. Veamos por qué las imágenes pesan más que nada y cómo aligerarlas sin estropear el aspecto.
Por qué son las imágenes las que ralentizan una web
La página media de hoy es, en buena parte, imágenes. El HTML, las hojas de estilo e incluso los scripts se cuentan en kilobytes, mientras que una sola foto del móvil se va a los megabytes. Las proporciones pueden ser dramáticas: el texto y la maquetación suman 200 KB, y la galería de debajo — ocho megabytes.
A eso se añade un segundo asunto: las imágenes suelen bloquear lo que el usuario ve primero. Una foto de cabecera, un banner o una imagen de producto en la parte superior es, por lo general, el elemento más grande que el navegador tiene que descargar y dibujar antes de que la página parezca lista. Mientras ese archivo se descarga, el visitante mira un vacío o un esqueleto que se descuadra.
Y, por último, las imágenes suelen ser muchas. Un archivo pesado es un problema, pero veinte miniaturas de producto de medio megabyte cada una son ya diez megabytes que descargar antes de que el cliente vea la oferta.
El LCP, o cómo las imágenes arruinan los Core Web Vitals
La métrica más importante sobre la que influyen las imágenes es el LCP (Largest Contentful Paint) — el tiempo que tarda en aparecer en pantalla el elemento visible más grande. En la inmensa mayoría de las páginas, ese elemento es una imagen: la foto de cabecera, el banner principal, la primera imagen de un artículo.
El mecanismo es sencillo. Cuanto más pesada sea esa imagen clave, más tarda en descargarse y mostrarse, y más tarde "encaja" la página. Google considera bueno un LCP por debajo de 2,5 segundos, mejorable entre 2,5 y 4 segundos, y deficiente por encima de 4 segundos. Basta un único banner sin optimizar de varios megabytes para caer en la zona roja incluso con buena conexión — y en un móvil, aún más.
Las imágenes también pueden empeorar el CLS (Cumulative Layout Shift) — la métrica que mide cuánto salta el contenido durante la carga. Cuando una imagen no tiene su espacio reservado de antemano, el texto se coloca primero y luego da un brinco hacia abajo al llegar la foto. Es molesto y penaliza. Aquí el remedio está en la maquetación y no en el peso, pero conviene tenerlo presente, porque los dos problemas suelen ir de la mano.
El peso de las imágenes frente al posicionamiento y la conversión
La velocidad de la página es uno de los factores que Google tiene en cuenta al ordenar los resultados, y los Core Web Vitals son las señales concretas y medibles de esa velocidad. No es un interruptor mágico que vaya a llevar una página a lo más alto por sí solo — el contenido y la relevancia para la búsqueda pesan más — pero entre dos páginas de calidad parecida, el rendimiento puede inclinar la balanza. Una página lenta y cargada de imágenes parte de una posición peor.
La segunda cara de la moneda, a menudo infravalorada, es la conversión. Las cifras hablan solas: cada segundo extra de carga aumenta el porcentaje de personas que se rinden antes de ver nada, y en el móvil la paciencia se agota todavía antes. Una tienda que muestra un producto a los cinco segundos pierde clientes frente a otra que lo hace en uno — al margen del precio.
Por lo que vemos: aligerar las imágenes suele ser la optimización de rendimiento más barata que existe. No requiere reescribir código ni cambiar de alojamiento, y el efecto en las métricas se nota de inmediato.
Los tres pilares de la optimización de imágenes
Todo el arte se reduce a tres movimientos, ejecutados en el orden correcto. Cada uno recorta peso, y juntos pueden quitar entre un 80 y un 90 por ciento sin diferencia visible en pantalla.
Pilar 1: las dimensiones correctas para el diseño
El error más común es subir imágenes con las dimensiones de la cámara — 4000, 6000 píxeles de ancho — a un hueco que en la página mide 800 o 1200 píxeles como mucho. El navegador reducirá esa imagen sobre la marcha, pero el visitante descarga igualmente la versión completa y enorme. Puro ancho de banda desperdiciado.
La regla es sencilla: una imagen debe tener tantos píxeles como ocupa realmente en pantalla (con un margen para pantallas de alta densidad — normalmente basta con multiplicar por dos). Una foto dentro de un artículo rara vez necesita más de 1600 px en el lado largo, una miniatura de producto 600–800 px, un fondo a pantalla completa unos 1920 px. Bajar de 4000 a 1600 px ya puede recortar dos tercios del peso antes de tocar la compresión. Con muchas fotos, lo más cómodo es hacerlo por lotes — el redimensionado por lotes procesa toda la tanda de una vez.
Pilar 2: un formato moderno — WebP o AVIF
El formato decide cómo se codifican esos mismos píxeles. JPG sigue siendo una opción sólida, pero WebP, con la misma calidad, suele pesar entre un 25 y un 35 por ciento menos, y AVIF baja aún más. Hoy ambos los soportan todos los navegadores que cuentan.
En la práctica, para la mayoría de las webs, pasar de JPG a WebP da la mayor ganancia con el menor esfuerzo. Si una galería está en JPG, convertirla a WebP por sí solo puede reducir el peso total en un tercio. Basta con conservar una alternativa en JPG para los pocos sitios que no abren WebP — y cuando hay que invertir el sentido, ayuda una rápida conversión de WebP a JPG. Una guía aparte cubre las diferencias entre formatos: JPG, PNG, WebP o AVIF.
Pilar 3: una compresión sensata
La compresión va al final — el sacrificio deliberado del detalle que el ojo no capta de todos modos. El truco está en dar con el punto en el que el archivo es pequeño pero la pérdida es invisible. Para fotos, una calidad en torno al 75–85 por ciento es el término medio — por debajo empiezan a verse bordes "cuadriculados" y manchas en las superficies lisas.
Cuando quieres un peso concreto y predecible, es más fácil que jugar con el control de calidad indicar el tamaño objetivo y dejar que la herramienta haga el resto. Así funciona la compresión a 200 KB — un techo razonable para las imágenes más grandes dentro de un artículo; para miniaturas y gráficos más pequeños se recurre a la variante a 100 KB. Todo el proceso ocurre en el navegador, así que las fotos no salen del dispositivo.
Sirve la imagen al tamaño en que se muestra
Esta regla merece su propio párrafo, porque es la que más se incumple. No tiene sentido subir una imagen más grande de lo que pide el diseño de la página. Si la foto de un producto se muestra en una casilla de 400 píxeles de ancho, un archivo de 3000 px es diez veces más datos — datos que alguien tiene que descargar y que el navegador descarta de todos modos.
En la práctica, esto significa ajustar las dimensiones del archivo a su hueco real en la maquetación, y no a lo que escupió la cámara. Una imagen de fondo, un hero en la parte superior, una miniatura en una cuadrícula y una foto dentro de un artículo son cuatro tamaños distintos — y cada uno debería tener su propia versión ajustada, en lugar de un único archivo gigante para todo.
Lazy-loading, o carga lo que se ve
Otra ganancia barata es la carga diferida. Los navegadores pueden cargar las imágenes solo cuando el usuario llega a ellas al desplazarse, en lugar de descargar de golpe una página entera. Basta con añadir el atributo loading="lazy" a las imágenes por debajo de la primera pantalla.
Hay una excepción que conviene recordar: la imagen principal de la parte superior (la del LCP) no debe diferirse — al contrario, es la que debe cargarse cuanto antes. El lazy-loading se reserva para las galerías y las fotos de más abajo.
Miniauditoría de las imágenes de tu página
Antes de empezar a optimizar, conviene saber dónde se escapan de verdad los megabytes. Esta miniauditoría lleva unos minutos:
- Abre la página y pésala. En el navegador basta el panel de herramientas de desarrollo (la pestaña "Network"): muestra el peso total de la página y cuánto de él son imágenes. Lo más habitual es que las imágenes supongan bastante más de la mitad.
- Localiza los archivos más grandes. Ordena los recursos por tamaño. Suele destacar un puñado de culpables — unas pocas fotos pesadas que marcan la diferencia por sí solas.
- Compara dimensiones con visualización. Para cada imagen grande, compara sus dimensiones con el espacio que ocupa en pantalla. Si un archivo tiene 4000 px y la casilla 400, ya tienes tu primer candidato a reducir.
- Mira el formato. Un archivo con extensión
.pngen fotografías normales es una señal de alarma — el PNG para fotos puede pesar varias veces de más. - Mide el LCP. Las herramientas gratuitas de Google muestran qué elemento es el más grande y cuánto tarda en mostrarse. Eso indica por qué imagen empezar.
Tras esa revisión suele resultar que un puñado de archivos concentra el 80 por ciento del problema. Aligerar esos da el mayor salto y por ahí conviene empezar.
Peso objetivo de las imágenes por página
No hay un número único, pero sí puntos de referencia razonables. Una foto dentro de un artículo debería caber en 100–300 KB, un banner o hero más grande hasta 400–500 KB, una miniatura por debajo de 100 KB. Si algún archivo supera el megabyte, casi siempre se puede aligerar sin riesgo.
A nivel de toda la página, un buen objetivo es un peso total de imágenes por debajo de uno, como mucho dos megabytes — contando todo lo que se ve al llegar. Suena estricto, pero después de pasar por los tres pilares resulta bastante alcanzable, y la diferencia de velocidad se ve a simple vista.
Una nota para terminar: dado que todo el proceso — redimensionar, convertir y comprimir — puede hacerse en el navegador, las fotos de producto o las imágenes de clientes no tienen que acabar en el servidor de nadie solo para aligerarse. Los detalles están en nuestra política de privacidad.
FAQ
¿Por qué mi web carga despacio si el código es ligero?
En la mayoría de los casos son las imágenes. Una sola foto recién salida de la cámara puede pesar más que todo el código de una página, y unas pocas en la parte superior ya son varios megabytes que descargar antes de que aparezca nada. Pesa la página en las herramientas de desarrollo — las imágenes suelen suponer bastante más de la mitad del peso.
¿Cómo afectan las imágenes a los Core Web Vitals?
Sobre todo a través del LCP, el tiempo que tarda en aparecer el elemento más grande — que suele ser la imagen principal. Cuanto más pesa, más tarde parece lista la página. Las imágenes sin espacio reservado también empeoran el CLS, el salto del contenido durante la carga.
¿Cuánto deberían pesar las imágenes de una página?
Una sola foto dentro de un artículo, mejor en 100–300 KB, un banner hasta 400–500 KB, una miniatura por debajo de 100 KB. El peso total de las imágenes visibles al llegar debería caber en uno, como mucho dos megabytes.
¿De verdad marca la diferencia WebP frente a JPG?
Sí. Con la misma calidad, WebP suele pesar entre un 25 y un 35 por ciento menos, y todos los navegadores actuales lo soportan. Para la mayoría de las webs, pasar de JPG a WebP da la mayor ganancia con el menor esfuerzo.
¿Tengo que optimizar las imágenes una a una?
No. Lo más cómodo es pasar todo el lote por el redimensionado y la compresión de una vez y descargar el resultado como ZIP. Todo el proceso ocurre en el navegador, así que los archivos no se envían a ningún sitio.