Carga diferida de imágenes y elementos de <iframe>

Las imágenes y los elementos <iframe> suelen consumir más ancho de banda que otros tipos de de Google Cloud. En el caso de los elementos <iframe>, una cantidad considerable de procesamiento adicional puede implicar tiempo en la carga y el procesamiento de las páginas que contienen.

En el caso de la carga diferida de imágenes, se aplaza la carga de las imágenes fuera del viewport inicial puede ser útil para reducir la contención del ancho de banda para más recursos críticos dentro del viewport inicial. Esto puede mejorar un el procesamiento de imagen con contenido más grande (LCP) de la página en algunos casos en los que las conexiones de red son deficientes, y ese ancho de banda reasignado puede ayudar a los candidatos de LCP a cargar y pintar más rápido.

Cuando se trata de los elementos <iframe>, la Interacción con la siguiente pintura de una página (INP) se puede mejorar durante el inicio mediante una carga diferida. Esto se debe a que un <iframe> es un documento HTML completamente independiente con sus propios subrecursos. Si bien los elementos <iframe> se pueden ejecutar en un proceso independiente, es común para compartir un proceso con otros subprocesos, lo que puede crear condiciones en las que las páginas se vuelven menos responsivas

Por lo tanto, diferir la carga de imágenes y elementos <iframe> fuera de la pantalla es un técnica que vale la pena seguir y requiere un esfuerzo bastante bajo para una buena en términos de rendimiento. En este módulo, se explica cómo usar la carga diferida dos tipos de elementos para una mejor y más rápida experiencia del usuario durante el período de período crítico de inicio.

Imágenes de carga diferida con el atributo loading

Se puede agregar el atributo loading a los elementos <img> para indicar a los navegadores cómo deberían cargarse:

  • "eager" informa al navegador que la imagen se debe cargar de inmediato. incluso si está fuera del viewport inicial. Este también es el valor predeterminado para el atributo loading.
  • "lazy" aplaza la carga de una imagen hasta que esté a una distancia determinada de la viewport visible. Esta distancia varía según el navegador, pero a menudo se configura lo suficientemente grande como para que la imagen se cargue cuando el usuario se desplaza hasta ella.

También vale la pena señalar que, si usas el elemento <picture>, el elemento El atributo loading debe aplicarse de todos modos al elemento secundario <img>, no. el elemento <picture> en sí. Esto se debe a que el elemento <picture> es un contenedor que contiene elementos <source> adicionales que apuntan a diferentes candidatos de imagen y el que elige el navegador se aplica directamente a su elemento secundario <img>.

No cargues de forma diferida las imágenes que se encuentran en el viewport inicial

Solo debes agregar el atributo loading="lazy" a los elementos <img> que se fuera del viewport inicial. Sin embargo, puede ser complejo conocer la posición precisa de un elemento en relación con el viewport, antes de que se cree la se renderizan. Los diferentes tamaños de viewport, relaciones de aspecto y dispositivos deben considerar.

Por ejemplo, un viewport de computadora de escritorio puede ser muy diferente de un viewport en una teléfono celular, ya que procesa más espacio vertical que podría ajustarse a las imágenes en el viewport inicial que no aparecen en el viewport inicial de un dispositivo físicamente más pequeño. También se muestran las tablets que se usan en orientación vertical una cantidad considerable de espacio vertical, quizás incluso más que el de algunas dispositivos.

Sin embargo, hay algunos casos en los que resulta bastante claro que debes evitar aplicando loading="lazy". Por ejemplo, definitivamente debes omitir el El atributo loading="lazy" de los elementos <img> en los casos de hero images y otros casos de uso de imágenes en los que es probable que los elementos <img> aparezcan encima del o cerca de la parte superior del diseño en cualquier dispositivo. Esto es aún más importante para imágenes que probablemente sean candidatas a LCP.

Las imágenes de carga diferida deben esperar a que el navegador finalice el diseño en para saber si la posición final de la imagen está dentro del viewport. Esto significa que, si un elemento <img> en el viewport visible tiene un valor loading="lazy" solo se solicita después de descargar, analizar y analizar todos los elementos CSS se aplican a la página, a diferencia de la recuperación apenas la descubren el escáner de precarga en el lenguaje de marcado sin procesar.

Dado que el atributo loading en el elemento <img> es compatible con todas las navegadores no es necesario usar JavaScript para cargar imágenes de forma diferida, ya que agregar JavaScript adicional a una página para proporcionar funciones que el navegador ya proporciona afecta otros aspectos del rendimiento de la página, como INP.

Demostración de carga diferida de imágenes

Carga diferida de elementos <iframe>

La carga diferida de los elementos <iframe> hasta que sean visibles en el viewport puede guardarse una cantidad significativa de datos y mejorar la carga de los recursos esenciales para que cargue la página de nivel superior. Además, debido a que los elementos <iframe> son en esencia, documentos HTML completos cargados en un documento de nivel superior, pueden incluyen una cantidad significativa de subrecursos, en especial JavaScript, que pueden afectar considerablemente el INP de una página si las tareas dentro de esos marcos requieren tiempo de procesamiento significativo.

Las incorporaciones de terceros son un caso de uso común para los elementos <iframe>. Por ejemplo: Los reproductores de video incorporados o las publicaciones en redes sociales suelen usar elementos <iframe>. y suelen requerir una cantidad significativa de subrecursos que también pueden causan una contención de ancho de banda para los recursos de la página de nivel superior. Como Por ejemplo, la carga diferida de un video de YouTube ahorra más de 500 KiB durante la carga inicial de la página y la carga diferida del complemento del botón Me gusta de Facebook ahorra más de 200 KiB, la mayoría de los cuales es JavaScript.

De cualquier manera, siempre que tengas una <iframe> en la mitad inferior de una página, deberías considere cargarla de forma diferida si no es fundamental, hacerlo puede mejorar significativamente la experiencia del usuario.

El atributo loading para elementos <iframe>

El atributo loading en los elementos <iframe> también es compatible con todas las principales navegadores. Los valores del atributo loading y sus comportamientos son los igual que con los elementos <img> que usan el atributo loading:

  • "eager" es el valor predeterminado. Le indica al navegador que cargue el <iframe>. el HTML del elemento y sus subrecursos de inmediato.
  • "lazy" aplaza la carga del código HTML del elemento <iframe> y sus subrecursos hasta que se encuentre dentro de una distancia predefinida desde el viewport.

Demostración de carga diferida de iframes

Fachadas

En lugar de cargar una incorporación de inmediato durante la carga de la página, puedes cargarla en demanda en respuesta a una interacción del usuario. Para ello, se muestra una imagen o algún otro elemento HTML apropiado hasta que el usuario interactúe con él. Una vez que usuario interactúa con el elemento, puedes reemplazarlo con la incorporación de terceros. Esta técnica se conoce como fachada.

Un caso de uso común para las fachadas son las incorporaciones de video desde servicios de terceros en los que la incorporación puede implicar la carga de muchos recursos adicionales como JavaScript, además del contenido de video en sí. De tal forma un caso, a menos que haya una necesidad legítima para que un video se reproduzca automáticamente, Se requiere que el usuario interactúe con ellos antes de la reproducción haciendo clic en el botón de reproducción .

Esta es una excelente oportunidad para mostrar una imagen estática visualmente similar a insertar el video y ahorrar un ancho de banda significativo en el proceso. Una vez que el usuario hace clic en la imagen, se reemplaza por la incorporación real de <iframe>, que Activa el código HTML del elemento <iframe> de terceros y sus subrecursos para comenzar descargas.

Además de mejorar la carga inicial de la página, otra ventaja clave es que si la El usuario nunca reproduce el video, los recursos necesarios para entregarlo nunca se descargado. Este es un buen patrón, ya que garantiza que el usuario solo descargue que en realidad quieren, sin hacer suposiciones erróneas sobre el las necesidades del usuario.

Los widgets de chat son otro excelente caso de uso para la técnica de fachada. Más probable los widgets de chat descargan cantidades significativas de JavaScript, que pueden afectar negativamente afectan la carga de la página y la capacidad de respuesta a las entradas del usuario. Como cuando se carga algo se genera un costo en el momento de la carga, pero en el caso de un widget de chat, no cada usuario nunca tiene la intención de interactuar con él.

Por otro lado, con una fachada, es posible reemplazar el nombre de dominio "Starter Chat" con uno falso. Una vez que el usuario interactúa de manera significativa con por ejemplo, sostener un puntero sobre ella durante un período razonable con un clic, el widget de chat real y funcional se ubica en su lugar cuando el usuario lo necesite.

Si bien es posible construir tus propias fachadas, hay otros tipos de fachadas opciones disponibles para terceros más populares, como lite-youtube-embed para videos de YouTube, lite-vimeo-embed para videos de Vimeo y Reactuar en el chat en vivo Cargador para los widgets de chat.

Carga diferida de bibliotecas de JavaScript

Si necesitas cargar de forma diferida elementos <video>, imágenes del elemento <video> poster, imágenes cargadas por la propiedad background-image del CSS, o bien otras imágenes elementos, puedes hacerlo con una solución de carga diferida basada en JavaScript, como lazysizes o yall.js, ya que la carga diferida de estos tipos de recursos no es un a nivel del navegador.

En particular, los elementos <video> de reproducción automática y bucle sin pista de audio son una alternativa mucho más eficiente que usar GIF animados, que pueden suele ser varias veces más grande que un recurso de video con formato visual equivalente calidad. Aun así, estos videos pueden ser significativos en términos de ancho de banda, por lo que su carga diferida es una optimización adicional para reducir el desperdicio de ancho de banda.

La mayoría de estas bibliotecas funcionan con la API de Intersection Observer. además de la API de Mutation Observer si el HTML de una página cambia después del carga inicial, para reconocer el momento en que un elemento ingresa al viewport del usuario. Si el botón sea visible, o se acerque a la viewport, entonces la biblioteca JavaScript reemplaza el atributo no estándar (a menudo, data-src o un atributo similar), con el atributo correcto, como src.

Supongamos que tienes un video que reemplaza un GIF animado, pero quieres cargarlo de forma diferida. con una solución de JavaScript. Esto es posible con yall.js de la siguiente manera: patrón de marcado:

<!-- The autoplay, loop, muted, and playsinline attributes are to
     ensure the video can autoplay without user intervention. -->
<video class="lazy" autoplay loop muted playsinline width="320" height="480">
  <source data-src="video.webm" type="video/webm">
  <source data-src="video.mp4" type="video/mp4">
</video>

De forma predeterminada, yall.js observa todos los elementos HTML calificados con una clase de "lazy" Una vez que yall.js se cargue y se ejecute en la página, el video no se hasta que el usuario se desplaza en el viewport. En ese momento, la data-src los atributos de los elementos secundarios <source> del elemento <video> se intercambian a los atributos src, que envía una solicitud para descargar el video y comenzar a reproducirlo automáticamente.

Ponga a prueba sus conocimientos

¿Cuál es el valor predeterminado del atributo loading para los elementos <img> y <iframe>?

"eager"
Correcto.
"lazy"
Vuelve a intentarlo.

¿Cuándo es razonable usar las soluciones de carga diferida basadas en JavaScript?

Para cualquier recurso que pueda ser de carga diferida.
Vuelve a intentarlo.
Para los recursos en los que el atributo loading no está como en el caso de los videos de reproducción automática destinados a reemplazar imágenes animadas o la carga diferida de los archivos <video> imagen de póster.
Correcto.

¿Cuándo es útil una fachada?

Para cualquier incorporación de terceros que consuma una cantidad significativa de datos, independientemente de las necesidades del usuario.
Vuelve a intentarlo.
Para las incorporaciones de terceros en las que no se deben cargar los recursos son sustanciales, pero hay una probabilidad aceptable de que no todos los usuarios pueden interactuar con ellos.
Correcto.

A continuación: Carga previa y renderización previa

Ahora que tienes un controlador para la carga diferida de imágenes y elementos <iframe>, está en una buena posición para garantizar que las páginas puedan cargarse más rápido, mientras respetando las necesidades de tus usuarios. Sin embargo, hay casos en los que la carga especulativa de recursos puede ser conveniente. En el próximo módulo, aprenderás sobre la carga previa y la renderización previa, y cómo estas técnicas, cuando se usan con cuidado, pueden acelerar sustancialmente las navegaciones a las páginas subsiguientes al cargar con anticipación.