Las imágenes son la razón de que tu web vaya lenta

Por qué merece tu tiempo

El Largest Contentful Paint es una de las Core Web Vitals, y las Core Web Vitals son un factor de posicionamiento. El umbral que fija Google son 2,5 segundos; a partir de ahí la página se clasifica como mejorable, y el efecto se suma a la consecuencia natural de una página lenta, que es que la gente se va.

La comparación que lo hace concreto: una página de 3 MB en una conexión móvil normal tarda varios segundos antes de mostrar nada útil. La misma página en 800 KB se siente instantánea. Mismo contenido, mismo diseño, mismo servidor.

Paso uno: redimensionar (este es el gordo)

La cámara de un móvil produce imágenes de unos 4000 píxeles de ancho. Tu columna de artículo mide 800 píxeles CSS. En una pantalla de alta densidad el navegador querrá unos 1600 píxeles físicos para ella, así que alrededor del 84% de los datos de esa fotografía se descargan y se descartan de inmediato.

Exporta al doble del ancho de visualización y ni un píxel más. Para la mayoría de webs eso significa 1600-2000 píxeles en cabeceras y 1600 dentro del artículo. Nada más en esta lista ahorra tanto, y todo lo demás sale más barato si haces esto primero.

Paso dos: convertir a WEBP

El WEBP produce archivos entre un 25% y un 35% más pequeños que el JPG con una calidad visual idéntica, y un ahorro parecido frente al PNG en gráficos. Todos los navegadores en uso lo soportan. Es un 30% de rebaja gratis sobre las imágenes que ya redimensionaste.

Si quieres ir más lejos, el AVIF es aproximadamente un 50% más pequeño que el JPG, a cambio de codificación más lenta y soporte más irregular en las herramientas alrededor de tu web. Sírvelo con WEBP como alternativa, no en lugar de él.

Paso tres: comprimir al nivel correcto, una sola vez

Calidad 80-85 es donde quieres estar en fotografías. Por encima de 90 estás enviando bytes que nadie puede percibir; por debajo de 75 los artefactos empiezan a notarse en degradados y tonos de piel.

Comprime desde el original, nunca desde una copia ya comprimida: el daño de codificar con pérdida repetidamente se acumula y no se recupera. Apunta a imágenes de artículo por debajo de 150 KB y cabeceras por debajo de 300 KB.

• Cabecera: 1600-2000 px de ancho, WEBP calidad 82, menos de 300 KB.
• Dentro del artículo: 1600 px de ancho, WEBP calidad 80, menos de 150 KB.
• Miniaturas: 600 px de ancho, WEBP calidad 75, menos de 30 KB.

Paso cuatro: el marcado que no cuesta nada

Tres atributos hacen un trabajo sorprendente, y los tres son cambios de una línea.

Pon width y height explícitos en todas las imágenes. Sin ellos el navegador no sabe cuánto espacio reservar, así que la página da saltos según van llegando las imágenes: eso es el Cumulative Layout Shift, otra Core Web Vital, y es completamente evitable.

• width y height en cada img — elimina el salto de maquetación.
• loading="lazy" en las imágenes por debajo del pliegue: no se descargan hasta que hacen falta.
• fetchpriority="high" solo en la imagen de cabecera: le dice al navegador cuál es el LCP.
• Nunca apliques carga diferida a la cabecera. Retrasa justo el elemento que mide el LCP.

Qué medir después

Prueba con una conexión móvil limitada, no en tu escritorio con el wifi de la oficina. Las herramientas de desarrollo de Chrome pueden simular 4G lenta, y PageSpeed Insights lo hace por defecto — por eso su puntuación siempre es peor que lo que ves en local, y por eso su puntuación es la que importa.

Después mira a tus usuarios reales y no al laboratorio. El informe de Core Web Vitals de Search Console muestra datos de campo de visitantes reales, en dispositivos y conexiones reales. Esos son los datos con los que Google posiciona, y son gratis.