Carga previa, renderización previa y almacenamiento en caché de service worker

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.

Muestra el flujo de almacenamiento en caché del service worker desde la página hasta el service worker y la caché.
La estrategia de solo caché solo recupera los recursos aptos del durante la instalación del service worker. Una vez instalada, el almacenamiento los recursos solo se recuperan de la caché del service worker.

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?

tan llevaderos
Alto.
Medium.

¿Cuál es la diferencia entre la carga previa y la la renderización previa de una página?

En general son iguales, solo una renderización previa obtiene subrecursos, mientras que una carga previa no.
Si bien tanto la carga previa como la renderización previa de una página obtienen sus subrecursos, una carga previa solo recupera la página y todos sus recursos, mientras que una renderización previa va un paso más allá toda la página en segundo plano hasta que el usuario navegue hacia ella.

La caché del service worker y la caché HTTP son iguales.

Falso
Verdadero

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.