El equipo de Chrome trabajó en algunas actualizaciones interesantes de la API de Speculation Rules que se usa para mejorar el rendimiento de la navegación mediante la precarga o incluso la renderización previa de navegaciones futuras. Estas mejoras adicionales ahora están disponibles en Chrome 122 (con algunas funciones disponibles en versiones anteriores).
Estos cambios facilitan considerablemente la implementación de la precarga y la renderización previa de páginas, y reducen el desperdicio, lo que esperamos que fomente una mayor adopción.
Funciones adicionales
En primer lugar, se incluye una explicación de las nuevas incorporaciones que agregamos a la API de Speculation Rules y cómo usarlas. Después de esto, 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 la precarga o la renderización previa:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Las reglas de especulación eran semidinámicas en el sentido de que se podían agregar nuevas secuencias de comandos de reglas de especulación y quitar las secuencias de comandos anteriores 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, aún 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 esta lista de forma dinámica 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 siguiente navegación proviene de un pequeño conjunto de URLs obvias) o 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 quiera usar y, luego, se inserta en la página).
Como alternativa, nos complace ofrecer una nueva opción para encontrar vínculos automáticamente con reglas de documentos. Para ello, se obtienen URLs del documento en función de 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 en conjunto con las 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 solo conjunto de reglas de especulación en todo el sitio, en lugar de tener reglas específicas por página, lo que facilita mucho la implementación de reglas de especulación en los sitios.
Por supuesto, realizar una renderización previa de todos los vínculos de una página sería una pérdida de tiempo, por lo que, con esta nueva función, presentamos un parámetro de configuración eagerness.
Ansía
Con cualquier tipo de especulación, existe un equilibrio entre la precisión y la recuperación, y el tiempo de preparación. La renderización previa de todos los vínculos en la carga de la página significa que, casi con certeza, renderizarás previamente un vínculo en el que haga clic un usuario (suponiendo que haga clic en un vínculo del mismo sitio en la página) y con el mayor tiempo de preparación posible, pero con un desperdicio potencialmente enorme de ancho de banda.
Por otro lado, solo renderizar previamente una vez que un usuario hace clic en un vínculo evita el desperdicio, pero a costa de un tiempo de preparación mucho más reducido. Esto significa que es poco probable que se haya completado la renderización previa antes de que el navegador cambie a esa página.
La configuración de eagerness te permite definir cuándo deben ejecutarse las especulaciones, lo que separa cuándo especular de en qué URLs realizar las 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 que Chrome tiene las siguientes heurísticas:
immediate: Se usa para especular lo antes posible, es decir, ni bien se observan las reglas de especulación.eager: Actualmente, su comportamiento es idéntico al del parámetro de configuraciónimmediate, pero queremos ubicarlo en algún lugar entreimmediateymoderateen el futuro.moderate: Este parámetro realiza especulaciones cuando se coloca el cursor sobre un vínculo por 200 milisegundos (o en el eventopointerdown, si ocurre antes, y en dispositivos móviles, donde no se puede colocar el cursor sobre un elemento).hoverconservative: Este parámetro realiza una especulación sobre el puntero o el evento de toque.
El eagerness predeterminado para las reglas list es immediate. Las opciones moderate y conservative se pueden usar para limitar las reglas list a las URLs con las que un usuario interactúa en una lista específica. Sin embargo, en muchos casos, las reglas document con una condición where adecuada pueden ser más apropiadas.
El eagerness predeterminado para las reglas document es conservative. Dado que un documento puede constar de muchas URLs, el uso de immediate o eager para las reglas document debe usarse con precaución (consulta también la sección Límites de Chrome a continuación).
El parámetro de configuración eagerness que debes usar depende de tu sitio. En el caso de un sitio estático muy simple, especular con más entusiasmo puede tener un costo bajo y ser beneficioso para los usuarios. Es posible que los sitios con arquitecturas más complejas y cargas útiles de páginas más pesadas prefieran reducir el desperdicio especulando con menos frecuencia hasta que obtengan indicadores más positivos de la intención de los usuarios para limitar el desperdicio.
La opción moderate es un 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 se presiona el botón del mouse como una implementación básica, pero potente, 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 de 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 forma primero en entrar, primero en salir (FIFO). Después de alcanzar el límite, una nueva especulación hará que se cancele la especulación más antigua y se reemplace por la más reciente para conservar la 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. La configuración de immediate y eager no se activa con una acción del usuario y, por lo tanto, tiene un límite más alto, ya que el navegador no puede saber cuáles son necesarias y cuándo.
Una especulación que se cancela cuando se quita de la cola de FIFO se puede volver a activar (por ejemplo, si vuelves a colocar el cursor sobre ese vínculo), lo que hará que se vuelva a especular esa URL. En ese caso, es probable que la especulación anterior haya causado que el navegador almacene en caché algunos recursos en la caché HTTP de esa URL, por lo que repetir la especulación debería tener una red mucho más reducida y, por lo tanto, 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 con estos niveles de avidez, se creará capacidad cancelando esas especulaciones quitadas. Estas URLs también se pueden volver a especificar si se incluyen en una nueva secuencia de comandos de URL y no se alcanzó el límite.
Chrome también evitará que se usen especulaciones en ciertas condiciones, como las siguientes:
- Ahorro de datos.
- Ahorro de energía:
- Restricciones de memoria.
- Cuando el parámetro de configuración "Cargar páginas previamente" está desactivado (que también se desactiva de forma explícita con extensiones de Chrome, como uBlock Origin).
- Páginas abiertas en pestañas en segundo plano
El objetivo de todas estas condiciones es reducir el impacto de la especulación excesiva cuando sea 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 mediante un encabezado HTTP Speculation-Rules, en lugar de incluirlas directamente en el código HTML del documento. Esto permite que las CDN implementen el contenido de los documentos con mayor facilidad 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 varios orígenes, debe pasar una verificación de CORS.
Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *
Si deseas usar URLs relativas, te recomendamos que incluyas la clave "relative_to": "document" en tus reglas de especulación. De lo contrario, las URLs relativas serán relativas a la URL del archivo JSON de las reglas de especulación. Esto puede ser especialmente útil si necesitas seleccionar algunos (o todos) los vínculos del mismo origen.
Mejor reutilización de la caché
Realizamos varias 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 en el futuro, incluso si no se usa.
Esto también hace que la nueva especulación (por ejemplo, para las reglas de documentos con un parámetro de configuración de moderate de prioridad alta) 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 de No-Vary-Search para mejorar aún más la reutilización de la caché.
Compatibilidad con No-Vary-Search
Cuando se realiza la precarga o la renderización previa de una página, es posible que ciertos parámetros de URL (conocidos técnicamente como parámetros de búsqueda) no sean importantes para la página que entrega el servidor y que solo los use JavaScript del cliente.
Por ejemplo, Google Analytics utiliza los parámetros UTM para la medición de campañas, pero, por lo general, no genera 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, de modo que se pueda volver a usar la misma página desde la caché.
Del mismo modo, las aplicaciones pueden usar otros parámetros de URL que solo se controlan del lado del cliente.
La propuesta de No-Vary-Search permite que un servidor especifique parámetros que no generen diferencias en el recurso entregado y, por lo tanto, permita que un navegador vuelva a usar versiones almacenadas en caché de un documento que solo difieran en estos parámetros. Nota: Actualmente, esto solo se admite en Chrome (y navegadores basados en Chromium) para las especulaciones de navegación de precarga.
Las reglas de especulación admiten el uso de expects_no_vary_search para indicar dónde se espera que se devuelva un encabezado HTTP No-Vary-Search. Esto puede ayudar a evitar descargas innecesarias.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["/products*"],
"expects_no_vary_search": "params=(\"id\")"
}]
}
</script>
<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>
En este ejemplo, el código HTML de la página inicial /products es el mismo para los IDs de producto 123 y 124. Sin embargo, el contenido de la página difiere en función de la renderización del cliente con JavaScript para recuperar datos de productos con el parámetro de búsqueda id. Por lo tanto, precargamos esa URL con entusiasmo y debería mostrar un encabezado HTTP No-Vary-Search que muestre 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 entre recuperar el vínculo nuevamente o esperar a que se complete la carga previa para ver si contiene un encabezado HTTP No-Vary-Search. La configuración de expects_no_vary_search permite que el navegador sepa que se espera que la respuesta de la página contenga un encabezado HTTP No-Vary-Search y que espere a que se complete esa carga previa.
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 prioridad moderate en acción:
Abre DevTools y haz clic en el panel Application. Luego, en la sección Servicios en segundo plano, haz clic en Cargas especulativas, luego en el panel Especulaciones y ordena 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 el de una de las recetas, que no se renderiza 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 reglas de especulación para obtener más información sobre cómo usar DevTools para depurar reglas de especulación.
Compatibilidad de la plataforma con las reglas de especulación
Si bien las reglas de especulación son relativamente simples de implementar, ya que se insertan en un elemento <script type="speculationrules">, la compatibilidad con la plataforma puede hacer que esto sea un asunto de un solo 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 API emocionante si así lo desean.
WordPress
El equipo de rendimiento principal de WordPress (incluidos los desarrolladores de Google) creó un complemento de Speculation Rules. Este complemento permite agregar compatibilidad con reglas de documentos a cualquier sitio de WordPress con un solo clic. Este complemento también está disponible para instalarse a través del complemento WordPress Performance Lab, que también deberías considerar instalar, ya que te mantendrá al tanto de los complementos de rendimiento relacionados del equipo.
Hay dos grupos de parámetros de configuración disponibles: el modo de especulación y el parámetro de configuración Eagerness:
Para configuraciones más complicadas (por ejemplo, para excluir ciertas URLs de la precarga o la renderización previa), lee la documentación.
Akamai
Akamai es uno de los proveedores de CDN líderes del mundo y lleva tiempo experimentando de forma activa con la API de Speculation Rules. Akamai publicó documentación sobre cómo los clientes pueden habilitar esta API en la configuración de su CDN. También compartieron los resultados impresionantes que se pueden obtener con esta nueva API.
NitroPack
NitroPack es una solución de optimización del rendimiento que usa su IA de navegación personalizada para predecir qué páginas agregar a las reglas de especulación, lo que tiene como objetivo proporcionar un tiempo de preparación más largo que el que se obtiene cuando se coloca 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 las reglas de especulación de Nitropack para obtener más información. Esta solución innovadora demuestra que las reglas de lista más antiguas aún tienen mucho para ofrecer cuando se combinan con estadísticas específicas del sitio.
El equipo de Chrome también trabajó con NitroPack en un seminario en línea sobre la API de Speculation Rules para quienes buscan más información, incluida una buena discusión sobre las consideraciones necesarias entre especular con anticipación y con frecuencia, así como con retraso y con menos frecuencia.
Astrofotografía
Astro agregó páginas de renderización previa con la API de Speculation Rules en la versión 4.2 de forma experimental, lo que permite que los desarrolladores que usan Astro habiliten esta función con facilidad y, al mismo tiempo, recurran a una carga previa estándar para los navegadores que no admiten la API de Speculation Rules. Para obtener más información, consulta su documentación sobre la renderización previa del cliente.
Conclusión
Estas incorporaciones a la API de Speculation Rules permiten un uso mucho más sencillo de esta nueva y emocionante función de rendimiento para los sitios, con menos riesgo de desperdiciar recursos con especulaciones sin usar. Es emocionante ver que las plataformas ya se apoyan en esta API. Esperamos que esta API se adopte de forma más amplia en 2024 y, en última instancia, que los usuarios finales obtengan un mejor rendimiento como resultado.
Además de los aumentos de rendimiento que proporciona la API de Speculation Rules, también nos entusiasma ver qué nuevas oportunidades abre. View Transitions es una nueva API que permite a los desarrolladores especificar transiciones entre navegaciones con mayor facilidad. Actualmente, está disponible para aplicaciones de una sola página (SPA), pero la versión de varias páginas está en proceso (y está disponible detrás de una marca en Chrome). El renderizado previo es un complemento natural de esa función para garantizar que no haya demoras, lo que, de otro modo, impediría la mejora de la experiencia del usuario que se pretende proporcionar con la transición. Ya vimos sitios que experimentan con esta combinación.
Esperamos que se adopte más la API de Speculation Rules a lo largo de 2024 y te mantendremos al tanto de las mejoras que realicemos en la API.
Agradecimientos
Miniatura de Robbie Down en Unsplash