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 atributoloading
."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>
?
"lazy"
"eager"
¿Cuándo es razonable usar las soluciones de carga diferida basadas en JavaScript?
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.
¿Cuándo es útil una fachada?
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.