¿Qué es el lazy loading?

La carga diferida le dice al navegador que no descargue una imagen o un <iframe> hasta que el usuario se acerque a él. Desde 2020 no hace falta ninguna biblioteca: basta con loading="lazy" en la etiqueta. El valor contrario es eager, que es además el comportamiento por defecto.

La decisión de cuándo empezar la descarga la toma el propio navegador con un umbral de distancia que varía según la conexión: en una red lenta empieza antes para que la imagen llegue a tiempo. Por eso no existe un número fijo de píxeles, y por eso tampoco sirve de nada intentar afinarlo desde el CMS.

Antes de que existiera el atributo, cada sitio resolvía esto con una biblioteca de JavaScript propia: se marcaba la imagen con un atributo inventado, un script vigilaba el desplazamiento y movía la ruta al src real en el momento adecuado. Funcionaba, y traía dos costes. Uno era el peso del propio script; el otro, que un fallo de JavaScript dejaba la página sin ninguna imagen, algo que un crawler ve igual de vacío que un visitante.

La versión nativa quita ambos problemas y añade uno nuevo, más sutil: como no cuesta nada activarla, se activa en todas partes. Un ajuste global en el CMS marca cada imagen del sitio en un clic, y nadie vuelve a mirar cuál era la primera. Esa comodidad es la razón por la que este atributo aparece hoy en tantas auditorías de SEO técnico como causa de un problema, y no como solución.

La regla cabe en una frase: carga diferida en todo menos en la primera imagen visible. Debajo del pliegue ahorra datos y libera ancho de banda; encima del pliegue retrasa justo el elemento que marca el LCP.

El daño no es teórico. Google documenta el caso expresamente porque muchos gestores de contenido aplican el atributo a todas las imágenes por norma, la de cabecera incluida. El navegador deja entonces de pedir temprano el archivo más importante y espera a saber dónde cae en el diseño, algo que en una plantilla con diseño responsive se decide tarde.

Merece la pena entender por qué el daño es tan grande para un cambio tan pequeño. El navegador construye una lista de prioridades mientras lee el HTML y empieza a descargar lo más importante antes de terminar de leer. Una imagen marcada como diferida sale de esa lista temprana por definición: el navegador decide no pedirla hasta saber dónde queda, y para saberlo necesita el CSS aplicado y el diseño calculado.

En una plantilla moderna eso ocurre bastante después del primer byte. El resultado es que el archivo más importante de la página se pide de los últimos, y el LCP recoge esa espera entera. Por eso el efecto se nota más en móvil, donde el índice mobile-first decide y la red suele ser peor, que en el escritorio del equipo que hizo el cambio.

Una imagen diferida sin width y height declarados provoca un salto de maquetación cuando por fin llega: el navegador no reservó sitio. Eso empeora otra de las Core Web Vitals y molesta al usuario justo cuando está leyendo.

Los <iframe> aceptan el mismo atributo, y ahí suele estar la ganancia mayor: un vídeo incrustado o un mapa cargan cientos de kilobytes de scripts ajenos. Para imágenes de fondo puestas por CSS el atributo no existe; ahí hace falta un observador de intersección en JavaScript, con el coste de mantenimiento que eso implica en el SEO on-page técnico.

Hay un tercer requisito que se olvida más que los dos anteriores: las imágenes diferidas deben seguir estando en el HTML como <img> normales, con su src y su atributo ALT puestos. Si el gestor las sustituye por un marcador que un script rellena después, el contenido depende de que ese script se ejecute, y eso afecta a la indexación de las propias imágenes en la búsqueda de Google Imágenes.

Para las páginas que viven de imágenes, una ficha de producto de e-commerce o una galería, ese detalle decide si las fotos aparecen en resultados de imagen o no. Y conviene medirlo con datos, no de oído: el informe de rendimiento de Search Console separa la búsqueda de imágenes de la web, así que la caída se ve donde ocurre.

Abre la página, mira qué elemento marca el LCP en PageSpeed Insights y comprueba si ese <img> lleva loading="lazy". Si lo lleva, ya tienes la causa y la corrección en el mismo paso.

Después conviene mirar los datos de campo en Google Search Console, que tardan semanas en moverse, y no solo la prueba de laboratorio. Y si el sitio vive de e-commerce, vale la pena cruzar el cambio con la conversión: la velocidad se nota antes en el negocio que en el informe.

La segunda comprobación es más aburrida y más útil: mirar el código de la plantilla, no de una página. El problema casi nunca vive en una entrada concreta, sino en el archivo que genera todas. Corregir la ficha que se estaba mirando deja el resto igual, y a la semana siguiente el informe vuelve a marcar rojo con otra URL.

Si el sitio tiene muchas plantillas, conviene ordenar por lo que más tráfico recibe antes de tocar nada, y volver a medir con el mismo criterio después. Un KPI que sube en una plantilla y baja en otra no dice nada si se miran juntos.

• Activar la carga diferida en todo el sitio desde un ajuste global sin excluir la primera imagen.
• Olvidar width y height, y cambiar un problema de velocidad por uno de estabilidad visual.
• Aplicarlo a imágenes diminutas como iconos, donde la petición extra cuesta más de lo que ahorra.
• Mantener una biblioteca de JavaScript para algo que el navegador ya hace solo.
• Dar por hecho que ayuda al crawler: el robot no desplaza la pantalla como una persona.

Y un malentendido de fondo que explica varios de los errores anteriores: la carga diferida no hace la página más rápida, sino que reparte el trabajo de otra manera. El total descargado durante una visita completa puede ser el mismo; lo que cambia es cuánto de ese total ocurre antes de que el usuario vea algo. Quien espera que el peso total baje se decepciona, y quien mide solo el peso total no ve la mejora que sí existe en el page speed percibido.