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

Navegadores compatibles

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

El equipo de Chrome volvió a habilitar la renderización previa completa de 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 y se reemplazó por NoState Prefetch, que recuperó los recursos que necesita la página futura, pero no realizó una renderización previa completa de la página ni ejecutó 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"), es posible que Chrome renderice automáticamente la página por ti, si tiene una alta confianza de que la visitarás, según tu historial de navegación anterior.
  2. Cuando usas la barra de favoritos, es posible que Chrome renderice previamente la página automáticamente 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 <link rel="prerender"...> solía hacer y permite que los sitios rendericen previamente una página de forma proactiva según 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.

Cuando la página renderizada previamente se abre en un estado oculto, una serie de APIs que causan comportamientos intrusivos (por ejemplo, mensajes) no se activan en este estado, sino que se retrasan hasta que se activa la página. En los pocos casos en los que 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 que la página se cargue casi de forma 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 con esto 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 en la carga de la página debería mejorar la experiencia de carga. Cuando se activa un vínculo mientras aún se está realizando la renderización previa, la página con 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 Cómo medir el rendimiento para obtener más información sobre cómo medir el impacto real del 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 predictores de Chrome filtrada 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" genera una confianza razonable (ámbar). Sin embargo, una vez que escribes "sh", Chrome tiene suficiente confianza como para que casi siempre navegues 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% (indicado en verde), Chrome renderizará previamente la URL.

La API de Speculation Rules

Para 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 qué URLs debe renderizar previamente:

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

También puedes usar las reglas del documento (disponibles en Chrome 121), que renderizan previamente los vínculos del documento según los selectores href (según la API de URL Pattern) 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 es compatible.

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: Este parámetro se comporta de forma idéntica al parámetro de configuración immediate, pero esperamos que, en el futuro, lo ubique entre immediate y moderate.
  • 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).

El parámetro de configuración eagerness que debes usar 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 término medio, y muchos sitios podrían beneficiarse de la siguiente regla de especulación que renderizaría previamente un vínculo cuando se mantenga el puntero sobre él durante 200 milisegundos o en el evento de abajo del puntero como una implementación básica, pero potente, de las 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. Este suele ser un buen primer paso para realizar 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:

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

Los parámetros de configuración de moderate y conservative, que dependen de la interacción del usuario, funcionan de manera primera 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 nueva para conservar memoria. Una especulación cancelada se puede volver a activar (por ejemplo, si vuelves a colocar el cursor sobre ese vínculo), lo que hará que se vuelva a especular sobre esa URL y se elimine la especulación más antigua. En este caso, la especulación anterior habrá almacenado en caché cualquier recurso que se pueda almacenar en caché HTTP para esa URL, por lo que la especulación más tiempo 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 determinadas condiciones, entre las que se incluyen 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 renderiza iframes de origen cruzado en páginas renderizadas previamente hasta que se activan.

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 subframes, y las reglas de especulación en las páginas renderizadas de forma previa 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 se admite.

Origen

Las reglas de especulación también se pueden entregar con un encabezado HTTP Speculation-Rules, en lugar de incluirlas directamente en el 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 de forma previa la aplicación desde una página anterior. Esto puede ayudar a compensar algunos de los costos de carga iniciales adicionales 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 publicación dedicada sobre cómo depurar reglas de especulación para conocer las nuevas funciones de las Herramientas para desarrolladores de Chrome 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 devuelva 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 anticipación y deberíamos mostrar un encabezado HTTP No-Vary-Search que indique 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 si recuperar el vínculo de nuevo 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 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 la carga previa entre orígenes, pero solo cuando no existen cookies para el dominio entre orígenes. 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 con respecto a <link rel="prefetch"> para los destinos de varios orígenes, que tampoco enviarán cookies, pero intentarán la carga previa, lo que generará una carga previa desperdiciada que se deberá volver a enviar o, lo que es peor, la carga incorrecta de la página.

Las reglas de especulación no son compatibles con la precarga de páginas controladas por trabajadores del servicio. Estamos trabajando para agregar esta compatibilidad. Sigue este problema de Service Worker de asistencia para ver las 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.

Del mismo modo, editar directamente el panel Elementos en Herramientas para desarrolladores de Chrome para agregar el elemento <script type = "speculationrules"> no registra las reglas de especulación y, en su lugar, la secuencia de comandos para agregarlo de forma dinámica al DOM se debe ejecutar 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 etiquetas HTML personalizadas en Google Tag Manager
Agrega reglas de especulación mediante 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, cuando esto suceda, es probable que ya se hayan invertido recursos para iniciar la renderización previa, por lo que se recomienda no realizar la renderización previa si es probable que debas cancelarla.

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 puede 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 se inhabilita en dispositivos con poca memoria o si el sistema operativo está en los modos Ahorro de datos o Ahorro de energía. Consulta la sección Límites de Chrome.

Cómo detectar e 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 se renderice previamente una página en particular, la mejor manera de garantizar que no suceda es mostrar un código de respuesta que no sea 2XX (como 503). 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.

Cómo detectar el renderizado previo 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 usar una función para verificar las páginas con renderización previa y renderización previa, como las siguientes:

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 completa o parcial) es abrir DevTools después de que se active la página y escribir performance.getEntriesByType('navigation')[0].activationStart en la consola. Si se muestra un valor distinto de cero, significa que la página se renderizó previamente:

La consola en Herramientas para desarrolladores de Chrome muestra una activación positiva. El comienzo indica que la página se renderizó previamente.
Prueba la renderización previa en la consola.

Cuando el usuario que está viendo la página active la página, se enviará el evento prerenderingchange en document, que se puede usar para habilitar actividades que antes se iniciarían de forma predeterminada al cargar la página, pero que deseas retrasar hasta que el usuario 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

Las estadísticas se utilizan para medir el uso de los sitios web, por ejemplo, con Google Analytics para medir las vistas de página y los eventos. También puedes medir las métricas de rendimiento de las páginas con supervisión de usuarios reales (RUM).

Las páginas solo deben renderizarse previamente cuando haya una alta probabilidad de que el usuario las cargue. 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 sitios deban agregar código adicional para habilitar solo las estadísticas de las páginas renderizadas previamente en 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 Analytics y casos de uso similares, en otros casos, es posible que desees que se cargue más contenido para esos casos y que uses document.prerendering y prerenderingchange para segmentar específicamente páginas de renderización previa.

Retener otro contenido durante la renderización previa

Las mismas APIs que se analizaron anteriormente se pueden usar para retener otro contenido durante la fase de renderización previa. Pueden ser partes específicas de JavaScript o elementos completos de secuencias de comandos que preferirías 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, se pueden retener las recomendaciones, el estado de acceso o los íconos del carrito de compras para garantizar que se presente la información más actualizada.

Si bien es más probable que esto ocurra con más frecuencia cuando se usa la renderización previa, estas condiciones también se aplican a las páginas cargadas en las pestañas en segundo plano que se mencionaron 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, pero esta 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, las estadísticas 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 que se miden según el tiempo de activación. Esto suele dar como resultado un LCP de 0 segundos, por ejemplo, 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

Se puede ver si una página se renderizó previamente con una entrada activationStart distinta de cero de PerformanceNavigationTiming. 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.

Mide las tasas de aciertos

Además de medir el impacto de las páginas que se visitan después de una renderización previa, también es importante medir las páginas que se renderizan previamente y que no se visitan 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 hecho de que se haya solicitado una renderización previa no indica que se haya iniciado o completado, ya que, como se señaló anteriormente, una renderización previa es una sugerencia para el navegador y este puede optar por no renderizar páginas en la configuración del usuario, el uso actual de la memoria y 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

Imagen en miniatura de Marc-Olivier Jodoin en Unsplash