Mejoras en la API de Speculation Rules

Barry Pollard

El equipo de Chrome ha estado trabajando en algunas actualizaciones interesantes de la API de Speculation Rules que se utilizan para mejorar el rendimiento de la navegación mediante la carga previa o incluso la renderización previa de navegaciones futuras. Todas estas mejoras adicionales ahora están disponibles a partir de Chrome 122 (con algunas funciones disponibles de versiones anteriores).

Estos cambios hacen que la carga previa y la renderización previa de páginas sean considerablemente más fáciles de implementar y menos desperdicios, lo que esperamos que fomente una mayor adopción.

Características adicionales

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

Reglas de documentos

Anteriormente, la API de Speculation Rules funcionaba especificando una lista de URLs para carga previa o renderización previa:

<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 descartar esas especulaciones (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 que el sitio escogiera la elección de las URLs, ya sea enviándolas desde el servidor en el momento de la solicitud de la página o mediante la creación dinámica de esta lista a través del código JavaScript del cliente.

Las reglas de lista permanecen como una opción para casos de uso más sencillos (en los que la siguiente navegación es de un conjunto pequeño de elementos obvios) o casos de uso más avanzados (donde la lista de URLs se calcula de forma dinámica en función de la heurística que el propietario del sitio desea usar y, luego, se inserta 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. Para ello, se obtienen las URLs del documento en función de una condición where. Esto se puede basar en los vínculos:

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

Los selectores CSS también se pueden usar como alternativa o en conjunto con las coincidencias 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 que los sitios implementen reglas de especulación.

Como es evidente, el procesamiento previo de todos los vínculos de una página sería un desperdicio. Por eso, con esta nueva función, incorporamos una configuración eagerness.

Impulso

Con cualquier tipo de especulación, existe un equilibrio entre precisión y recuperación y el plazo de entrega. El procesamiento previo de todos los vínculos durante la carga de la página significa que seguramente harás un procesamiento previo de un vínculo en el que hace clic un usuario (suponiendo que hace clic en un vínculo del mismo sitio en la página), con el mayor tiempo de antelación posible, pero con un desperdicio potencialmente enorme de ancho de banda.

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

El parámetro de configuración eagerness te permite definir cuándo se deben ejecutar las especulaciones y separar cuándo especular sobre las URLs sobre las que se deben realizar especulaciones. 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 utiliza la siguiente heurística:

• immediate: Se usa para especular lo antes posible, es decir, en cuanto se observen las reglas de especulación.
• eager: Actualmente, este parámetro se comporta de la misma manera que el parámetro de configuración immediate, pero, en el futuro, esperamos colocarlo entre immediate y moderate.
• moderate: Realiza especulaciones si colocas el cursor sobre un vínculo durante 200 milisegundos (o sobre el evento pointerdown, si es 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 con 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 varias 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 se use depende de tu sitio. En el caso de un sitio estático muy simple, especular con más entusiasmo 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áginas más pesadas prefieran reducir el desperdicio mediante especulaciones con menos frecuencia hasta que obtengas una señal más positiva de intención de los usuarios para limitar el desperdicio.

La opción moderate es un punto intermedio, y muchos sitios podrían beneficiarse de la siguiente regla de especulación simple que renderizaría previamente todos los vínculos al colocar el cursor sobre un elemento o hacer clic en él hacia abajo como una implementación básica, pero poderosa, de 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 de eagerness, Chrome tiene límites para evitar el uso excesivo de esta API:

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 especulación nueva hará que se cancele la especulación más antigua y se reemplace por la más nueva para conservar memoria.

El hecho de que los usuarios activen las especulaciones de moderate y conservative nos permite usar un umbral más modesto de 2 para conservar la memoria. Los parámetros de configuración de immediate y eager no se activan con una acción del usuario, por lo que deben tener un límite más alto, ya que no es posible que el navegador sepa cuáles y cuándo se necesitan.

Una especulación que se cancela cuando se la quita de la cola FIFO se puede activar de nuevo (por ejemplo, si se coloca el cursor sobre ese vínculo otra vez), lo que hará que se vuelva a especular esa URL. En ese caso, es probable que la especulación anterior haya provocado que el navegador almacene en caché algunos recursos de la caché HTTP para esa URL, por lo que repetir la especulación debería reducir mucho el costo de la red y, por lo tanto, el costo del tiempo.

Los límites immediate y eager también son dinámicos. Quitar un elemento de la secuencia de comandos de reglas de especulación que usa estos niveles de rapidez creará capacidad mediante la cancelación de las especulaciones eliminadas. También es posible volver a especular sobre estas URLs si se incluyen en una secuencia de comandos de URL nueva y no se alcanzó el límite.

Chrome también evitará que se usen especulaciones en determinadas condiciones, entre las que se incluyen las siguientes:

• Save-Data:
• Ahorro de energía.
• Restricciones de memoria.
• Cuando aparezca el cuadro de diálogo el parámetro de configuración esté desactivado (lo que también se desactivará explícitamente con las extensiones de Chrome, como uBlock Origin).
• Páginas abiertas en pestañas en segundo plano.

Todas estas condiciones tienen como objetivo reducir el impacto de la sobreespeculación cuando sería perjudicial para los usuarios.

source opcional

Chrome 122 hace que la clave source sea opcional, ya que se puede inferir de la presencia de las claves 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 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 una 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 origen cruzado, pasar una verificación de CORS.

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

Si quieres usar URLs relativas, puedes incluir 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 particularmente útil si necesitas seleccionar algunos (o todos) vínculos del mismo origen.

Mejor reutilización de caché

Realizamos una serie de mejoras en el almacenamiento en caché en Chrome, de modo que la carga previa (o incluso el procesamiento previo) de un documento almacene y reutilice recursos en la caché HTTP. Esto significa que la especulación puede tener beneficios futuros, aunque no se use esa especulación.

Esto también hace que la reespeculación (por ejemplo, para reglas de documentos con un parámetro de configuración de velocidad moderate) sea considerablemente más económico, ya que Chrome usará la caché HTTP para los recursos que pueden almacenarse en caché.

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

Compatibilidad con No-Vary-Search

Cuando se realiza una carga previa o se renderiza previamente una página, es posible que ciertos parámetros de URL (técnicamente conocidos como parámetros de búsqueda) no tengan importancia para la página entregada por el servidor y que solo los use el código JavaScript del cliente.

Por ejemplo, Google Analytics utiliza los parámetros de UTM para las mediciones de una campaña, pero no suelen implicar que el servidor envíe diferentes páginas. 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 puede 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 manejan 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 previamente almacenadas en caché de un documento que solo difieren en estos parámetros. Nota: Actualmente, 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 ayudar a evitar más 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 del 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 expects_no_vary_search le permite al navegador saber que se espera que la respuesta de la página contenga un encabezado HTTP No-Vary-Search y esperar 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 reglas de documentos con un parámetro de configuración de nivel de atención moderate en acción:

Abre Herramientas para desarrolladores, 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 especulaciones y ordénalas por la columna Estado.

Cuando coloques el cursor sobre las frutas, verás la renderización previa de las páginas. Si haces clic en ellos, se mostrará un tiempo de LCP mucho más rápido que en 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 la depuración de las reglas de especulación para obtener más información sobre cómo usar las Herramientas para desarrolladores para depurar reglas de especulación.

Compatibilidad de la plataforma con reglas de especulación

Si bien las reglas de especulación son relativamente fáciles de implementar cuando se las inserta en un elemento <script type="speculationrules">, la compatibilidad con la plataforma puede hacer que esto sea una cuestión de un clic. Trabajamos con varias plataformas y socios para facilitar el lanzamiento de las reglas de especulación.

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

WordPress

El equipo de rendimiento básico de WordPress (incluidos los desarrolladores de Google) creó un complemento de Speculation Rules. Este complemento permite agregar con un solo clic la compatibilidad con las reglas de los documentos a cualquier sitio de WordPress. Este complemento también se puede instalar a través del complemento WordPress Performance Lab. También puedes instalarlo para mantenerte actualizado sobre los complementos de rendimiento relacionados del equipo.

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

Para configuraciones más complicadas (por ejemplo, para excluir ciertas URLs de la carga previa o la renderización previa), consulta la documentación.

Akamai

Akamai es uno de los principales proveedores de CDN del mundo y hace tiempo que está experimentando de manera activa con la API de Speculation Rules. Akamai publicó documentación sobre cómo los clientes pueden habilitar esta API en su configuración de CDN. En el pasado, también compartieron los impresionantes resultados posibles con esta nueva API.

NitroPack

NitroPack es una solución de optimización del rendimiento que usa su Navigation AI personalizado para predecir qué páginas agregar a las reglas de especulación. Su objetivo es proporcionar un plazo de entrega más largo que situar el cursor sobre un vínculo, pero sin el desperdicio de especular innecesariamente sobre todos los vínculos observados. Consulta la documentación de la API de Nitropack Speculation Rules para obtener más información. Esta solución innovadora demuestra que aún hay mucho que ofrecer las reglas de listas anteriores cuando se combinan con estadísticas específicas de sitios.

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

Astrofotografía

Astro agregó de manera experimental la renderización previa de páginas con la API de Speculation Rules en la versión 4.2, lo que permite a los desarrolladores que usan Astro habilitar esta función con facilidad y recurre a una carga previa estándar para los navegadores que no admiten la API de Speculation Rules. Lee la documentación sobre renderización previa del cliente para obtener más información.

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 y emocionante para sitios, con un riesgo menor de desperdiciar recursos con especulaciones que no se utilizan. Es emocionante ver que las plataformas ya utilizan esta API. Esperamos ver una adopción más amplia de esta API en 2024 y, en última instancia, 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 abre. Transiciones de vistas es una API nueva que permite a los desarrolladores especificar transiciones entre navegaciones con mayor facilidad. Actualmente, esta opción está disponible para las aplicaciones de una sola página (SPA), pero la versión de varias páginas está en curso (y está disponible detrás de una función experimental en Chrome). La renderización previa es un complemento natural de esa función para garantizar que no haya retrasos, lo que impediría la mejora de la experiencia del usuario que se pretende proporcionar con la transición. Ya hemos visto sitios que están experimentando con esta combinación.

Esperamos seguir adoptando la API de Speculation Rules durante el 2024 y te mantendremos al tanto de las mejoras que realicemos en la API.

Agradecimientos

Miniatura de Robbie Down en Unsplash