En los últimos módulos, descubriste conceptos como diferir la
Carga de JavaScript y carga diferida de imágenes y elementos <iframe>
Posponer la carga de recursos reduce el uso de red y CPU durante la fase
para cargar la página, descargando los recursos en el momento en que se necesitan
en lugar de cargarlos por adelantado, en los que podrían no usarse.
Esto puede mejorar los tiempos de carga iniciales de la página, pero es posible que las interacciones posteriores
un retraso si los recursos necesarios para alimentarlos aún no están cargados en ese momento
ocurran.
Por ejemplo, si una página contiene un selector de fecha personalizado, puedes postergar la fecha los recursos del selector hasta que el usuario interactúe con el elemento. Sin embargo, cargar los recursos del selector de fecha a pedido pueden provocar una demora, quizás leve, pero según la conexión de red del usuario, las capacidades del dispositivo o ambos, hasta que los recursos se descarguen, analicen y estén disponibles para su ejecución.
Es un equilibrio un poco complicado. No es bueno desperdiciar ancho de banda cargando recursos que pueden no usarse, pero que retrasan las interacciones y de cargas de trabajo tampoco sean ideales. Por suerte, hay una serie de herramientas que puedes para lograr un mejor equilibrio entre estos dos extremos, y este módulo abarca algunas técnicas que puedes usar para llegar allí, como la carga previa de recursos, el procesamiento previo de páginas completas y el almacenamiento previo de recursos en caché con un service worker.
Precarga los recursos necesarios en un futuro cercano con baja prioridad.
Es posible recuperar recursos de manera preventiva, como imágenes, hojas de estilo
o recursos de JavaScript,
a través de la sugerencia del recurso <link rel="prefetch">. El
La sugerencia prefetch informa al navegador que es probable que se requiera un recurso en
en el futuro cercano.
Cuando se especifica una sugerencia prefetch, el navegador puede iniciar una solicitud
para ese recurso con la prioridad más baja para evitar competir con recursos
se necesitan para la página actual.
La precarga de recursos puede mejorar la experiencia del usuario, ya que este necesarios para esperar a que los recursos que se necesitan en un futuro cercano se descarguen, ya que se pueden recuperar al instante desde la caché del disco cuando sea necesario.
<head>
<!-- ... -->
<link rel="prefetch" as="script" href="/date-picker.js">
<link rel="prefetch" as="style" href="/date-picker.css">
<!-- ... -->
</head>
El fragmento HTML anterior informa al navegador que puede hacer una carga previa
date-picker.js y date-picker.css una vez que esté inactivo. También es posible
precarga recursos de manera dinámica cuando el usuario interactúa con la página en
JavaScript:
prefetch es compatible con todos los navegadores modernos, excepto Safari, donde
disponible detrás de una bandera. Si necesitas cargar de forma preventiva
recursos para tu sitio web de forma tal que funcione en todos los navegadores, y
un service worker; luego lee la sección posterior de este módulo sobre almacenamiento previo en caché
con un service worker.
Cargar páginas previamente para acelerar las navegaciones futuras
También es posible cargar previamente una página y todos sus subrecursos si especificas el
el atributo as="document" cuando apunta a un documento HTML:
<link rel="prefetch" href="/page" as="document">
Cuando el navegador está inactivo, es posible que inicie una solicitud de prioridad baja para /page.
En los navegadores basados en Chromium, puedes cargar documentos previamente con el API de Speculation Rules. Las reglas de especulación se definen como un objeto JSON se incluyen en el código HTML de la página o se agregan de forma dinámica mediante JavaScript:
<script type="speculationrules">
{
"prefetch": [{
"source": "list",
"urls": ["/page-a", "/page-b"]
}]
}
</script>
El objeto JSON describe una o más acciones que actualmente solo admiten
prefetch y prerender, y una lista de las URLs asociadas con esa acción. En
En el fragmento HTML anterior, se le indica al navegador que realice una carga previa de /page-a.
y /page-b. Al igual que <link rel="prefetch">, las reglas de especulación son un
que el navegador puede ignorar en ciertas circunstancias.
Las bibliotecas como Quicklink mejoran la navegación de las páginas gracias a que carga previa o renderización previa de vínculos a páginas una vez que están visibles en el viewport del usuario. Esto aumenta la probabilidad de que el usuario finalmente navega a esa página, en comparación con la carga previa de todos los vínculos de la página.
Páginas con renderización previa
Además de realizar una carga previa de los recursos, también es posible sugerirle al navegador. para renderizar previamente una página antes de que el usuario navegue a ella. Esto puede proporcionar casi carga instantánea de la página, a medida que la página y sus recursos se recuperan y procesan en segundo plano. Una vez que el usuario navega a la página, esta se ubica en el primer plano.
La renderización previa es compatible con la API de Speculation Rules:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["/page-a", "page-b"]
}
]
}
</script>
Demostración de carga previa y renderización previa
Almacenamiento previo en caché del service worker
También es posible precargar recursos de manera especulativa con un service worker.
El almacenamiento previo en caché del service worker puede recuperar y ahorrar recursos con la API de Cache.
lo que permite que el navegador entregue la solicitud usando la API de Cache sin acceder
la red. El almacenamiento previo en caché de service worker usa un service worker muy eficaz
de almacenamiento en caché, conocida como estrategia de solo caché. Este patrón es muy
Es muy eficaz porque, una vez que los recursos se colocan en la caché del service worker,
se recuperan casi al instante si se solicita.
Para almacenar en caché previamente los recursos con un service worker, puedes usar Workbox. Si pero prefieres, puedes escribir tu propio código para almacenar en caché un conjunto predeterminado de archivos. Cualquiera sea tu forma de usar un service worker para almacenar en caché por adelantado recursos, es importante saber que el almacenamiento previo en caché ocurre cuando el servicio Instalar el trabajador. Después de la instalación, se almacenan en caché los recursos disponibles para recuperarse en cualquier página que el service worker controle de tu sitio web.
Workbox usa un manifiesto de almacenamiento previo en caché para determinar qué recursos se deben se almacenan en caché previamente. Un manifiesto de almacenamiento previo en caché es una lista de información sobre el control de versiones y archivos que funcione como la "fuente de verdad" que los recursos se prealmacenan en caché.
[{
url: 'script.ffaa4455.js',
revision: null
}, {
url: '/index.html',
revision: '518747aa'
}]
El código anterior es un manifiesto de ejemplo que incluye dos archivos:
script.ffaa4455.js y /index.html. Si un recurso contiene una
en el mismo archivo (conocido como hash de archivo), luego el revision
se puede dejar como null, porque el archivo ya tiene control de versiones (por ejemplo,
ffaa4455 para el recurso script.ffaa4455.js en el código anterior). Para
recursos sin control de versiones, se puede generar una revisión para ellos en el momento de la compilación.
Una vez configurado, se puede usar un service worker para almacenar en caché previamente las páginas estáticas o subrecursos para acelerar las navegaciones posteriores de páginas.
workbox.precaching.precacheAndRoute([
'/styles/product-page.ac29.css',
'/styles/product-page.39a1.js',
]);
Por ejemplo, en una página de ficha de producto de comercio electrónico, se puede usar un service worker
para almacenar en caché previamente el CSS y JavaScript necesarios para renderizar la página de detalles del producto
lo que hace que la navegación a la página de detalles del producto parezca mucho más rápida. En la
ejemplo anterior, product-page.ac29.css y product-page.39a1.js son
se almacenan en caché previamente. El método precacheAndRoute disponible en workbox-precaching
registra automáticamente los controladores necesarios para garantizar que los recursos previamente almacenados en caché
se recuperan de la API del service worker cada vez que es necesario.
Debido a que los service workers son ampliamente compatibles, puedes utilizar service worker almacenamiento previo en caché en cualquier navegador moderno cuando la situación lo requiera.
Ponga a prueba sus conocimientos
¿Con qué prioridad se produce una sugerencia de prefetch?
¿Cuál es la diferencia entre la carga previa y la la renderización previa de una página?
La caché del service worker y la caché HTTP son iguales.
A continuación: Descripción general de los trabajadores web
Ahora que sabes cómo la carga previa, la renderización previa y el almacenamiento previo en caché del service worker puede ser beneficiosa cuando se trata de acelerar las navegaciones hacia futuras en las páginas de destino, puedes tomar decisiones informadas beneficiosos para tu sitio web y sus usuarios.
A continuación, se ofrece una descripción general de los trabajadores web y se indica cómo pueden demorar un poco más los costosos. trabajar a partir del subproceso principal y darle más espacio a este interacciones del usuario. Si alguna vez te preguntaste qué podrías hacer para otorgarle a la principal más espacio, entonces los próximos dos módulos valdrán el tiempo.