Lazy loading en WordPress: lo que el navegador ya hace y dónde frena un plugin

Durante mucho tiempo, el lazy loading fue un motivo para instalar un plugin. Un script cambiaba marcadores de posición por las imágenes reales en cuanto alguien bajaba por la página, y la web parecía más rápida. Hoy ese trabajo lo hace el navegador, con un único atributo HTML. WordPress te lo escribe en el código fuente sin que lo pidas.

Si aun así sigues arrastrando un lazy loader de otros tiempos, tienes dos mecanismos para la misma tarea. En el mejor de los casos, eso sobra. En el peor, retrasa la imagen que tus visitantes esperan durante más tiempo.

Qué hace en realidad loading="lazy"

El atributo es una petición al navegador para que no pida una imagen de inmediato. Según la referencia de MDN sobre el elemento img, el navegador retrasa la carga hasta que la imagen alcanza una distancia respecto a la zona visible que él mismo calcula. Esa distancia no la decides tú. La decide el navegador, y está bien así: él conoce la conexión y la pantalla, tú no.

Con las páginas incrustadas pasa lo mismo, porque el elemento iframe también admite loading="lazy" y entonces solo se pide cuando se acerca a la zona visible. Eso afecta a vídeos incrustados, mapas y formularios de terceros.

<img src="puerto.jpg" width="1200" height="800" loading="lazy" alt="Buque portacontenedores en el muelle">

Fíjate en width y height. Sin medidas, el navegador no sabe cuánto espacio ocupará la imagen antes de que llegue, y el texto de debajo salta cuando aparece. Con las imágenes diferidas se nota más, porque la carga ocurre en plena lectura. WordPress saca de ahí una consecuencia tajante, enseguida vamos con ella.

Lo que WordPress hace automáticamente desde hace años

No tienes que poner el atributo tú. El núcleo se encarga desde 2020 y ha afinado las reglas varias veces desde entonces. Cada fila se basa en la nota para desarrolladores correspondiente de make.wordpress.org.

En la práctica, esto significa que un WordPress actual con un tema bien hecho carga en diferido las imágenes de más abajo y con prioridad la imagen principal de arriba, sin que toques ningún interruptor.

Sigue siendo una estimación. WordPress decide en el servidor qué imagen estará probablemente arriba, y no conoce ni el tamaño de pantalla de tu visitante ni lo que tu tema hace con el contenido mediante CSS. En un blog de una sola columna suele acertar. En portadas con cuadrícula de tarjetas, slider o constructor de páginas, conviene comprobar si la estimación es correcta.

Por qué la imagen LCP nunca debe cargar en diferido

LCP significa Largest Contentful Paint: el momento en que se ve el elemento más grande de la primera pantalla. Casi siempre es una imagen destacada, una foto de cabecera o la vista previa de un vídeo, a veces un bloque de texto grande. Google lo cuenta entre las Core Web Vitals, y se considera bueno un LCP de 2,5 segundos o menos.

Una imagen con loading="lazy" el navegador no la pide hasta que ha calculado el diseño y sabe dónde está. Para una imagen muy abajo, eso es lo correcto. Para la imagen más importante de la página, es el orden equivocado: espera a un paso de cálculo que no necesitaría y empieza más tarde de lo que podría. La guía de Google para optimizar el LCP lo dice sin ningún matiz: nunca cargues en diferido la imagen LCP, porque eso siempre provoca un retraso innecesario.

WordPress comprobó en su propio núcleo lo real que es el problema. En la primera versión de 2020, casi todas las imágenes recibían el atributo, también la de arriba. Felix Arntz y Rick Viscomi analizaron las consecuencias para web.dev (datos a marzo de 2022): el 84 por ciento de las webs con lazy loading nativo del navegador funcionaban con WordPress, y en la prueba de laboratorio con el tema por defecto Twenty Twenty-One el LCP de las páginas de archivo mejoró entre un 13 y un 15 por ciento al desactivar el lazy loading, mientras que en las entradas individuales apenas había diferencia. La corrección llegó con la versión 5.9, mira la tabla.

Por qué un plugin de lazy load adicional no suele aportar nada

Los scripts clásicos de lazy load siguen un patrón que reconoces enseguida en el código fuente. La dirección real de la imagen pasa de src a un atributo sustituto como data-src, en su lugar queda un marcador de posición, y un script devuelve la dirección en cuanto la imagen entra en el campo de visión. Antes de que el atributo se convirtiera en estándar web en 2020, era el único camino. Hoy tiene cuatro inconvenientes:

• El navegador ve la imagen demasiado tarde. Normalmente empieza a descargarla en cuanto lee el HTML. Si allí solo hay un marcador de posición, la imagen espera al script, y el script espera a todo lo que carga antes que él.
• La imagen de arriba es la que más lo sufre. Un script que trata igual todas las imágenes retrasa también la imagen LCP. Ese error lo corrigió WordPress en su propio núcleo con la 5.9 y la 6.3.
• Dos mecanismos para una tarea. Según el plugin, el atributo del núcleo se mantiene además o se elimina. Si algo no carga, buscas en dos sitios.
• Sin JavaScript no hay imagen. Si el script falla, por ejemplo por un error en un plugin que no tiene nada que ver, el marcador de posición se queda ahí, salvo que haya un sustituto en noscript.

Lo caro que puede salir una imagen principal cargada por script lo medimos en nuestro caso real de cambio de tema. Tras pasar a un tema de WordPress rápido, el LCP en móvil seguía entre 4 y 6 segundos, porque el elemento más grande de las páginas clave era el póster de un vídeo que solo se cargaba después con JavaScript. En una segunda ronda, esa imagen de vista previa se pidió con preload y prioridad alta y se mostró de inmediato como fondo CSS, en lugar de esperar al script de incrustación.

En la página del curso, el LCP bajó después de 5,2 a 4,0 segundos, medido en móvil con Lighthouse. Por honestidad hay que añadir dos límites. En la misma ronda entraron otras medidas, y no medimos por separado la parte que corresponde al póster. Y 4,0 segundos siguen por encima del límite de 2,5.

Nuestra recomendación para un WordPress actual: desactivar las funciones de lazy load de los plugins, dejar el trabajo al núcleo y volver a medir. Si usas un plugin de optimización cuyo lazy load quieres conservar, mira si puede excluir las imágenes de la parte superior, y saca como mínimo la imagen principal.

Cómo comprobar si tu imagen LCP carga en diferido por error

El vistazo rápido: Inspeccionar

1. Abre la página en Chrome, pulsa F12 y activa la vista de dispositivo con Ctrl+Mayús+M. En el móvil, el elemento más grande puede ser otro que en el escritorio.
2. Clic derecho en la imagen grande de la primera pantalla y luego Inspeccionar.
3. Revisa la etiqueta img. Si pone loading="lazy", o falta src y solo hay data-src junto con una clase como lazyload, tu imagen más importante carga con retraso.
4. Si pone fetchpriority="high", WordPress o tu tema la han reconocido bien.

El vistazo a fondo: panel Rendimiento y Lighthouse

En el panel Rendimiento (Performance) de las herramientas para desarrolladores y en Lighthouse aparece el aviso «LCP request discovery» (así se llama en la interfaz en inglés). Según la documentación de Chrome, comprueba si la imagen LCP se puede descubrir directamente en el HTML, si lleva fetchpriority="high" y si prescinde de loading="lazy".

Para curiosos: una línea en la consola

new PerformanceObserver(l => { const e = l.getEntries().at(-1); console.log(e.element, e.element?.loading, Math.round(e.startTime) + ' ms'); }).observe({ type: 'largest-contentful-paint', buffered: true });

Pégala en la consola de las herramientas para desarrolladores y pulsa Intro. Muestra el elemento LCP, su valor de loading y el momento en milisegundos. Si pone lazy, has encontrado el fallo. El valor de tiempo sale de tu ordenador y de tu conexión, y no sustituye a una medición en condiciones iguales.

Si encuentras algo

• Lazy loader en un plugin: añade una excepción para la imagen principal o desactiva la función por completo.
• Imagen en una plantilla del tema: si la muestras con wp_get_attachment_image(), pasa 'loading' => false y WordPress omite el atributo.
• Imagen hero como fondo CSS: el navegador no la ve hasta haber leído la hoja de estilos. Aquí ayuda una precarga con prioridad en la cabecera de la página, como en nuestro caso real:

<link rel="preload" as="image" href="/imagenes/hero.webp" fetchpriority="high">

Cuándo sí tienen sentido un plugin o unas líneas de script

Imágenes de fondo desde CSS

El atributo existe para img e iframe. A la pregunta de si las imágenes de fondo CSS pueden usarlo, la guía de Google sobre el lazy loading nativo del navegador responde con un no escueto. Para imágenes de fondo grandes muy abajo, de las que los constructores de páginas suelen poner en las secciones, no hay por tanto ningún freno integrado.

Aquí sí se justifica un script que solo añade la clase con la imagen de fondo cuando la sección entra en el campo de visión, con IntersectionObserver. A menudo, rehacer la sección es la mejor solución. Donde una imagen de fondo es en realidad contenido, va en el HTML como img, y el navegador vuelve a encargarse él solo.

Vídeos incrustados: una fachada en lugar del reproductor

En los vídeos de YouTube, WordPress pone desde la 5.7 loading="lazy" en el iframe si las medidas están. Eso aplaza la carga, pero no la evita. Cuando el vídeo se acerca a la pantalla, el navegador carga el reproductor completo, conexión con YouTube incluida, aunque nadie pulse reproducir.

Por eso en hafenstudios.com incrustamos los vídeos como fachada. En el HTML no hay ningún iframe, sino un enlace al vídeo en YouTube con una imagen de vista previa de nuestro propio servidor. Solo el clic sustituye el enlace, mediante un script, por un iframe a youtube-nocookie.com que empieza a reproducirse enseguida. Hasta entonces, la fachada no carga nada de YouTube, y sin JavaScript queda un enlace normal que lleva a YouTube. Simplificado y sin estilos, se ve como en la entrada con nuestro primer vídeo:

<a class="yt-facade" href="https://youtu.be/VIDEO-ID" data-ytid="VIDEO-ID">
  <img src="/assets/blog/vista-previa.jpg" width="1280" height="720" decoding="async" alt="…">
</a>
<script>
document.querySelector('.yt-facade').addEventListener('click', function (e) {
  e.preventDefault();
  var i = document.createElement('iframe');
  i.src = 'https://www.youtube-nocookie.com/embed/' + this.dataset.ytid + '?autoplay=1';
  i.allow = 'autoplay; encrypted-media; picture-in-picture';
  i.allowFullscreen = true;
  this.innerHTML = '';
  this.appendChild(i);
});
</script>

La imagen de vista previa es un img normal y sigue las mismas reglas que cualquier otra imagen. En las entradas con vídeo, la fachada está justo después del primer párrafo y no lleva atributo loading. En la página de producto de nuestro plugin de anuncios Adjet no aparece hasta la tercera sección. En el informe de laboratorio del 28 de septiembre de 2026, la versión alemana de esa página tenía en móvil un LCP de 2,5 a 2,6 segundos, la única de 14 páginas medidas por encima de 2,5 segundos, y el informe anotaba una imagen de vista previa de 129 KB que se cargaba de inmediato. Desde el 29 de septiembre lleva loading="lazy" en todas las versiones de idioma y se sirve en WebP. El informe no recoge una nueva medición, por eso aquí no damos una cifra posterior.

Galerías con muchas imágenes

En las galerías es donde más ahorra el lazy loading. Una página con 60 fotos carga al abrirse solo las que están cerca de la pantalla, el resto llega al desplazarse. Para eso no necesitas un lazy loader propio en el plugin de galerías. Pero tres cosas tienen que estar bien:

• Ancho y alto en cada imagen. Sin ambos, WordPress ni siquiera pone el atributo, y la cuadrícula salta al cargar.
• srcset y sizes. El lazy loading ahorra las imágenes que nadie ve. En las que sí se cargan, decide el tamaño adecuado: un móvil no necesita un archivo a todo el ancho para una tarjeta estrecha. Las imágenes de la biblioteca de medios reciben srcset de WordPress.
• No retrasar la primera fila. Si la galería está arriba del todo, sus primeras imágenes son candidatas a imagen LCP. WordPress deja fuera desde la 6.3 las tres primeras imágenes del contenido. Si tu primera fila muestra cuatro o cinco imágenes, sube el umbral para esa página:

add_filter( 'wp_omit_loading_attr_threshold', function ( $umbral ) {
	return is_page( 'galeria' ) ? 8 : $umbral;
} );

El filtro viene de WordPress 5.9 y va en el functions.php de un tema hijo o en un plugin de snippets. El número corresponde a las imágenes que tienes en la primera pantalla. No más, o pierdes el ahorro de más abajo.

Si las imágenes están fuera de la biblioteca de medios, por ejemplo en tablas y carpetas propias de un plugin de galerías, el núcleo no añade ni srcset ni las medidas que falten, porque ambas cosas solo puede calcularlas para adjuntos de la biblioteca de medios. En nuestro plugin de galerías Heckgalerie, una galería es una lista de adjuntos normales de la biblioteca de medios: srcset y tamaños de imagen vienen de WordPress, las cuadrículas y las barras de logos funcionan sin JavaScript, y solo carga scripts en las páginas que contienen un slider o un lightbox (así consta en su ficha del directorio de WordPress, a 4 de octubre de 2026). Si quieres dejar un plugin de galerías pesado, encontrarás candidatos en la comparativa de alternativas a NextGEN Gallery.

Sigue este orden

1. Mantén WordPress al día, a partir de la 6.3 el núcleo hace el trabajo básico.
2. Desactiva los lazy loaders duplicados. Basta con uno, y el núcleo ya lo es.
3. Revisa el elemento LCP en móvil y en escritorio: nada de loading="lazy", nada de data-src.
4. Resuelve a propósito las imágenes de fondo y los vídeos.
5. Mide antes y después, con el mismo método. Lo demás que cuesta velocidad está en la guía para acelerar una web WordPress lenta.

Preguntas frecuentes