En los últimos módulos, descubriste conceptos como diferir la carga de JavaScript y carga diferida de imágenes y elementos <iframe>.
Diferir la carga de recursos disminuye el uso de red y CPU durante la carga inicial de la página, ya que se descargan los recursos en el momento en que se necesitan, en lugar de cargarlos por adelantado, donde es posible que no se usen.
Esto puede mejorar los tiempos de carga inicial de las páginas, pero las interacciones posteriores pueden generar un retraso si los recursos necesarios para activarlas aún no están cargados en el momento en que se producen.
Por ejemplo, si una página contiene un selector de fecha personalizado, puedes diferir los recursos del selector de fecha hasta que el usuario interactúe con el elemento. Sin embargo, la carga de los recursos del selector de fecha a pedido puede generar un retraso (tal vez un leve, pero quizás no, según la conexión de red del usuario, las capacidades del dispositivo o ambas) hasta que los recursos se descarguen, analicen y estén disponibles para la ejecución.
Es un poco complicado: no es bueno desperdiciar ancho de banda cargando recursos que pueden no usarse, pero retrasar las interacciones y las cargas de páginas posteriores puede no ser lo ideal. Afortunadamente, existen varias herramientas que puedes usar para lograr un mejor equilibrio entre estos dos extremos. En este módulo, se explican algunas técnicas que puedes usar para lograrlo, como la carga previa de recursos, el procesamiento previo de páginas completas y el almacenamiento previo en caché de recursos con un service worker.
Precarga los recursos necesarios en el futuro cercano con prioridad baja.
Es posible recuperar recursos de forma preventiva, como imágenes, hojas de estilo o recursos de JavaScript, con la sugerencia de recursos <link rel="prefetch">. La sugerencia prefetch informa al navegador que es probable que se necesite un recurso en un futuro cercano.
Cuando se especifica una sugerencia de prefetch, el navegador puede iniciar una solicitud para ese recurso con la prioridad más baja a fin de evitar tener que competir con los recursos necesarios para la página actual.
La carga previa de recursos puede mejorar la experiencia del usuario, ya que no es necesario que espere a que se descarguen los recursos necesarios en un futuro cercano, ya que se pueden recuperar de forma instantánea de la caché del disco en el momento en que se necesiten.
<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 cargar previamente date-picker.js y date-picker.css una vez que esté inactivo. También es posible precargar recursos de forma dinámica a medida que el usuario interactúa con la página en JavaScript.
prefetch es compatible con todos los navegadores modernos, excepto Safari, donde está disponible detrás de una marca. Si tienes una necesidad imperdible de cargar recursos para tu sitio web de forma preventiva de una manera que funcione en todos los navegadores (y usas un service worker), lee la sección posterior de este módulo sobre el almacenamiento previo de recursos en caché con un service worker.
Precarga páginas para acelerar futuras navegaciones
También es posible precargar una página y todos sus subrecursos si especificas el atributo as="document" cuando se 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 previamente documentos mediante la API de Speculation Rules. Las reglas de especulación se definen como un objeto JSON incluido en el código HTML de la página o que se agrega de forma dinámica a través de 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 URLs asociadas con esa acción. 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 una sugerencia que el navegador puede ignorar en ciertas circunstancias.
Las bibliotecas como Quicklink mejoran la navegación de páginas ya que precargan dinámicamente o renderizan previamente los vínculos a las páginas una vez que están visibles en el viewport del usuario. Esto aumenta la probabilidad de que el usuario navegue a esa página, en comparación con la carga previa de todos los vínculos de la página.
Renderizar páginas previamente
Además de cargar previamente los recursos, también es posible sugerirle al navegador que represente previamente una página antes de que el usuario navegue a ella. De esta manera, se pueden cargar páginas casi instantáneas, ya que la página y sus recursos se recuperan y procesan en segundo plano. Una vez que el usuario navegue a la página, esta se colocará en 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>
Demostraciones de carga previa y renderización previa
Almacenamiento previo en caché de service worker
También es posible precargar recursos de manera especulativa con un service worker.
El almacenamiento en caché previo de los service workers puede recuperar y guardar recursos con la API de Cache, lo que permite que el navegador entregue la solicitud con la API de Cache sin ir a la red. El almacenamiento previo en caché de service worker usa una estrategia de almacenamiento
en caché de service worker muy eficaz, conocida como la estrategia de solo caché. Este patrón es muy eficaz porque, una vez que los recursos se colocan en la caché del service worker, se recuperan casi al instante si se lo solicita.
Para almacenar previamente recursos en caché con un service worker, puedes usar Workbox. Sin embargo, si lo prefieres, puedes escribir tu propio código para almacenar en caché un conjunto de archivos predeterminado. Independientemente de la manera en que decidas usar un service worker para almacenar previamente recursos en caché, es importante que sepas que el almacenamiento previo en caché ocurre cuando se instala el service worker. Después de la instalación, los recursos prealmacenados en caché estarán disponibles para su recuperación en cualquier página que controle el service worker de tu sitio web.
Workbox usa un manifiesto de almacenamiento previo en caché para determinar qué recursos deben almacenarse en caché previamente. Un manifiesto de precaché es una lista de archivos y de información sobre el control de versiones que sirve como “fuente de información” para que los recursos se almacenen en caché previamente.
[{
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 información de versión en el archivo (conocido como hash de archivo), la propiedad revision puede dejarse como null, debido a que el archivo ya tiene control de versiones (por ejemplo, ffaa4455 para el recurso script.ffaa4455.js en el código anterior). En el caso de los recursos sin versiones, se puede generar una revisión en el momento de la compilación.
Una vez configurado, se puede usar un service worker para almacenar en caché las páginas estáticas o sus subrecursos a fin de acelerar la navegación posterior de las 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 por esta página parezca mucho más rápida. En el ejemplo anterior, product-page.ac29.css y product-page.39a1.js se almacenan previamente en caché. El método precacheAndRoute disponible en workbox-precaching
registra automáticamente los controladores necesarios para garantizar que los recursos almacenados previamente
en caché se recuperen de la API del service worker cuando es necesario.
Dado que los service workers tienen una amplia compatibilidad, puedes usar el almacenamiento en caché de service worker en cualquier navegador moderno que la situación lo requiera.
Pon a prueba tus conocimientos
¿Con qué prioridad se muestra una sugerencia de prefetch?
¿Cuál es la diferencia entre la carga previa y el procesamiento previo de una página?
La caché del service worker y la caché de HTTP son las mismas.
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é de los service workers pueden ser beneficiosos cuando se trata de acelerar la navegación a páginas futuras, estás en posición de tomar algunas decisiones fundamentadas sobre cómo esto puede beneficiar a tu sitio web y a su usuario.
A continuación, se proporciona una descripción general de los trabajadores web y cómo pueden quitar el trabajo costoso del subproceso principal y darle más espacio a las interacciones del usuario. Si alguna vez te preguntaste qué puedes hacer para darle más espacio al subproceso principal, vale la pena que te tomes los siguientes dos módulos.