Renderiza previamente las páginas en Chrome para navegarlas de forma instantánea

Barry Pollard

Navegadores compatibles

  • Chrome: 109.
  • Edge: 109.
  • Firefox: No es compatible.
  • Safari: No se admite.

El equipo de Chrome volvió a renderizar por completo las páginas futuras a las que es probable que navegue un usuario.

Breve historia del renderización previa

En el pasado, Chrome admitía la sugerencia de recursos <link rel="prerender" href="/next-page">. Sin embargo, no era ampliamente compatible fuera de Chrome y no era una API muy expresiva.

Esta renderización previa heredada con la sugerencia de vínculo rel=prerender dejó de estar disponible a favor de la carga previa sin estado, que recuperaba los recursos que necesitaba la página futura, pero no renderizaba la página por completo ni ejecutaba JavaScript. La carga previa sin estado ayuda a mejorar el rendimiento de la página, ya que mejora la carga de recursos, pero no proporciona una carga de página instantánea como lo haría una renderización previa completa.

El equipo de Chrome volvió a implementar la renderización previa completa en Chrome. Para evitar complicaciones con el uso existente y permitir la expansión futura de la renderización previa, este nuevo mecanismo de renderización previa no usará la sintaxis <link rel="prerender"...>, que permanecerá en su lugar para la precarga sin estado, con la intención de retirarla en algún momento en el futuro.

¿Cómo se renderiza previamente una página?

Una página se puede renderizar previamente de una de las siguientes cuatro maneras, todas las cuales tienen como objetivo hacer que las navegaciones sean más rápidas:

  1. Cuando escribes una URL en la barra de direcciones de Chrome (también conocida como "cuadro multifunción"), Chrome puede preprocesar automáticamente la página por ti, en función de tu historial de navegación anterior, en caso de que tenga un alto nivel de confianza con que la visites.
  2. Cuando usas la barra de favoritos, Chrome puede preprocesar automáticamente la página si mantienes el puntero sobre uno de los botones de favoritos.
  3. Cuando escribes un término de búsqueda en la barra de direcciones de Chrome, Chrome puede preprocesar automáticamente la página de resultados de búsqueda cuando el motor de búsqueda lo solicita.
  4. Los sitios pueden usar la API de Speculation Rules para indicarle a Chrome de forma programática qué páginas renderizar previamente. Esto reemplaza lo que solía hacer <link rel="prerender"...> y permite que los sitios rendericen de forma previa una página de forma proactiva en función de las reglas de especulación en la página. Pueden existir de forma estática en las páginas o inyectarse de forma dinámica con JavaScript según lo considere conveniente el propietario de la página.

En cada uno de estos casos, una renderización previa se comporta como si la página se hubiera abierto en una pestaña invisible en segundo plano y, luego, se "activa" reemplazando la pestaña en primer plano por esa página renderizada previamente. Si una página se activa antes de que se renderice por completo, su estado actual se "pone en primer plano" y sigue cargándose, lo que significa que aún puedes obtener una buena ventaja.

Como la página renderizada previamente se abre en un estado oculto, una serie de APIs que causan comportamientos intrusivos (por ejemplo, instrucciones) no se activan en este estado y, en su lugar, se retrasan hasta que se activa la página. En la pequeña cantidad de casos en los que esto aún no es posible, se cancela la renderización previa. El equipo de Chrome está trabajando para exponer los motivos de cancelación de la renderización previa como una API y también para mejorar las capacidades de DevTools para facilitar la identificación de esos casos extremos.

Impacto de la renderización previa

La renderización previa permite una carga de página casi instantánea, como se muestra en el siguiente video:

Ejemplo del impacto de la renderización previa.

El sitio de ejemplo ya es rápido, pero incluso así puedes ver cómo la renderización previa mejora la experiencia del usuario. Por lo tanto, esto también puede tener un impacto directo en las Métricas web esenciales de un sitio, con un LCP casi nulo, un CLS reducido (ya que cualquier CLS de carga ocurre antes de la vista inicial) y un INP mejorado (ya que la carga debe completarse antes de que el usuario interactúe).

Incluso cuando una página se activa antes de que se cargue por completo, tener una ventaja inicial en la carga debería mejorar la experiencia de carga. Si se activa un vínculo mientras la renderización previa aún está en curso, la página de renderización previa se moverá al marco principal y continuará cargándose.

Sin embargo, la renderización previa usa memoria y ancho de banda de red adicionales. Ten cuidado de no realizar una renderización previa excesiva, ya que esto puede afectar los recursos del usuario. Solo realiza la renderización previa cuando haya una alta probabilidad de que se navegue a la página.

Consulta la sección Medición del rendimiento para obtener más información sobre cómo medir el impacto real en el rendimiento en tus estadísticas.

Cómo ver las predicciones de la barra de direcciones de Chrome

En el primer caso de uso, puedes ver las predicciones de Chrome para las URLs en la página chrome://predictors:

La página de Predictors de Chrome se filtró para mostrar predicciones bajas (gris), medias (ámbar) y altas (verde) según el texto ingresado.
Página de predictores de Chrome.

Las líneas verdes indican que hay suficiente confianza para activar la renderización previa. En este ejemplo, escribir "s" proporciona una confianza razonable (ámbar), pero una vez que escribes "sh", Chrome tiene suficiente confianza como para saber que casi siempre navegas a https://sheets.google.com.

Esta captura de pantalla se tomó en una instalación de Chrome relativamente reciente y se filtraron las predicciones de confianza cero, pero si ves tus propios predictores, es probable que veas muchas más entradas y, posiblemente, más caracteres necesarios para alcanzar un nivel de confianza lo suficientemente alto.

Estos predictores también son los que generan las opciones sugeridas de la barra de direcciones que quizás hayas notado:

La función &quot;Typeahead&quot; de la barra de direcciones de Chrome
Función "Typeahead" de la barra de direcciones.

Chrome actualizará continuamente sus predictores según lo que escribas y selecciones.

  • Si el nivel de confianza es superior al 50% (se muestra en ámbar), Chrome se conecta de forma anticipada al dominio de forma proactiva, pero no renderiza la página de forma anticipada.
  • Si el nivel de confianza es superior al 80% (se muestra en verde), Chrome renderizará previamente la URL.

La API de Speculation Rules

En el caso de la opción de renderización previa de la API de Speculation Rules, los desarrolladores web pueden insertar instrucciones JSON en sus páginas para informar al navegador sobre qué URLs renderizar previamente:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

O bien por reglas de documentos (disponibles a partir de Chrome 121), que renderizan previamente los vínculos que se encuentran en el documento según los selectores href (basados en la API de patrones de URL) o los selectores CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

El equipo de Chrome preparó un codelab de Speculation Rules en el que se explica cómo agregar Speculation Rules a un sitio.

Impulso

Navegadores compatibles

  • Chrome: 121.
  • Edge: 121.
  • Firefox: No es compatible.
  • Safari: No se admite.

Se usa una configuración eagerness para indicar cuándo deben activarse las especulaciones, lo que es particularmente útil para las reglas de documentos:

  • immediate: Se usa para especular lo antes posible, es decir, ni bien se observan las reglas de especulación.
  • eager: Su comportamiento es idéntico al del parámetro de configuración immediate, pero queremos ubicarlo en algún lugar entre immediate y moderate más adelante.
  • moderate: Este parámetro realiza especulaciones si mantienes el puntero sobre un vínculo durante 200 milisegundos (o en el evento pointerdown, si ocurre antes, y en dispositivos móviles, donde no hay un evento hover).
  • conservative: Especula sobre el puntero o el touchdown.

El eagerness predeterminado para las reglas list es immediate. Las opciones moderate y conservative se pueden usar para limitar las reglas list a las URLs con las que un usuario interactúa en una lista específica. Sin embargo, en muchos casos, las reglas document con una condición where adecuada pueden ser más apropiadas.

El eagerness predeterminado para las reglas document es conservative. Dado que un documento puede constar de muchas URLs, el uso de immediate o eager para las reglas document debe usarse con precaución (consulta también la sección Límites de Chrome a continuación).

La configuración de eagerness que se use depende de tu sitio. En el caso de un sitio estático y ligero, especular con más entusiasmo puede tener un costo bajo y ser beneficioso para los usuarios. Es posible que los sitios con arquitecturas más complejas y cargas útiles de páginas más pesadas prefieran reducir el desperdicio especulando con menos frecuencia hasta que obtengan indicadores más positivos de la intención de los usuarios para limitar el desperdicio.

La opción moderate es un punto intermedio, y muchos sitios podrían beneficiarse de la siguiente regla de especulación que renderizaría previamente un vínculo al mantener el puntero sobre el vínculo durante 200 milisegundos o en el evento Pointdown como una implementación básica y, pero potente, de reglas de especulación:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Recuperación previa

Las reglas de especulación también se pueden usar para recuperar páginas de antemano, sin una renderización previa completa. A menudo, este puede ser un buen primer paso en el camino hacia la renderización previa:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Límites de Chrome

Chrome tiene límites para evitar el uso excesivo de la API de Speculation Rules:

afán Recuperación previa Renderización previa
immediate/eager 50 10
moderate/conservative 2 (FIFO) 2 (FIFO)
Límites de especulación en Chrome

La configuración de moderate y conservative, que depende de la interacción del usuario, funciona de manera primero en entrar, primero en salir (FIFO): después de alcanzar el límite, una nueva especulación hará que se cancele la especulación más antigua y se reemplace por la más reciente para conservar la memoria. Una especulación cancelada se puede activar de nuevo (por ejemplo, si se coloca el cursor sobre ese vínculo nuevamente), lo que provocará que se vuelva a especular esa URL, lo que provocará la especulación más antigua. En este caso, la especulación anterior habrá almacenado en caché cualquier recurso almacenable en la caché HTTP de esa URL, por lo que especular una vez más debería tener un costo reducido. Por este motivo, el límite se establece en el umbral modesto de 2. Las reglas de lista estáticas no se activan con una acción del usuario y, por lo tanto, tienen un límite más alto, ya que el navegador no puede saber cuáles son necesarias y cuándo.

Los límites de immediate y eager también son dinámicos, por lo que quitar un elemento de secuencia de comandos de URL list creará capacidad, ya que cancelará esas especulaciones quitadas.

Chrome también evitará que se usen especulaciones en ciertas condiciones, como las siguientes:

  • Ahorro de datos.
  • Ahorro de energía cuando está habilitado y la batería está baja.
  • Restricciones de memoria.
  • Cuando el parámetro de configuración "Cargar páginas previamente" está desactivado (que también se desactiva de forma explícita con extensiones de Chrome, como uBlock Origin).
  • Páginas abiertas en pestañas en segundo plano

Chrome tampoco renderizará iframes de origen cruzado en páginas renderizadas previamente hasta la activación.

El objetivo de todas estas condiciones es reducir el impacto de la especulación excesiva cuando sea perjudicial para los usuarios.

Cómo incluir reglas de especulación en una página

Las reglas de especulación se pueden incluir de forma estática en el código HTML de la página o insertarse de forma dinámica en la página con JavaScript:

  • Reglas de especulación incluidas de forma estática: Por ejemplo, un sitio de noticias o un blog puede renderizar previamente el artículo más reciente, si ese es el siguiente vínculo que suele visitar una gran proporción de usuarios. Como alternativa, se pueden usar reglas de documentos con un moderate o conservative para especular a medida que los usuarios interactúan con los vínculos.
  • Reglas de especulación insertadas de forma dinámica: Pueden basarse en la lógica de la aplicación, personalizarse para el usuario o basarse en otras heurísticas.

Se recomienda que quienes prefieran la inserción dinámica basada en acciones como colocar el cursor sobre un vínculo o hacer clic en él (como lo hicieron muchas bibliotecas en el pasado con <link rel=prefetch>) revisen las reglas de documentos, ya que permiten que el navegador controle muchos de tus casos de uso.

Las reglas de especulación se pueden agregar en <head> o <body> del marco principal. No se aplican las reglas de especulación en los submarcos, y las reglas de especulación en las páginas renderizadas previamente solo se aplican una vez que se activa esa página.

El encabezado HTTP Speculation-Rules

Navegadores compatibles

  • Chrome: 121
  • Edge: 121.
  • Firefox: No es compatible.
  • Safari: no es compatible.

Origen

Las reglas de especulación también se pueden entregar mediante un encabezado HTTP Speculation-Rules, en lugar de incluirlas directamente en el código HTML del documento. Esto facilita la implementación de las CDN sin la necesidad de alterar el contenido de los documentos.

El encabezado HTTP Speculation-Rules se muestra con el documento y apunta a la ubicación de un archivo JSON que contiene las reglas de especulación:

Speculation-Rules: "/speculationrules.json"

Este recurso debe usar el tipo de MIME correcto y, si es un recurso de varios orígenes, debe pasar una verificación de CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Si deseas usar URLs relativas, te recomendamos que incluyas la clave "relative_to": "document" en tus reglas de especulación. De lo contrario, las URLs relativas serán relativas a la URL del archivo JSON de las reglas de especulación. Esto puede ser especialmente útil si necesitas seleccionar algunos o todos los vínculos del mismo origen.

Reglas de especulación y SPA

Las reglas de especulación solo son compatibles con las navegaciones de página completa que administra el navegador, no con las apps de una sola página (SPA) ni con las páginas de shell de la app. Esta arquitectura no usa recuperaciones de documentos, sino que realiza recuperaciones parciales o de API de datos o páginas, que luego se procesan y presentan en la página actual. La app puede recuperar previamente los datos necesarios para estas llamadas "navegaciones suaves" fuera de las reglas de especulación, pero no se pueden renderizar previamente.

Las reglas de especulación se pueden usar para renderizar previamente la aplicación en sí desde una página anterior. Esto puede ayudar a compensar algunos de los costos adicionales de carga inicial que tienen algunos SPA. Sin embargo, los cambios de ruta dentro de la app no se pueden renderizar previamente.

Cómo depurar reglas de especulación

Consulta la entrada dedicada a las reglas de especulación de depuración para conocer las nuevas funciones de Chrome DevTools que te ayudarán a ver y depurar esta nueva API.

Varias reglas de especulación

También se pueden agregar varias reglas de especulación a la misma página y se agregan a las reglas existentes. Por lo tanto, las siguientes formas diferentes generan una renderización previa de one.html y two.html:

Lista de URLs:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

Varias secuencias de comandos speculationrules:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Varias listas dentro de un conjunto de speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Navegadores compatibles

  • Chrome: 121.
  • Edge: 121
  • Firefox: No es compatible.
  • Safari: No se admite.

Origen

Cuando se realiza la precarga o la renderización previa de una página, es posible que ciertos parámetros de URL (conocidos técnicamente como parámetros de búsqueda) no sean importantes para la página que entrega el servidor y que solo los use JavaScript del cliente.

Por ejemplo, Google Analytics usa los parámetros UTM para la medición de campañas, pero, por lo general, no genera que se publiquen páginas diferentes desde el servidor. Esto significa que page1.html?utm_content=123 y page1.html?utm_content=456 entregarán la misma página desde el servidor, de modo que se pueda volver a usar la misma página desde la caché.

Del mismo modo, las aplicaciones pueden usar otros parámetros de URL que solo se controlan del lado del cliente.

La propuesta de No-Vary-Search permite que un servidor especifique parámetros que no generen una diferencia en el recurso entregado y, por lo tanto, permita que un navegador vuelva a usar versiones almacenadas en caché de un documento que solo difieran en estos parámetros. Esto es compatible con Chrome (y navegadores basados en Chromium) para las especulaciones de navegación de precarga (aunque estamos buscando también admitir esto para la renderización previa).

Las reglas de especulación admiten el uso de expects_no_vary_search para indicar dónde se espera que se muestre un encabezado HTTP No-Vary-Search. Esto puede ayudar a evitar descargas innecesarias.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

En este ejemplo, el código HTML de la página inicial /products es el mismo para los IDs de producto 123 y 124. Sin embargo, el contenido de la página finalmente difiere en función de la renderización del cliente con JavaScript para recuperar datos de productos a través del parámetro de búsqueda id. Por lo tanto, precargamos esa URL con entusiasmo y debería mostrar un encabezado HTTP No-Vary-Search que muestre que la página se puede usar para cualquier parámetro de búsqueda id.

Sin embargo, si el usuario hace clic en cualquiera de los vínculos antes de que se complete la carga previa, es posible que el navegador no haya recibido la página /products. En este caso, el navegador no sabe si contendrá el encabezado HTTP No-Vary-Search. Luego, el navegador puede elegir entre recuperar el vínculo nuevamente o esperar a que se complete la carga previa para ver si contiene un encabezado HTTP No-Vary-Search. La configuración de expects_no_vary_search permite que el navegador sepa que se espera que la respuesta de la página contenga un encabezado HTTP No-Vary-Search y que espere a que se complete esa carga previa.

Restricciones de las reglas de especulación y mejoras futuras

Las reglas de especulación se limitan a las páginas que se abren en la misma pestaña, pero estamos trabajando para reducir esa restricción.

De forma predeterminada, las especulaciones se restringen a las páginas del mismo origen. Especulación de páginas del mismo sitio de origen cruzado (por ejemplo, https://a.example.com podría renderizar previamente una página en https://b.example.com). Para usar esta función, la página especulada (https://b.example.com en este ejemplo) debe habilitarla mediante la inclusión de un encabezado HTTP Supports-Loading-Mode: credentialed-prerender, o Chrome cancelará la especulación.

Es posible que las versiones futuras también permitan la renderización previa para páginas de origen cruzado que no sean del mismo sitio, siempre y cuando no existan cookies para la página renderizada previamente y esta se habilite con un encabezado HTTP Supports-Loading-Mode: uncredentialed-prerender similar.

Las reglas de especulación ya admiten cargas previas de origen cruzado, pero solo cuando no existen cookies para el dominio de origen cruzado. Si existen cookies del usuario que visitó ese sitio anteriormente, no se activará la especulación y se mostrará un error en DevTools.

Teniendo en cuenta esas limitaciones actuales, un patrón que puede mejorar la experiencia de los usuarios en los vínculos internos y externos, siempre que sea posible, es renderizar previamente las URLs del mismo origen y tratar de recuperar previamente las URLs de origen cruzado:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/*" },
        "eagerness": "moderate"
      }
    ],
    "prefetch": [
      {
        "where": { "not": { "href_matches": "/*" } },
        "eagerness": "moderate"
      }
    ]
  }
</script>

La restricción para evitar especulaciones de origen cruzado para vínculos de origen cruzado de forma predeterminada es necesaria para la seguridad. Es una mejora en comparación con <link rel="prefetch"> para destinos de origen cruzado que tampoco enviarán cookies, pero aún intentarán la carga previa, lo que dará como resultado una carga previa desperdiciada que se debe volver a enviar o, lo que es peor, una carga incorrecta de la página.

No se admiten las reglas de especulación para la carga previa de páginas controladas por service workers. Estamos trabajando para agregar esta compatibilidad. Sigue este problema de trabajador del servicio de asistencia para obtener actualizaciones. La renderización previa es compatible con las páginas controladas por el trabajador del servicio.

Detectar compatibilidad con la API de Speculation Rules

Puedes detectar la compatibilidad con la API de Speculation Rules con verificaciones HTML estándar:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Agrega reglas de especulación de forma dinámica a través de JavaScript

Este es un ejemplo de cómo agregar una regla de especulación prerender con JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Puedes ver una demostración de la renderización previa de la API de Speculation Rules, con la inserción de JavaScript, en esta página de demostración de renderización previa.

Si insertas un elemento <script type = "speculationrules"> directamente en el DOM con innerHTML, no se registrarán las reglas de especulación por motivos de seguridad, y se deben agregar como se muestra anteriormente. Sin embargo, el contenido insertado de forma dinámica con innerHTML que contiene vínculos nuevos se detectará con las reglas existentes en la página.

De manera similar, la edición directa del panel Elements en las Herramientas para desarrolladores de Chrome para agregar el elemento <script type = "speculationrules"> no registra las reglas de especulación, sino que la secuencia de comandos para agregarla dinámicamente al DOM debe ejecutarse desde la consola para insertar las reglas.

Agrega reglas de especulación a través de un administrador de etiquetas

Para agregar reglas de especulación con un administrador de etiquetas como Google Tag Manager (GTM), es necesario que se inserten a través de JavaScript, en lugar de agregar el elemento <script type = "speculationrules"> directamente a través de GTM por los mismos motivos que se mencionaron anteriormente:

Configuración de la etiqueta HTML personalizada en Google Tag Manager
Agregar reglas de especulación a través de Google Tag Manager.

Ten en cuenta que este ejemplo usa var, ya que GTM no admite const.

Cancela las reglas de especulación

Si quitas las reglas de especulación, se cancelará la renderización previa, pero, para el momento en que esto suceda, es probable que los recursos ya se hayan gastado para iniciar la renderización previa, por lo que se recomienda no realizarla si hay alguna probabilidad de que se deba cancelar.

Reglas de especulación y política de seguridad del contenido

Como las reglas de especulación usan un elemento <script>, aunque solo contengan JSON, deben incluirse en la Content-Security-Policy script-src si el sitio la usa, ya sea con un hash o un nonce.

Se puede agregar una nueva inline-speculation-rules a script-src, lo que permite admitir elementos <script type="speculationrules"> insertados desde secuencias de comandos de hash o nonce. No admite reglas incluidas en el HTML inicial, por lo que JavaScript debe insertar reglas para los sitios que usan un CSP estricto.

Cómo detectar y, luego, inhabilitar la renderización previa

Por lo general, la renderización previa es una experiencia positiva para los usuarios, ya que permite una renderización de páginas rápida, a menudo instantánea. Esto beneficia tanto al usuario como al propietario del sitio, ya que las páginas renderizadas previamente permiten una mejor experiencia del usuario que podría ser difícil de lograr de otra manera.

Sin embargo, puede haber casos en los que no quieras que se realice la renderización previa de las páginas, por ejemplo, cuando las páginas cambian de estado, ya sea en función de la solicitud inicial o de la ejecución de JavaScript en la página.

Habilita y desactiva la renderización previa en Chrome

La renderización previa solo está habilitada para los usuarios de Chrome con el parámetro de configuración "Precargar páginas" en chrome://settings/performance/. Además, la renderización previa también está inhabilitada en dispositivos con poca memoria o si el sistema operativo está en los modos de Ahorro de datos o Ahorro de energía. Consulta la sección Límites de Chrome.

Cómo detectar y, luego, inhabilitar la renderización previa del servidor

Las páginas renderizadas previamente se enviarán con el encabezado HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

Las páginas que se precargaron con la API de Speculation Rules tendrán este encabezado configurado solo en prefetch:

Sec-Purpose: prefetch

Los servidores pueden responder en función de este encabezado para registrar solicitudes de especulación, mostrar contenido diferente o evitar que se produzca una renderización previa. Si se muestra un código de respuesta final que no es correcto (es decir, no está en el rango de 200 a 299 después de los redireccionamientos), la página no se renderizará previamente y se descartará cualquier página de precarga. Ten en cuenta también que las respuestas 204 y 205 no son válidas para la renderización previa, pero sí para la carga previa.

Si no quieres que una página específica se renderice previamente, mostrar un código de respuesta que no sea 2XX (como el 503) es la mejor manera de asegurarte de que no suceda. Sin embargo, para ofrecer la mejor experiencia, se recomienda permitir la renderización previa, pero retrasar las acciones que solo deben ocurrir cuando se ve la página, con JavaScript.

Detecta la renderización previa en JavaScript

La API de document.prerendering mostrará true mientras se renderiza previamente la página. Las páginas pueden usar esta función para evitar o retrasar ciertas actividades durante la renderización previa hasta que la página se active.

Una vez que se active un documento renderizado previamente, el activationStart de PerformanceNavigationTiming también se establecerá en un tiempo distinto de cero que representará el tiempo entre el inicio de la renderización previa y el momento en que se activó el documento.

Puedes tener una función para verificar si hay páginas renderizadas previamente y renderizadas, como la siguiente:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

La forma más fácil de ver si una página se renderizó previamente (ya sea de forma total o parcial) es abrir las Herramientas para desarrolladores después de activar la página y escribir performance.getEntriesByType('navigation')[0].activationStart en la consola. Si se muestra un valor distinto de cero, sabrás que la página se renderizó previamente:

La consola de Chrome DevTools muestra un valor positivo de activationStart que indica que la página se renderizó previamente.
Prueba la renderización previa en la consola.

Cuando el usuario que ve la página la active, se enviará el evento prerenderingchange en document, que se puede usar para habilitar actividades que, anteriormente, se iniciaban de forma predeterminada cuando se cargaba la página, pero que deseas retrasar hasta que el usuario realmente vea la página.

Con estas APIs, el código JavaScript del frontend puede detectar y actuar sobre las páginas renderizadas previamente de forma adecuada.

Impacto en las estadísticas

Analytics se usa para medir el uso del sitio web; por ejemplo, con Google Analytics para medir las vistas de páginas y los eventos. También puedes medir las métricas de rendimiento de las páginas con la supervisión de usuarios reales (RUM).

Las páginas solo se deben renderizar previamente cuando haya una alta probabilidad de que el usuario cargue la página. Por este motivo, las opciones de renderización previa de la barra de direcciones de Chrome solo se aplican cuando hay una probabilidad tan alta (más del 80% de las veces).

Sin embargo, en particular cuando se usa la API de Speculation Rules, las páginas renderizadas previamente pueden tener un impacto en las estadísticas y es posible que los propietarios de los sitios deban agregar código adicional para habilitar solo las estadísticas de las páginas que se renderizan previamente durante la activación, ya que no todos los proveedores de estadísticas pueden hacerlo de forma predeterminada.

Para ello, puedes usar un Promise que espera el evento prerenderingchange si se está renderizando un documento previamente o se resuelve de inmediato si se está realizando la siguiente acción:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Un enfoque alternativo es retrasar las actividades analíticas hasta que la página se haga visible por primera vez, lo que abarcaría el caso de la renderización previa y también cuando se abren pestañas en segundo plano (por ejemplo, con el clic derecho y abrir en una pestaña nueva):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Si bien esto puede tener sentido para las estadísticas y casos de uso similares, en otros casos, es posible que desees que se cargue más contenido para esos casos, por lo que te recomendamos que uses document.prerendering y prerenderingchange para segmentar específicamente las páginas de renderización previa.

Retener otro contenido durante la renderización previa

Se pueden usar las mismas APIs que se analizaron anteriormente para retener otro contenido durante la fase de renderización previa. Pueden ser partes específicas de JavaScript o elementos completos de la secuencia de comandos que prefieras no ejecutar durante la etapa de renderización previa.

Por ejemplo, con esta secuencia de comandos:

<script src="https://example.com/app/script.js" async></script>

Puedes cambiar esto a un elemento de secuencia de comandos insertado de forma dinámica que solo se inserta en función de la función whenActivated anterior:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Esto puede ser útil para retener secuencias de comandos distintas que incluyen estadísticas o renderizar contenido en función del estado o de otras variables que pueden cambiar durante el período de una visita. Por ejemplo, las recomendaciones, el estado de acceso o los íconos de carrito de compras podrían retenerse para garantizar que se presente la información más actualizada.

Si bien es más probable que esto suceda con el uso de la renderización previa, estas condiciones también son verdaderas para las páginas cargadas en las pestañas en segundo plano mencionadas anteriormente (por lo que se podría usar la función whenFirstVisible en lugar de whenActivated).

En muchos casos, lo ideal es que el estado también se verifique en los cambios generales de visibilitychange; por ejemplo, cuando se vuelve a una página que estaba en segundo plano, los contadores de la canasta de compras deben actualizarse con la cantidad más reciente de artículos en la canasta. Por lo tanto, este no es un problema específico de la renderización previa, sino que la renderización previa solo hace que un problema existente sea más evidente.

Una forma en que Chrome mitiga la necesidad de unir manualmente secuencias de comandos o funciones es que ciertas APIs se retienen, como se mencionó anteriormente, y tampoco se renderizan los iframes de terceros, por lo que solo el contenido adicional es el que se debe retener de forma manual.

Cómo medir el rendimiento

Para medir las métricas de rendimiento, los análisis deben considerar si es mejor medirlas en función del tiempo de activación en lugar del tiempo de carga de la página que informarán las APIs del navegador.

En el caso de las Métricas web esenciales, que mide Chrome a través del Informe sobre la experiencia del usuario en Chrome, estos datos están destinados a medir la experiencia del usuario. Por lo tanto, se miden en función del tiempo de activación. Esto suele generar una LCP de 0 segundos, lo que demuestra que esta es una excelente manera de mejorar tus Métricas web esenciales.

A partir de la versión 3.1.0, la biblioteca web-vitals se actualizó para controlar las navegaciones renderizadas previamente de la misma manera que Chrome mide las métricas principales de la Web. Esta versión también marca las navegaciones renderizadas previamente para esas métricas en el atributo Metric.navigationType si la página se renderizó de forma parcial o total.

Mide las renderizaciones previas

Si una página está renderizada previamente, se puede ver con una entrada activationStart de PerformanceNavigationTiming distinta de cero. Esto se puede registrar con una dimensión personalizada o algo similar cuando se registran las vistas de página, por ejemplo, con la función pagePrerendered que se describió anteriormente:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Esto permitirá que tus estadísticas muestren cuántas navegaciones se renderizan previamente en comparación con otros tipos de navegación y también te permitirá correlacionar cualquier métrica de rendimiento o métrica empresarial con estos diferentes tipos de navegación. Las páginas más rápidas generan más satisfacción entre los usuarios, lo que, a menudo, puede tener un impacto real en las medidas comerciales, como muestran nuestros casos de éxito.

A medida que midas el impacto comercial de la renderización previa de páginas para navegaciones instantáneas, podrás decidir si vale la pena invertir más esfuerzo en usar esta tecnología para permitir que se rendericen previamente más navegaciones o investigar por qué no se renderizan previamente las páginas.

Cómo medir las tasas de aciertos

Además de medir el impacto de las páginas que se visitan después de una renderización previa, es importante medir las páginas con renderización previa y no visitadas posteriormente. Esto podría implicar que estás realizando la renderización previa en exceso y que estás agotando recursos valiosos del usuario con poco beneficio.

Para medir esto, se puede activar un evento de Analytics cuando se insertan reglas de especulación (después de verificar que el navegador admita la renderización previa con HTMLScriptElement.supports('speculationrules')) para indicar que se solicitó la renderización previa. Ten en cuenta que el solo hecho de que se haya solicitado una renderización previa no indica que se haya iniciado o completado una renderización previa, como se indicó anteriormente, una renderización previa es una sugerencia para el navegador, y es posible que decida no renderizar previamente páginas en la configuración del usuario, el uso actual de la memoria ni otras heurísticas.

Luego, puedes comparar la cantidad de estos eventos con las vistas de página de renderización previa reales. Como alternativa, activa otro evento en la activación si eso facilita la comparación.

Luego, se puede aproximar el "porcentaje de hits correctos" observando la diferencia entre estas dos cifras. En el caso de las páginas en las que usas la API de Speculation Rules para renderizarlas previamente, puedes ajustar las reglas de manera adecuada para asegurarte de mantener una tasa de hits alta y mantener el equilibrio entre usar los recursos de los usuarios para ayudarlos y usarlos innecesariamente.

Ten en cuenta que es posible que se realice una renderización previa debido a la renderización previa de la barra de direcciones y no solo a tus reglas de especulación. Si quieres diferenciarlos, puedes verificar el document.referrer (que estará en blanco para la navegación de la barra de direcciones, incluidas las navegaciones de la barra de direcciones renderizadas previamente).

Recuerda revisar también las páginas que no tienen renderizaciones previas, ya que eso podría indicar que no son aptas para la renderización previa, incluso desde la barra de direcciones. Esto puede significar que no te beneficias de esta mejora de rendimiento. El equipo de Chrome busca agregar herramientas adicionales para probar la elegibilidad de la prerenderización, quizás similares a la herramienta de prueba de bfcache, y también agregar una API para exponer por qué falló una prerenderización.

Impacto en las extensiones

Consulta la publicación exclusiva sobre Extensiones de Chrome: Extiende la API para admitir la navegación instantánea, en la que se detallan algunas consideraciones adicionales que los autores de extensiones pueden tener en cuenta para las páginas renderizadas previamente.

Comentarios

El equipo de Chrome está desarrollando activamente la renderización previa, y hay muchos planes para expandir el alcance de lo que se puso a disposición en la versión 108 de Chrome. Aceptamos cualquier comentario en el repositorio de GitHub o a través de nuestro seguimiento de problemas. Esperamos escuchar y compartir casos de éxito de esta nueva y emocionante API.

Agradecimientos

Miniatura de Marc-Olivier Jodoin en Unsplash