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>
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ónimmediate
, pero, en el futuro, deseamos ubicarlo en algún lugar entreimmediate
ymoderate
.moderate
: Realiza especulaciones si colocas el cursor sobre un vínculo durante 200 milisegundos (o en el eventopointerdown
, si ocurre antes, y en dispositivos móviles donde no hay un eventohover
).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.
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) |
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"
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:
![Captura de pantalla de un sitio de demostración creado en glitch con varios vínculos etiquetados con frutas. Herramientas para desarrolladores está abierto y muestra que dos de los vínculos (apple.html y naranja.html) ya se renderizaron previamente de forma correcta.](https://developer.chrome.com/static/blog/speculation-rules-improvements/images/speculation-rules-demo.png?authuser=5&hl=es)
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:
![Captura de pantalla del panel de lectura de la configuración de WordPress con la configuración de las reglas de especulación. Existen dos opciones: el modo de especulación con la opción de carga previa o renderización previa, y una configuración de veloz con configuración conservadora, moderada o veloz.](https://developer.chrome.com/static/blog/speculation-rules-improvements/images/wordpress-speculation-rules.png?authuser=5&hl=es)
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