Mejoras en la API de Speculation Rules

Barry Pollard

El equipo de Chrome ha estado trabajando en algunas actualizaciones interesantes para la API de Speculation Rules que se utiliza para mejorar el rendimiento de la navegación realizando una carga previa o incluso el procesamiento previo de navegaciones futuras. Ahora, todas estas mejoras adicionales están disponibles en Chrome 122 (con algunas funciones disponibles en versiones anteriores).

Estos cambios hacen que la carga previa y la renderización previa de las páginas sean mucho más fáciles de implementar y menos desperdicio, lo cual esperamos fomentar una mayor adopción.

Características adicionales

En primer lugar, encontrarás una explicación de las nuevas incorporaciones que agregamos a la API de Speculation Rules y cómo usarlas. Luego, te mostraremos una demostración para que puedas verlas en acción.

Reglas del documento

Anteriormente, la API de Speculation Rules funcionaba especificando una lista de URLs para precargar o renderizar previamente:

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

Las reglas de especulación eran semidinámicas, ya que se podían agregar nuevas secuencias de comandos de reglas de especulación y se quitaron las antiguas para descartarlas (ten en cuenta que actualizar la lista urls de una secuencia de comandos de reglas de especulación existente no activa un cambio en las especulaciones). Sin embargo, dejaba la elección de las URLs al sitio, ya sea enviándolas desde el servidor en el momento de la solicitud de la página o creando dinámicamente esta lista a través de JavaScript del cliente.

Las reglas de lista siguen siendo una opción para casos de uso más simples (en los que la navegación siguiente proviene de un conjunto pequeño de obvias) o casos de uso más avanzados (en los que la lista de URLs se calcula de forma dinámica en función de cualquier heurística que el propietario del sitio desee utilizar y, luego, se inserte en la página).

Como alternativa, nos complace ofrecer una nueva opción para la búsqueda automática de vínculos mediante las reglas de documentos. Esto funciona obteniendo las URLs del documento según una condición where. Esto puede basarse en los vínculos en sí:

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

Nota: Una versión anterior de las reglas de documentos (disponible durante la prueba de origen) tenía un href_matches más complejo que requería una sintaxis adicional para hacer coincidir los parámetros de URL y los fragmentos ({"href_matches": "/*\\?*#*"}). Esto se simplificó en la versión de actualización.

Los selectores CSS también se pueden usar como alternativa o junto con coincidencias de href para encontrar vínculos en la página actual:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Esto permite que se use un único conjunto de reglas de especulación en todo el sitio, en lugar de tener reglas específicas por página, lo que facilita mucho a los sitios implementar reglas de especulación.

Sin duda, la renderización previa de todos los vínculos de una página sería un desperdicio, por lo que, con esta nueva capacidad, agregamos un parámetro de configuración eagerness.

Ansiedad

En cualquier tipo de especulación, existe una compensación entre precisión y recuperación y el plazo de entrega. La renderización previa de todos los vínculos cuando se carga la página significa que, con certeza, renderizarás previamente un vínculo en el que un usuario hace clic (suponiendo que hace clic en un vínculo del mismo sitio en la página) y con el mayor tiempo de antelación posible, pero con una pérdida potencial enorme de ancho de banda.

Por otro lado, solo la renderización previa una vez que el usuario hace clic en un vínculo evita que se desperdicien, pero se reduce el plazo de entrega. lo que significa que es poco probable que haya completado la renderización previa antes de que el navegador cambie a esa página.

La configuración eagerness te permite definir cuándo se deben ejecutar las especulaciones, y separa cuándo especular desde qué URLs se deben realizar. El parámetro de configuración eagerness está disponible para las reglas de origen list y document, y tiene cuatro parámetros de configuración, para los cuales Chrome tiene la siguiente heurística:

• immediate: Se usa para especular lo antes posible, es decir, en cuanto se observan las reglas de especulación.
• eager: Actualmente, este comportamiento es idéntico al parámetro de configuración immediate, pero, en el futuro, deseamos ubicarlo 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 muy simple, especular con más anticipación puede tener poco costo 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 simple que renderizaría previamente 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": [{
    "source": "document",
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

Límites de Chrome

Incluso con la opción eagerness, Chrome tiene límites para evitar el uso excesivo de esta API:

eagerness	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 la manera Primero en entrar, primero en salir (FIFO). Después de alcanzar el límite, una especulación nueva hará que se cancele y reemplace la especulación más antigua por la más nueva para conservar memoria.

El hecho de que los usuarios activen las especulaciones moderate y conservative nos permite usar un umbral más sencillo de 2 para conservar memoria. La configuración de immediate y eager no se activa a través de una acción del usuario, por lo que tiene un límite más alto, ya que el navegador no puede saber cuáles son los elementos necesarios ni cuándo se necesitan.

Una especulación que se cancela cuando se la expulsa de la cola FIFO puede volver a activarse (por ejemplo, si colocas el cursor sobre ese vínculo nuevamente), lo que hará que se vuelva a especular la URL. En ese caso, la especulación anterior probablemente haya provocado que el navegador haya almacenado en caché algunos recursos de la caché HTTP para esa URL, por lo que repetir la especulación debería tener una red mucho menor y los costos de tiempo.

Los límites de immediate y eager también son dinámicos. Si quitas un elemento de la secuencia de comandos de reglas de especulación que usa estos niveles de anticipación, se creará capacidad mediante la cancelación de las especulaciones que se quitaron. Estas URLs también se pueden volver a especular si se incluyen en una nueva secuencia de comandos de URLs y no se alcanzó el límite.

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

• Guardar datos.
• Ahorro de energía.
• 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.

El objetivo de todas estas condiciones es reducir el impacto de la especulación excesiva que podría perjudicar a los usuarios.

source opcional

En Chrome 122, la clave source es opcional, ya que se puede inferir de la presencia de las teclas url o where. Por lo tanto, estas dos reglas de especulación son idénticas:

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

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

Encabezado HTTP Speculation-Rules

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.

Mejor reutilización de la caché

Realizamos una serie de mejoras en el almacenamiento en caché de Chrome para que la carga previa (o incluso la renderización previa) de un documento almacene y reutilice recursos en la caché HTTP. Esto significa que la especulación aún puede tener beneficios futuros, incluso si no se usa.

Esto también hace que la nueva especulación (por ejemplo, para reglas de documentos con un parámetro de configuración de alcance moderate) sea considerablemente más económica, ya que Chrome usará la caché HTTP para los recursos que se pueden almacenar en caché.

También admitimos la nueva propuesta No-Vary-Search para mejorar aún más la reutilización de la caché.

Compatibilidad con No-Vary-Search

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 UTM para la medición de campañas, pero, por lo general, no generan la publicación de 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. Nota: Por el momento, esto solo se admite en Chrome (y navegadores basados en Chromium) 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.

Demostración

Creamos una demostración en https://speculative-rules.glitch.me/common-fruits.html, que se puede usar para ver las reglas de documentos con un parámetro de configuración de orden moderate en acción:

Demostración de las reglas de especulación

Abre Herramientas para desarrolladores y haz clic en el panel Aplicación. Luego, en la sección Servicios en segundo plano, haz clic en Cargas especulativas, luego en el panel Speculations y ordénalos por la columna Status.

Cuando coloques el cursor sobre las frutas, verás la renderización previa de las páginas. Si haces clic en ellas, se mostrará un tiempo de LCP mucho más rápido que una de las recetas, que no están renderizadas previamente. Esta demostración también se explica en el siguiente video:

También puedes consultar la entrada de blog anterior sobre las reglas de especulación de depuración para obtener más información sobre cómo usar las Herramientas para desarrolladores a fin de depurar reglas de especulación.

Plataforma compatible con reglas de especulación

Si bien las reglas de especulación son relativamente fáciles de implementar mediante la inserción de las reglas en un elemento <script type="speculationrules">, la compatibilidad con la plataforma puede hacer de un clic. Trabajamos con varias plataformas y socios para facilitar la implementación de reglas de especulación.

También estamos trabajando arduamente para estandarizar la API a través de Web Incubator Community Group (WICG), de modo que se permita que otros navegadores también implementen esta emocionante API si así lo desean.

WordPress

El equipo de WordPress Core Performance (incluidos los desarrolladores de Google) creó un complemento de reglas de especulación. Este complemento permite agregar con un solo clic la compatibilidad de reglas de documentos a cualquier sitio de WordPress. Este complemento también está disponible para su instalación a través del complemento WordPress Performance Lab. También deberías instalarlo, ya que te mantendrá al tanto de los complementos de rendimiento relacionados del equipo.

Hay dos grupos de parámetros de configuración disponibles: Modo de especulación y Eagerness:

Complemento de reglas de especulación de WordPress

En el caso de configuraciones más complicadas (por ejemplo, para excluir determinadas URLs de la carga previa o la renderización previa), lee la documentación.

Akamai

Akamai es uno de los proveedores de CDN líderes del mundo y lleva algún tiempo experimentando de forma activa con la API de Speculation Rules. Akamai publicó documentación sobre la forma en que los clientes pueden habilitar esta API en su configuración de CDN. También compartieron anteriormente los impresionantes resultados posibles con esta nueva API.

NitroPack

NitroPack es una solución de optimización del rendimiento que usa su IA de Navigation personalizada para predecir qué páginas agregar a las reglas de especulación, que tiene como objetivo proporcionar un plazo de entrega más largo que colocar el cursor sobre un vínculo, pero sin la pérdida de especular innecesariamente sobre todos los vínculos observados. Consulta la documentación de la API de reglas de especulación de Nitropack para obtener más información. Esta solución innovadora demuestra que todavía hay mucho que ofrecer las reglas anteriores de las listas cuando se combina con estadísticas específicas del sitio.

El equipo de Chrome también trabajó con NitroPack en un seminario en línea para la API de Speculation Rules para aquellos que buscaban más información, incluido un buen debate sobre las consideraciones necesarias para especular temprano y con frecuencia, así como tarde y con menos frecuencia.

Astro

Astro agregó preprocesamiento de páginas con la API de Speculation Rules en 4.2 de forma experimental, lo que permite a los desarrolladores que usan Astro habilitar esta función con facilidad y, al mismo tiempo, recurrir a una carga previa estándar para navegadores que no admiten la API de Speculation Rules. Para obtener más información, consulta la documentación de renderización previa de clientes.

Conclusión

Estas incorporaciones a la API de Speculation Rules permiten un uso mucho más sencillo de esta emocionante función de rendimiento nueva para sitios, con menos riesgo de desperdiciar recursos con especulaciones sin usar. Es emocionante ver que las plataformas ya recurren a esta API. Esperamos ver una adopción más amplia de esta API en 2024 y, en definitiva, un mejor rendimiento para los usuarios finales.

Además de las mejoras en el rendimiento que ofrece la API de Speculation Rules, también nos entusiasma ver las nuevas oportunidades que esto ofrece. Transiciones de vistas es una nueva API que permite a los desarrolladores especificar transiciones entre navegaciones con mayor facilidad. Actualmente, esta opción está disponible para aplicaciones de una sola página (SPA), pero la versión de varias páginas está en curso (y detrás de una marca en Chrome). La renderización previa es un complemento natural a esa función para garantizar que no haya retrasos, lo que evitaría la mejora de la experiencia del usuario que la transición pretende proporcionar. Ya vimos sitios que experimentan con esta combinación.

Esperamos seguir adoptando la API de Speculation Rules durante 2024 y te mantendremos al tanto de cualquier mejora que realicemos en la API.

Agradecimientos

Miniatura de Robbie Down en Unsplash