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

Barry Pollard

Navegadores compatibles

• 109
• 109
• x
• x

El equipo de Chrome está trabajando en diferentes opciones para recuperar la renderización previa completa de las páginas futuras a las que sea probable que el usuario navegue.

Breve historial de la renderización previa

En el pasado, Chrome admitía la sugerencia del recurso <link rel="prerender" href="/next-page">; sin embargo, no era ampliamente compatible más allá de Chrome y no era una API muy expresiva.

Esta renderización previa heredada con la sugerencia rel=prerender del vínculo dejó de estar disponible y se reemplazó por NoState Prefetch, que, en su lugar, recuperaba los recursos que necesitaba la página futura, pero no preprocesó la página ni ejecutó JavaScript por completo. NoState Prefetch ayuda a mejorar el rendimiento de la página, ya que optimiza la carga de recursos, pero no proporciona una carga instantánea de la página como lo haría una renderización previa completa.

El equipo de Chrome volvió a introducir 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 permanece para NoState Prefetch, con la idea de retirar esta función en algún momento.

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

Una página se puede renderizar previamente de una de estas cuatro maneras, todas ellas diseñadas para acelerar la navegación:

1. Cuando escribes una URL en la barra de direcciones de Chrome (también conocida como "el cuadro multifunción"), es posible que Chrome renderice automáticamente la página por ti si tiene un alto grado de certeza de que la visitarás.
2. Cuando escribes un término de búsqueda en la barra de direcciones de Chrome, es posible que Chrome renderice automáticamente la página de resultados de búsqueda si el motor de búsqueda te lo solicita.
3. Los sitios pueden usar la API de Speculation Rules para indicarle a Chrome qué páginas renderizar previamente de forma programática. Esto reemplaza lo que solía hacer <link rel="prerender"...> y permite que los sitios rendericen previamente una página de forma proactiva en función de las reglas de especulación de la página. Estos pueden existir de manera estática en las páginas o se pueden insertar de forma dinámica con JavaScript según lo considere adecuado 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 se activa una página antes de completar la renderización previa, su estado actual será "en primer plano" y continuará 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, varias 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 la pequeña cantidad de 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 mejorar las capacidades de Herramientas para desarrolladores para facilitar la identificación de estos casos extremos.

Nota: Las páginas renderizadas previamente deben tratarse como una sugerencia y una mejora progresiva. A diferencia de preload, la renderización previa es una sugerencia especulativa y el navegador puede optar por no actuar según la configuración del usuario, el uso actual de memoria o alguna otra heurística.

Impacto de la renderización previa

La renderización previa permite que la página se cargue casi al instante, como se muestra en el siguiente video:

Ejemplo de impacto de la renderización previa.

El sitio de ejemplo ya es un sitio 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 inicial con la carga de la página debería mejorar la experiencia de carga. Si se activa un vínculo mientras se realiza la renderización previa, la página de renderización previa se moverá al marco principal y continuará cargándose.

Sin embargo, la renderización previa usa memoria adicional y ancho de banda de red. Ten cuidado de no realizar un procesamiento previo, a costa de los recursos del usuario. Renderiza previamente solo cuando hay una alta probabilidad de que se navegue por 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 en el rendimiento en tus estadísticas.

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:

Página de Predictores de Chrome.

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

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

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

Función "escritura anticipada" en la barra de direcciones

Chrome actualizará sus predictores continuamente en función de lo que hayas escrito y lo que selecciones.

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

La API de Speculation Rules

Para la tercera opción de renderización previa, los desarrolladores web pueden insertar instrucciones JSON en sus páginas para informar al navegador qué URLs deben renderizar previamente:

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

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

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

Nota: La API de Speculation Rules se usaba para incluir una clave source configurada como list para las URLs de lista o document para las URLs de documentos. Sin embargo, como esto se puede inferir por la presencia de una clave urls o where (que son mutuamente excluyentes), este requisito se quitó de Chrome 121. Es posible que veas esta clave source en algunos sitios o código de ejemplo.

Ansiedad

Navegadores compatibles

• 121
• 121
• x
• x

Se usa un parámetro de configuración eagerness para indicar cuándo se deben activar las especulaciones, lo que es particularmente útil para las reglas de documentos:

• immediate: Se usa para especular lo antes posible, es decir, en cuanto se observan las reglas de especulación.
• eager: Se comporta de la misma manera que el parámetro de configuración immediate, pero, en el futuro, buscaremos colocarlo en algún lugar entre immediate y moderate.
• moderate: Realiza especulaciones si colocas el cursor 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 toque.

El eagerness predeterminado para las reglas de 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 con una lista específica. Sin embargo, en muchos casos, las reglas de document con una condición where adecuada pueden ser más adecuadas.

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

La configuración de eagerness que debes usar depende de tu sitio. En el caso de un sitio estático y liviano, especular con más anticipación puede tener pocos costos y ser beneficioso para los usuarios. Es posible que los sitios con arquitecturas más complejas y cargas útiles de página más pesadas prefieran reducir el desperdicio con una especulación menos frecuente hasta que obtengas indicadores más positivos de intención de los usuarios de limitar el desperdicio.

Precaución: La sobreespeculación tiene un costo claro para los usuarios en términos de ancho de banda, memoria y CPU, pero también para los sitios. Sé consciente del impacto que tienes en tus usuarios cuando implementes especulaciones. La configuración de eagerness te permite reducir la probabilidad de especulaciones desperdiciadas. Chrome también impone límites a las especulaciones para reducir el impacto del uso excesivo.

La opción moderate es un punto intermedio, y muchos sitios podrían beneficiarse de la siguiente regla de especulación que preprocesaría todos los vínculos cuando se coloca el cursor sobre ellos o el puntero hacia abajo como una implementación básica, pero poderosa, 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 solo para cargar previamente páginas, sin una renderización previa completa. A menudo, este puede ser un buen primer paso para completar la renderización previa:

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

Nota: A diferencia de la sugerencia del recurso <link rel="prefetch"> anterior que acaba de cargar previamente en la caché HTTP, los documentos cargados con reglas de especulación se procesan de la misma manera que las navegaciones (pero no se renderizan) y se mantienen en la memoria, de modo que estarán disponibles más rápido para el navegador una vez que lo necesiten. Esto también permite que los documentos que no se pueden almacenar en caché en la caché HTTP se carguen previamente. Debido a problemas con la carga previa de documentos con <link rel="prefetch">, se recomienda usar reglas de especulación para estos en el futuro, y <link rel="prefetch"> solo se usa para la carga previa de subrecursos.

Límites de Chrome

Chrome tiene los siguientes 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 forma primero en entrar, primero en salir (FIFO): después de alcanzar el límite, una especulación nueva hará que se cancele y se reemplace la más antigua por la más nueva para conservar memoria. Una especulación cancelada se puede volver a activar, por ejemplo, si colocas el cursor sobre ese vínculo nuevamente, lo que hará que se vuelva a especular la URL y se envíe la especulación más antigua. En este caso, la especulación anterior habrá almacenado en caché cualquier recurso de la caché HTTP para esa URL, por lo que especular más tiempo debería tener un costo reducido. Por eso, el límite se estableció en un umbral mínimo de 2. Las reglas de listas estáticas no se activan mediante una acción del usuario, por lo que tienen un límite más alto, ya que no es posible que el navegador sepa qué elementos son necesarios y cuándo se necesitan.

Los límites de immediate y eager también son dinámicos, por lo que quitar un elemento de secuencia de comandos de URL de list creará capacidad mediante la cancelación de las especulaciones que se quitaron.

Chrome también evitará el uso de especulaciones en ciertas condiciones, como las siguientes:

• Guardar datos.
• Ahorro de energía cuando está habilitado y con batería baja
• Las restricciones de memoria.
• Cuando está desactivado el parámetro de configuración "Precargar páginas" (que también está desactivado explícitamente por extensiones de Chrome como uBlock Origin)
• Páginas abiertas en pestañas en segundo plano.

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

El objetivo de todas estas condiciones es reducir el impacto de la especulación excesiva que podría perjudicar a 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, de forma dinámica, en JavaScript mediante JavaScript:

• Reglas de especulación incluidas de forma estática: Por ejemplo, un sitio de medios de noticias o un blog pueden renderizar previamente el artículo más reciente, si esa suele ser la siguiente navegación para una gran proporción de usuarios. Como alternativa, se pueden usar reglas de documentos con moderate o conservative para especular a medida que los usuarios interactúan con 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.

Aquellos que prefieren la inserción dinámica en función de acciones como colocar el cursor sobre un vínculo o hacer clic hacia abajo en un vínculo (como lo hacían muchas bibliotecas en el pasado con <link rel=prefetch>) se recomienda que observen las reglas de los documentos, ya que permiten que el navegador maneje muchos de tus casos de uso.

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

El encabezado HTTP Speculation-Rules

Navegadores compatibles

• 121
• 121
• x
• x

Origen

Las reglas de especulación también se pueden entregar con un encabezado HTTP Speculation-Rules, en lugar de incluirlas directamente en el código HTML del documento. Esto permite una implementación más sencilla mediante CDN sin 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"

Advertencia: Como se trata de un encabezado estructurado, las comillas son importantes y deben incluirse en el valor del encabezado.

Este recurso debe usar el tipo de MIME correcto y, si es un recurso de origen cruzado, debe pasar una verificación de CORS.

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

Si deseas usar URLs relativas, puedes incluir la clave "relative_to": "document" en tus reglas de especulación. De lo contrario, las URLs relativas estarán relacionadas con la URL del archivo JSON de las reglas de especulación. Esto puede ser particularmente ú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áginas completas administradas por el navegador y no con las apps de una sola página (SPA) ni las páginas de shells de apps. Esta arquitectura no usa recuperaciones de documentos, sino recuperaciones de datos o páginas parciales mediante API o parciales, que luego se procesan y se presentan en la página actual. La app puede cargar previamente los datos necesarios para estas llamadas “navegaciones de software”, 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 desde una página anterior. Esto puede ayudar a compensar algunos de los costos adicionales de carga inicial que tienen algunas SPA. Sin embargo, los cambios de ruta dentro de la app no se pueden renderizar previamente.

Depurar reglas de especulación

Consulta la entrada exclusiva sobre la depuración de 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 estas se anexan a las reglas existentes. Por lo tanto, las siguientes formas generan una renderización previa de one.html y two.html:

Lista de URLs:

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

Varios speculationrules:

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

Varias listas en un conjunto de speculationrules

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

Compatibilidad con No-Vary-Search

Navegadores compatibles

• 121
• 121
• x
• x

Origen

Cuando realizas un procesamiento previo o una solicitud 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 realmente proporciona el servidor y solo los use el código JavaScript del cliente.

Por ejemplo, Google Analytics usa los parámetros de AUA para medir las campañas, pero no suele dar como resultado que se publiquen diferentes páginas 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, por lo que se podrá volver a usar la misma página de la caché.

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

La propuesta No-Vary-Search permite que un servidor especifique parámetros que no generan una diferencia con el recurso entregado y, por lo tanto, permite que un navegador reutilice versiones de un documento previamente almacenadas en caché que solo difieren por estos parámetros. Esto es compatible con Chrome (y los navegadores basados en Chromium) solo para especulaciones de navegación con carga 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 ayudarte 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 inicial de la página /products es el mismo para los IDs de producto 123 y 124. Sin embargo, el contenido de la página eventualmente difiere según el procesamiento del cliente mediante JavaScript para recuperar datos de productos con el parámetro de búsqueda id. Por lo tanto, cargamos esa URL con anticipación y debería mostrar un encabezado HTTP No-Vary-Search que indique que la página se puede usar para cualquier parámetro de búsqueda de 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 optar por 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. El parámetro de configuración 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 espere a que se complete esa carga previa.

Restricciones de las reglas de especulación y mejoras futuras

Las reglas de especulación se restringen a páginas abiertas en la misma pestaña, pero estamos trabajando para reducir esas restricciones. De forma predeterminada, la renderización previa está restringida a páginas del mismo origen.

Renderiza previamente páginas de origen cruzado en el mismo sitio (por ejemplo, https://a.example.com podría renderizar previamente una página en https://b.example.com). Para usar esta opción, la página renderizada previamente (en este ejemplo, https://b.example.com) debe habilitarse incluyendo un encabezado HTTP Supports-Loading-Mode: credentialed-prerender; de lo contrario, Chrome cancelará la renderización previa.

Las versiones futuras también pueden permitir la renderización previa de páginas de origen cruzado (en las que el sitio habilita la función con un encabezado HTTP Supports-Loading-Mode: uncredentialed-prerender similar) y habilitar la renderización previa en pestañas nuevas.

Compatibilidad con la API de Detect Speculation Rules

Puedes detectar la compatibilidad de la API de Speculation Rules con verificaciones de 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 inserción de JavaScript en esta página de demostración de renderización previa.

Cancelar reglas de especulación

Si quitas las reglas de especulación, se cancelará la renderización previa. Sin embargo, cuando esto ocurra, es probable que los recursos ya se hayan gastado para iniciar la renderización previa. Por lo tanto, se recomienda no realizar la renderización previa si existe la probabilidad de que se necesite cancelar la renderización.

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 script-src Content-Security-Policy si el sitio lo usa, ya sea con un hash o un nonce.

Se puede agregar un nuevo inline-speculation-rules a script-src para permitir que se admitan los elementos <script type="speculationrules"> inyectados desde hash o secuencias de comandos noncedidas. Este comando no admite reglas incluidas en el código HTML inicial, por lo que JavaScript debe insertarlas en los sitios que usan una CSP estricta.

Cómo detectar e 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 rápida de la página, que a menudo es 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 otro modo.

Sin embargo, puede haber algunas instancias en las que no quieras que se produzca 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 en función de la ejecución de JavaScript en la página.

Cómo habilitar e inhabilitar la renderización previa en Chrome

La renderización previa solo está habilitada para los usuarios de Chrome que tengan el parámetro de configuración "Precargar páginas" en chrome://settings/performance/. Además, la renderización previa también está inhabilitada en los 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 precargadas que usan la API de Speculation Rules tendrán este encabezado establecido en solo 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 realice una renderización previa. Si se muestra un código de respuesta sin éxito (es decir, no un 200 ni un 304), la página no se renderizará previamente y se descartará cualquier página de carga previa.

Si no quieres que una página específica se renderice previamente, esta es la mejor manera de asegurarte de que no suceda. Sin embargo, para brindar la mejor experiencia, se recomienda permitir la renderización previa, pero retrasar las acciones que solo deberían realizarse para que la página se vea realmente, con JavaScript.

Detecta la renderización previa en JavaScript

La API de document.prerendering mostrará true mientras la página se esté renderizando previamente. Las páginas pueden usarlo para evitar, o retrasar, ciertas actividades durante la renderización previa hasta que la página se active realmente.

Una vez que se active un documento renderizado previamente, el activationStart de PerformanceNavigationTiming también se establecerá en una hora distinta de cero, que representa el tiempo desde que se inició la renderización previa y se activó el documento.

Puedes usar una función para verificar las páginas renderizadas previamente y con renderización previa de la siguiente manera:

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 es abrir las Herramientas para desarrolladores después de que se haya realizado la renderización previa 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:

Prueba la renderización previa en la consola.

Sugerencia: Hay funciones de depuración adicionales de Herramientas para desarrolladores de Chrome disponibles para depurar páginas que se completaron previamente y las que se renderizaron previamente. Consulta la publicación de depuración de reglas de especulación para obtener más detalles.

Cuando el usuario que está visualizando la página activa la página, se envía el evento prerenderingchange al document, que luego se puede usar para habilitar actividades que antes se iniciarían de forma predeterminada cuando se carga la página, pero que deseas retrasar hasta que el usuario vea la página.

Con estas APIs, el frontend de JavaScript puede detectar las páginas renderizadas previamente y tomar las medidas adecuadas.

Advertencia: PerformanceNavigationTiming.type no usa el valor prerender, que era para el tipo de navegación original <link rel="prerender"...> más antiguo. Esto puede cambiar en el futuro, pero, por ahora, los clientes deben usar la API de document.prerendering para identificar las páginas de renderización previa y un campo PerformanceNavigationTiming.activationStart que no sea cero para identificar las páginas prerenderizadas que se activaron desde entonces.

Impacto en las estadísticas

Analytics se usa para medir el uso de los sitios web; por ejemplo, se usa 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 la función Supervisión de usuarios reales (RUM).

Las páginas solo se deben renderizar previamente cuando hay una alta probabilidad de que el usuario cargue la página. Es por eso que las opciones de renderización previa de la barra de direcciones de Chrome solo aparecen cuando hay una probabilidad tan alta (superior al 80% de las veces).

Sin embargo, especialmente 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 el análisis de las páginas renderizadas previamente en la activación, ya que no todos los proveedores de estadísticas pueden hacerlo de forma predeterminada.

Nota: Google Analytics controla la renderización previa retrasando la activación de forma predeterminada. Google Publisher Tag (GPT) y Google AdSense también retrasan el proceso hasta la activación de manera similar.

Para ello, puedes usar un Promise que espera el evento prerenderingchange si se está renderizando un documento o se resuelve de inmediato si ahora sucede lo siguiente:

// 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);
  } else {
    resolve();
  }
});

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

initAnalytics();

Cómo medir el rendimiento

Para medir las métricas de rendimiento, Analytics debe 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 Chrome mide a través del Informe sobre la experiencia del usuario en Chrome, se usan para medir la experiencia del usuario. Se miden según el tiempo de activación. Esto suele generar un LCP de 0 segundos, por ejemplo, lo que muestra que es una excelente manera de mejorar tus Métricas web esenciales.

A partir de la versión 3.1.0, se actualizó la biblioteca web-vitals para controlar las navegaciones renderizadas previamente de la misma manera que Chrome mide las Métricas web esenciales. Esta versión también marca las navegaciones renderizadas previamente para esas métricas en el atributo Metric.navigationType.

Cómo medir las renderizaciones previas

Si una página está renderizada previamente, se puede ver con una entrada activationStart de PerformanceNavigationTiming que no sea cero. Luego, esto se puede registrar con una dimensión personalizada, o similar cuando se registran las vistas de página, por ejemplo, con la función pagePrerendered descrita 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 están renderizadas previamente en comparación con otros tipos de navegación y, además, te permitirá correlacionar las métricas de rendimiento o empresariales con estos diferentes tipos de navegación. Una página más rápida significa que los usuarios están más satisfechos, lo que a menudo puede tener un impacto real en las medidas comerciales, como se muestra en nuestros casos de éxito.

A medida que mides el impacto comercial de las páginas renderizadas previamente para las navegaciones instantáneas, puedes decidir si vale la pena invertir más esfuerzo en usar esta tecnología para permitir que se rendericen más navegaciones o investigar por qué las páginas no se están renderizando previamente.

Mide las tasas de hits

Además de medir el impacto de las páginas visitadas después de una renderización previa, también es importante medir las páginas que se renderizan previamente y no se visitan posteriormente. lo que podría implicar que estás renderizando demasiado y usando recursos valiosos del usuario para obtener poco beneficio.

Para medir esto, se activa un evento de estadísticas cuando se insertan reglas de especulación (después de verificar que el navegador admite 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 inició o completó una renderización previa, ya que, como se indicó anteriormente, es una sugerencia para el navegador y puede optar por no renderizar previamente las páginas en la configuración del usuario, el uso actual de memoria o alguna otra heurística).

Luego, puedes comparar la cantidad de estos eventos con las vistas de página con la renderización previa reales. También puedes activar otro evento durante la activación si eso facilita la comparación.

Entonces, la "tasa de hits exitosos" se puede aproximar observando la diferencia entre estas dos cifras. En el caso de las páginas en las que usas la API de Speculation Rules para renderizar previamente las páginas, puedes ajustar las reglas adecuadamente a fin de asegurarte de mantener una tasa de hits alta para mantener el equilibrio entre usar los recursos de los usuarios para ayudarlos o usarlos innecesariamente.

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

Recuerda 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 estás aprovechando esta mejora del rendimiento. El equipo de Chrome está buscando agregar herramientas adicionales para probar la elegibilidad de la renderización previa, similar a la herramienta de prueba de bfcache, y también agregar una API para exponer por qué falló una renderización previa.

Impacto en las extensiones

Consulta la publicación dedicada sobre Extensiones de Chrome: Cómo extender 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 ampliar el alcance de lo que está disponible en la versión 108 de Chrome. Agradecemos los comentarios que nos envíes en el repositorio de GitHub o mediante nuestra Herramienta de seguimiento de errores, y esperamos escuchar y compartir casos de éxito de esta emocionante API nueva.

Vínculos relacionados

• Depuración de reglas de especulación
• Presentamos NoState Prefetch
• API de Speculation Rules
• El repositorio de GitHub de especulación de Navigation
• Extensiones de Chrome: Extensión de la API para admitir la navegación instantánea

Agradecimientos

Imagen en miniatura de Marc-Olivier Jodoin en Unsplash