Definición
El lazy loading o carga diferida consiste en no cargar un recurso hasta que realmente se necesita.
La alternativa —cargarlo todo de entrada— hace que el navegador descargue imágenes que el visitante quizá nunca vea y código de funciones que quizá nunca use. En una página larga, eso puede ser la mayor parte del peso.
Se aplica a tres cosas distintas:
Imágenes y vídeos, que se cargan al acercarse a la zona visible. Es lo más común y da el mayor beneficio, porque las imágenes suelen ser el grueso del peso.
Código. Cargar el JavaScript de una funcionalidad solo cuando se abre. Un editor complejo, un mapa, un visor de documentos.
Datos. Traer resultados por bloques según el usuario avanza, en lugar de los mil de golpe.
Cómo se hace en imágenes
Hoy no hace falta ninguna biblioteca: el propio HTML lo soporta con un atributo de carga diferida, y los navegadores lo gestionan solos.
Y con dos matices que cambian el resultado por completo:
No diferir la imagen principal. La imagen grande de cabecera es habitualmente el elemento que define el LCP. Diferirla retrasa su descarga y empeora la métrica que se pretendía mejorar. Esa imagen debe cargarse cuanto antes; a veces incluso con prioridad alta explícita.
Reservar el espacio siempre. Si la imagen no tiene dimensiones declaradas, el hueco es cero hasta que llega y entonces el contenido salta. Eso es CLS, penaliza y resulta muy molesto de usar. Declarar ancho y alto —o una proporción en CSS— lo evita.
Ejemplo práctico
En una web con muchas imágenes de producto, la carga diferida es de las mejoras más rentables que existen: se aplica en minutos y puede recortar drásticamente el peso inicial.
Lo que aprendí optimizando una portada pesada: la carga diferida es la segunda medida, no la primera. Antes hay que hacer lo obvio: las imágenes tienen que pesar lo que deben. Una foto de varios megas servida a tamaño completo y reducida por CSS sigue descargándose entera aunque se difiera.
El orden que funciona:
- Redimensionar a lo que realmente se muestra.
- Convertir a un formato moderno, que ahorra mucho sin pérdida visible.
- Servir tamaños distintos según la pantalla.
- Y entonces diferir lo que está por debajo del pliegue.
Con ese orden, una portada de varios megas baja a una fracción. Diferir sin comprimir solo reparte el mismo peso a lo largo del scroll.
El segundo aprendizaje, sobre el código: diferir JavaScript pesado es donde más se nota en interactividad. Si una funcionalidad la usa el 5 % de los visitantes, cargar su código para el 100 % es puro desperdicio. La versión más simple y efectiva de esto es no cargar nada de una biblioteca hasta que el usuario abre lo que la necesita.
Y una advertencia sobre el buscador: si el contenido solo aparece tras una interacción del usuario —un clic, un scroll simulado que un rastreador no hace—, puede no indexarse. El texto importante debe estar en el HTML inicial. Diferir imágenes es seguro; diferir contenido textual relevante es arriesgado. Ver JavaScript SEO.
Errores comunes
- Diferir la imagen de cabecera y empeorar el LCP.
- No reservar espacio, provocando saltos.
- Diferir sin comprimir, que reparte el peso sin reducirlo.
- Diferir texto relevante y perder indexación.
- Aplicarlo a todo indiscriminadamente, incluidos iconos diminutos.
- Usar una biblioteca para algo que el navegador ya hace.
- No probar en conexión lenta, donde se ven los huecos vacíos.
Cuándo aplicarlo
En imágenes por debajo de la primera pantalla, en listados largos y en código de funcionalidades que no todo el mundo usa.
La regla que evita el error clásico: lo que se ve al abrir, carga ya; lo que hay que buscar, carga después. Y siempre con el espacio reservado.
