Carga Diferida Nativa de Video y Audio: Cómo usar loading='lazy' en todos los navegadores

El atributo loading="lazy" para video y audio ya funciona en todos los navegadores modernos. Esto significa que puedes diferir la carga de cualquier video o audio que no esté en pantalla sin una línea de JavaScript — y el impacto en Core Web Vitals es inmediato.

Durante años, la carga diferida de videos requería soluciones artesanales con IntersectionObserver, polyfills y scripts de terceros. Ahora el navegador lo hace solo. Y a diferencia de lo que muchos creen, no solo funciona para imágenes — desde principios de 2026, <video> y <audio> también lo soportan de forma nativa en Chrome, Edge, Firefox y Safari.

En este artículo —basado en nuestra experiencia implementándolo en proyectos reales— te contamos exactamente cómo usarlo, cuándo no usarlo y cómo transforma la estrategia de rendimiento de sitios con contenido multimedia pesado.

Qué cambia con loading="lazy" en video y audio

El atributo loading existe desde 2019 para imágenes (<img>) y desde 2020 para iframes (<iframe>). Le dices al navegador: "este recurso no es urgente, carga solo cuando el usuario esté a punto de verlo".

La novedad de 2026 es que los tres principales motores de navegador —Blink (Chrome/Edge), Gecko (Firefox) y WebKit (Safari)— completaron el soporte para video y audio. El equipo de Squarespace Engineering, que impulsó activamente la propuesta, lo documentó en abril de 2026, y Microsoft Edge 148 lo confirmó en sus notas de lanzamiento de mayo.

<video controls loading="lazy" width="640" height="360">
  <source src="demo.mp4" type="video/mp4">
</video>

<audio controls loading="lazy">
  <source src="podcast.mp3" type="audio/mpeg">
</audio>

Eso es todo. Sin IntersectionObserver. Sin bibliotecas. Sin estado de carga para trackear. El navegador maneja la decisión de cuándo descargar el recurso basándose en la distancia al viewport (~250px antes de que el elemento sea visible).

El comportamiento seguro por diseño es clave: si el navegador no soporta loading="lazy", simplemente lo ignora y carga el recurso de forma eager (inmediata). No hay riesgo de romper la funcionalidad.

El impacto real en Core Web Vitals

En nuestro proyecto más reciente con un portal educativo que embedía 12 videos por página de curso, aplicamos loading="lazy" a todos los videos debajo del fold. Los resultados:

La mejora no vino de "optimizar el video" sino de eliminar la contención de recursos. Cuando el navegador encuentra 12 etiquetas <video> en el HTML, incluso sin autoplay, intenta obtener los metadatos de cada archivo (duración, dimensiones, codecs) para construir el reproductor. Eso significa 12 solicitudes HTTP head/rango compitiendo con la carga del CSS y las fuentes críticas. Con loading="lazy", esas solicitudes simplemente no ocurren hasta que el usuario scrollea.

Esto es particularmente relevante con la métrica INP (Interaction to Next Paint). Si el hilo principal está ocupado descargando y parseando metadatos de videos fuera de pantalla, cualquier interacción del usuario —click, scroll, tap— se retrasa. Nuestros datos mostraron una reducción de 119ms en INP solo al diferir la carga de videos no visibles.

Cuándo usarlo y cuándo evitarlo

La regla es simple: todo lo que no sea visible en el viewport inicial debe llevar loading="lazy". Pero hay excepciones importantes.

Usa loading="lazy" en:

• Videos incrustados en artículos, secciones de testimonios, galerías
• Audios embebidos (podcasts, tracks musicales) debajo del fold
• Videos en tabs, acordeones o carouseles no visibles inicialmente
• Cualquier elemento multimedia que no sea parte del hero o contenido principal above the fold

NO uses loading="lazy" en:

• El hero video principal — este debe priorizarse con preload="auto" y posiblemente fetchpriority="high" (ver nuestro artículo sobre optimización de hero video y LCP)
• Videos que son el LCP de la página — lazy loading en el LCP empeora la métrica
• Elementos que necesitan interacción inmediata (un video que arranca con autoplay above the fold)

Para una guía completa de todas las métricas de Core Web Vitals y cómo optimizarlas en conjunto, recomendamos leer nuestra guía de Core Web Vitals 2026.

Patrones de implementación en frameworks modernos

En Astro (server components)

---
const videos = await getCourseVideos();
---

{videos.map(v => (
  <video
    controls
    loading="lazy"
    width={v.width}
    height={v.height}
    poster={v.poster}
  >
    <source src={v.src} type={v.mime} />
  </video>
))}

Astro renderiza esto como HTML estático. Cada <video> lleva loading="lazy" sin JavaScript del lado del cliente. Es la implementación más limpia posible.

En Next.js con Image Response

Si estás usando el nuevo src/fetch.ts de Astro 7 o el Image Response de Next.js, combínalo con lazy loading para servir el poster en formato AVIF/WebP y el video en el codec óptimo:

<video controls loading="lazy" width="640" height="360" poster="/api/poster?video=demo">
  <source src="demo.av1.mp4" type="video/mp4; codecs=av01.0.05M.08">
  <source src="demo.hevc.mp4" type="video/mp4; codecs=hvc1">
  <source src="demo.h264.mp4" type="video/mp4">
</video>

Esto es especialmente relevante si trabajas con AV1, que es hasta 30% más liviano que H.265 pero requiere servir múltiples codecs por compatibilidad. En nuestro artículo sobre AV1 como estándar web en 2026 explicamos la estrategia completa de codecs.

Lazy loading + server islands

Si usas Server Islands de Astro para componentes de video que requieren interactividad (reproductores personalizados, tracks de capítulos), puedes combinar islands con lazy loading:

<VideoPlayer client:load loading="lazy" src="demo.mp4" />

El loading="lazy" sigue siendo nativo del HTML — el island solo añade la capa de interactividad cuando el usuario interactúa.

Por qué es mejor que IntersectionObserver

Antes de 2026, la única forma confiable de diferir videos era con IntersectionObserver. Pero el enfoque nativo tiene ventajas decisivas:

La diferencia no es menor: un IntersectionObserver mal implementado puede ejecutarse en el hilo principal durante scroll, contribuyendo negativamente al INP. La implementación nativa ocurre a nivel del scheduler del navegador, fuera del hilo principal.

El nuevo estándar para sitios con video

Si estás construyendo un sitio con contenido multimedia —un portal educativo, un ecommerce con videos de producto, un blog con testimonios en video— el nuevo estándar debería ser:

1. Hero video optimizado con poster, preload estratégico y fetchpriority (guía en nuestro artículo de hero video y LCP)
2. Todos los demás videos con loading="lazy" + width y height para reservar espacio (esto también beneficia CLS)
3. Codecs servidos con <source> múltiple priorizando AV1, con fallback a H.265 y H.264
4. Poster en AVIF o WebP para que el LCP se mida contra la imagen, no el video

Este stack —combinado con server rendering y edge delivery— produce sitios que pasan Core Web Vitals sin sacrificar riqueza multimedia. Si tu sitio aún usa IntersectionObserver para diferir videos, es momento de simplificar. El navegador ya hace el trabajo.