Navegadores compatibles
El equipo de Chrome volvió a habilitar la renderización previa completa de las páginas futuras a las que es probable que navegue un usuario.
Breve historia del renderización previa
En el pasado, Chrome admitía la sugerencia de recursos <link rel="prerender" href="/next-page">
. Sin embargo, no era ampliamente compatible fuera de Chrome y no era una API muy expresiva.
Esta renderización previa heredada con la sugerencia de vínculo rel=prerender
dejó de estar disponible a favor de la carga previa sin estado, que recuperaba los recursos que necesitaba la página futura, pero no renderizaba la página por completo ni ejecutaba JavaScript. La carga previa sin estado ayuda a mejorar el rendimiento de la página, ya que mejora la carga de recursos, pero no proporciona una carga de página instantánea como lo haría una renderización previa completa.
El equipo de Chrome volvió a implementar 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 se mantendrá para la precarga sin estado, con la intención de retirarla en algún momento en el futuro.
¿Cómo se renderiza previamente una página?
Una página se puede renderizar previamente de una de las siguientes cuatro maneras, todas las cuales tienen como objetivo hacer que las navegaciones sean más rápidas:
- Cuando escribes una URL en la barra de direcciones de Chrome (también conocida como "cuadro multifunción"), es posible que Chrome renderice automáticamente la página por ti, si tiene una alta confianza de que la visitarás, según tu historial de navegación anterior.
- Cuando usas la barra de favoritos, es posible que Chrome renderice previamente la página automáticamente si mantienes el puntero sobre uno de los botones de favoritos.
- Cuando escribes un término de búsqueda en la barra de direcciones de Chrome, es posible que el navegador renderice previamente la página de resultados de la búsqueda automáticamente, si el motor de búsqueda le indica que lo haga.
- Los sitios pueden usar la API de Speculation Rules para indicarle a Chrome de forma programática qué páginas renderizar previamente. Esto reemplaza lo que solía hacer
<link rel="prerender"...>
y permite que los sitios rendericen de forma previa una página de forma proactiva en función de las reglas de especulación en la página. Pueden existir de forma estática en las páginas o inyectarse de forma dinámica con JavaScript según lo considere conveniente 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 una página se activa antes de que se renderice por completo, su estado actual se "pone en primer plano" y sigue 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, una serie de APIs que causan comportamientos intrusivos (por ejemplo, instrucciones) no se activan en este estado y, en su lugar, se retrasan hasta que se activa la página. En los pocos 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 para mejorar las capacidades de DevTools para facilitar la identificación de esos casos extremos.
Impacto de la renderización previa
La renderización previa permite una carga de página casi instantánea, como se muestra en el siguiente video:
El sitio de ejemplo ya es 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 en la carga de la página debería mejorar la experiencia de carga. Cuando se activa un vínculo mientras aún se está realizando la renderización previa, la página con renderización previa se moverá al marco principal y continuará cargándose.
Sin embargo, la renderización previa usa memoria y ancho de banda de red adicionales. Ten cuidado de no realizar una renderización previa excesiva, ya que esto puede afectar los recursos del usuario. Solo realiza la renderización previa cuando haya una alta probabilidad de que se navegue a 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 del rendimiento en tus estadísticas.
Cómo 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
:
Las líneas verdes indican que hay suficiente confianza para activar la renderización previa. En este ejemplo, escribir "s" proporciona una confianza razonable (ámbar), pero una vez que escribes "sh", Chrome tiene suficiente confianza como para saber que casi siempre navegas a https://sheets.google.com
.
Esta captura de pantalla se tomó en una instalación de Chrome relativamente reciente y se filtraron las predicciones de confianza cero, pero si ves tus propios predictores, es probable que veas muchas más entradas y, posiblemente, más caracteres necesarios para alcanzar un nivel de confianza lo suficientemente alto.
Estos predictores también son los que generan las opciones sugeridas de la barra de direcciones que quizás hayas notado:
Chrome actualizará continuamente sus predictores en función de lo que escribas y selecciones.
- Si el nivel de confianza es superior al 50% (se muestra en ámbar), Chrome se conecta de forma anticipada al dominio de forma proactiva, pero no renderiza la página de forma anticipada.
- Si el nivel de confianza es superior al 80% (se muestra en verde), Chrome renderizará previamente la URL.
La API de Speculation Rules
En el caso de la opción de renderización previa de la API de Speculation Rules, los desarrolladores web pueden insertar instrucciones JSON en sus páginas para informar al navegador sobre qué URLs renderizar previamente:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
O bien por reglas de documentos (disponibles a partir de Chrome 121), que renderizan previamente los vínculos que se encuentran en el documento según los selectores href
(basados en la API de patrones de URL) o los selectores CSS:
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/wp-admin"}},
{ "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
{ "not": {"selector_matches": ".do-not-prerender"}},
{ "not": {"selector_matches": "[rel~=nofollow]"}}
]
}
}]
}
</script>
El equipo de Chrome preparó un codelab de Speculation Rules en el que se explica cómo agregar Speculation Rules a un sitio.
Ansía
Navegadores compatibles
Se usa una configuración eagerness
para indicar cuándo deben activarse las especulaciones, lo que es particularmente útil para las reglas de documentos:
immediate
: Se usa para especular lo antes posible, es decir, ni bien se observan las reglas de especulación.eager
: Su comportamiento es idéntico al del parámetro de configuraciónimmediate
, pero queremos ubicarlo en algún lugar entreimmediate
ymoderate
más adelante.moderate
: Este parámetro realiza especulaciones si mantienes el puntero 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
: 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 y ligero, 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 término medio, y muchos sitios podrían beneficiarse de la siguiente regla de especulación que renderizaría previamente un vínculo cuando se mantenga el puntero sobre él durante 200 milisegundos o en el evento de abajo del puntero como una implementación básica, pero potente, 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 para recuperar páginas de antemano, sin una renderización previa completa. A menudo, este puede ser un buen primer paso en el camino hacia la renderización previa:
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["next.html", "next2.html"]
}
]
}
</script>
Límites de Chrome
Chrome tiene límites para evitar el uso excesivo de la API de Speculation Rules:
anhelo | 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 manera 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. Una especulación cancelada 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 sobre esa URL y se elimine la especulación más antigua. En este caso, la especulación anterior habrá almacenado en caché todos los recursos almacenables en la caché HTTP de esa URL, por lo que especular una vez más debería tener un costo reducido. Por este motivo, el límite se establece en el umbral modesto de 2. Las reglas de lista estáticas no se activan con una acción del usuario y, por lo tanto, tienen un límite más alto, ya que el navegador no puede saber cuáles son necesarias y cuándo.
Los límites de immediate
y eager
también son dinámicos, por lo que quitar un elemento de secuencia de comandos de URL list
creará capacidad, ya que cancelará esas especulaciones quitadas.
Chrome también evitará que se usen especulaciones en ciertas condiciones, como las siguientes:
- Ahorro de datos.
- Ahorro de energía cuando está habilitado y la batería está baja
- 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
Chrome tampoco renderiza iframes de origen cruzado en páginas renderizadas previamente hasta que se activan.
El objetivo de todas estas condiciones es reducir el impacto de la especulación excesiva cuando sea perjudicial para 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 insertarse de forma dinámica en la página con JavaScript:
- Reglas de especulación incluidas de forma estática: Por ejemplo, un sitio de noticias o un blog puede renderizar previamente el artículo más reciente, si ese es el siguiente vínculo que suele visitar una gran proporción de usuarios. Como alternativa, se pueden usar reglas de documentos con un
moderate
oconservative
para especular a medida que los usuarios interactúan con los 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.
Se recomienda que quienes prefieran la inserción dinámica basada en acciones como colocar el cursor sobre un vínculo o hacer clic en él (como lo hicieron muchas bibliotecas en el pasado con <link rel=prefetch>
) revisen las reglas de documentos, ya que permiten que el navegador controle muchos de tus casos de uso.
Las reglas de especulación se pueden agregar en <head>
o <body>
del marco principal. No se aplican las reglas de especulación en los submarcos, y las reglas de especulación en las páginas renderizadas de forma previa solo se aplican una vez que se activa esa página.
El 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.
Reglas de especulación y SPA
Las reglas de especulación solo son compatibles con las navegaciones de página completa que administra el navegador, no con las apps de una sola página (SPA) ni con las páginas de shell de la app. Esta arquitectura no usa recuperaciones de documentos, sino que realiza recuperaciones parciales o de API de datos o páginas, que luego se procesan y presentan en la página actual. La app puede recuperar previamente los datos necesarios para estas llamadas "navegaciones suaves" fuera de las reglas de especulación, pero no se pueden renderizar previamente.
Las reglas de especulación se pueden usar para renderizar de forma previa la aplicación desde una página anterior. Esto puede ayudar a compensar algunos de los costos de carga iniciales adicionales que tienen algunos SPA. Sin embargo, los cambios de ruta dentro de la app no se pueden renderizar previamente.
Cómo depurar reglas de especulación
Consulta la entrada dedicada a las reglas de especulación de depuración para conocer las nuevas funciones de Chrome DevTools 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 se agregan a las reglas existentes. Por lo tanto, las siguientes formas diferentes generan una renderización previa de one.html
y two.html
:
Lista de URLs:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html", "two.html"]
}
]
}
</script>
Varias secuencias de comandos speculationrules
:
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
}
]
}
</script>
<script type="speculationrules">
{
"prerender": [
{
"urls": ["two.html"]
}
]
}
</script>
Varias listas dentro de un conjunto de speculationrules
<script type="speculationrules">
{
"prerender": [
{
"urls": ["one.html"]
},
{
"urls": ["two.html"]
}
]
}
</script>
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 una diferencia 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. Esto es compatible con Chrome (y navegadores basados en Chromium) para las especulaciones de navegación de precarga (aunque estamos buscando también admitir esto para la renderización previa).
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.
Restricciones de las reglas de especulación y mejoras futuras
Las reglas de especulación se limitan a las páginas que se abren en la misma pestaña, pero estamos trabajando para reducir esa restricción.
De forma predeterminada, las especulaciones se restringen a las páginas del mismo origen. Especulación de páginas del mismo sitio de origen cruzado (por ejemplo, https://a.example.com
podría renderizar previamente una página en https://b.example.com
). Para usar esta función, la página especulada (https://b.example.com
en este ejemplo) debe habilitarla mediante la inclusión de un encabezado HTTP Supports-Loading-Mode: credentialed-prerender
, o Chrome cancelará la especulación.
Es posible que las versiones futuras también permitan la renderización previa de páginas de origen cruzado que no sean del mismo sitio, siempre y cuando no existan cookies para la página renderizada previamente y esta acepte un encabezado HTTP Supports-Loading-Mode: uncredentialed-prerender
similar.
Las reglas de especulación ya admiten la carga previa entre orígenes, pero solo cuando no existen cookies para el dominio entre orígenes. Si existen cookies del usuario que visitó ese sitio anteriormente, no se activará la especulación y se mostrará un error en DevTools.
Teniendo en cuenta esas limitaciones actuales, un patrón que puede mejorar la experiencia de los usuarios en los vínculos internos y externos, siempre que sea posible, es renderizar previamente las URLs del mismo origen y tratar de recuperar previamente las URLs de origen cruzado:
<script type="speculationrules">
{
"prerender": [
{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}
],
"prefetch": [
{
"where": { "not": { "href_matches": "/*" } },
"eagerness": "moderate"
}
]
}
</script>
La restricción para evitar especulaciones de origen cruzado para vínculos de origen cruzado de forma predeterminada es necesaria para la seguridad. Es una mejora con respecto a <link rel="prefetch">
para los destinos de varios orígenes, que tampoco enviarán cookies, pero intentarán la carga previa, lo que generará una carga previa desperdiciada que se deberá volver a enviar o, lo que es peor, la carga incorrecta de la página.
Las reglas de especulación no son compatibles con la precarga de páginas controladas por trabajadores del servicio. Estamos trabajando para agregar esta compatibilidad. Sigue este problema de trabajador del servicio de asistencia para obtener actualizaciones. La renderización previa es compatible con las páginas controladas por el trabajador del servicio.
Detecta la compatibilidad con la API de Speculation Rules
Puedes detectar la compatibilidad con la API de Speculation Rules con verificaciones 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 la inserción de JavaScript, en esta página de demostración de renderización previa.
Si insertas un elemento <script type = "speculationrules">
directamente en el DOM con innerHTML
, no se registrarán las reglas de especulación por motivos de seguridad, y se deben agregar como se muestra anteriormente. Sin embargo, el contenido insertado de forma dinámica con innerHTML
que contiene vínculos nuevos se detectará con las reglas existentes en la página.
Del mismo modo, editar directamente el panel Elementos en Herramientas para desarrolladores de Chrome para agregar el elemento <script type = "speculationrules">
no registra las reglas de especulación y, en su lugar, la secuencia de comandos para agregarlo de forma dinámica al DOM se debe ejecutar desde la consola para insertar las reglas.
Agrega reglas de especulación a través de un administrador de etiquetas
Para agregar reglas de especulación con un administrador de etiquetas como Google Tag Manager (GTM), es necesario que se inserten a través de JavaScript, en lugar de agregar el elemento <script type = "speculationrules">
directamente a través de GTM por los mismos motivos que se mencionaron anteriormente:
Ten en cuenta que este ejemplo usa var
, ya que GTM no admite const
.
Cancela las reglas de especulación
Si quitas las reglas de especulación, se cancelará la renderización previa, pero, cuando esto suceda, es probable que ya se hayan invertido recursos para iniciar la renderización previa, por lo que se recomienda no realizar la renderización previa si es probable que debas cancelarla.
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 la Content-Security-Policy script-src
si el sitio la usa, ya sea con un hash o un nonce.
Se puede agregar una nueva inline-speculation-rules
a script-src
, lo que permite admitir elementos <script type="speculationrules">
insertados desde secuencias de comandos de hash o nonce. No admite reglas incluidas en el HTML inicial, por lo que JavaScript debe insertar reglas para los sitios que usan un CSP estricto.
Cómo detectar y, luego, 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 de páginas rápida, a menudo 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 puede ser difícil de lograr de otra manera.
Sin embargo, puede haber casos en los que no quieras que se realice 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 de la ejecución de JavaScript en la página.
Habilita y desactiva la renderización previa en Chrome
La prerenderización solo está habilitada para los usuarios de Chrome que tienen la configuración "Cargar páginas previamente" en chrome://settings/performance/
. Además, la renderización previa también se inhabilita en 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 y, luego, 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 que se precargaron con la API de Speculation Rules tendrán este encabezado configurado solo en 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 produzca una renderización previa. Si se muestra un código de respuesta final que no es correcto (es decir, no está en el rango de 200 a 299 después de los redireccionamientos), la página no se renderizará previamente y se descartará cualquier página de precarga. Ten en cuenta también que las respuestas 204 y 205 no son válidas para la renderización previa, pero sí para la carga previa.
Si no quieres que se renderice previamente una página en particular, la mejor manera de garantizar que no suceda es mostrar un código de respuesta que no sea 2XX (como 503). Sin embargo, para ofrecer la mejor experiencia, se recomienda permitir la renderización previa, pero retrasar las acciones que solo deben ocurrir cuando se ve la página, con JavaScript.
Cómo detectar el renderizado previo en JavaScript
La API de document.prerendering
mostrará true
mientras se renderiza previamente la página. Las páginas pueden usar esta función para evitar o retrasar ciertas actividades durante la renderización previa hasta que la página se active.
Una vez que se active un documento renderizado previamente, el activationStart
de PerformanceNavigationTiming
también se establecerá en un tiempo distinto de cero que representará el tiempo entre el inicio de la renderización previa y el momento en que se activó el documento.
Puedes tener una función para verificar si hay páginas renderizadas previamente y renderizadas, como la siguiente:
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 (ya sea de forma completa o parcial) es abrir DevTools después de que se active la página y escribir performance.getEntriesByType('navigation')[0].activationStart
en la consola. Si se muestra un valor distinto de cero, significa que la página se renderizó previamente:
Cuando el usuario que ve la página la active, se enviará el evento prerenderingchange
en document
, que se puede usar para habilitar actividades que, anteriormente, se iniciaban de forma predeterminada cuando se cargaba la página, pero que deseas retrasar hasta que el usuario realmente vea la página.
Con estas APIs, el código JavaScript del frontend puede detectar y actuar sobre las páginas renderizadas previamente de forma adecuada.
Impacto en las estadísticas
Las estadísticas se utilizan para medir el uso de los sitios web, por ejemplo, con 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 supervisión de usuarios reales (RUM).
Las páginas solo deben renderizarse previamente cuando haya una alta probabilidad de que el usuario las cargue. Por este motivo, las opciones de renderización previa de la barra de direcciones de Chrome solo se aplican cuando hay una probabilidad tan alta (más del 80% de las veces).
Sin embargo, en particular 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 del sitio deban agregar código adicional para habilitar solo las estadísticas de las páginas renderizadas previamente en la activación, ya que no todos los proveedores de estadísticas pueden hacerlo de forma predeterminada.
Esto se puede lograr con un Promise
que espera el evento prerenderingchange
si un documento está en renderización previa o se resuelve de inmediato si está en uno de los siguientes estados:
// 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, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialise your analytics
}
initAnalytics();
Un enfoque alternativo es retrasar las actividades analíticas hasta que la página se haga visible por primera vez, lo que abarcaría el caso de la renderización previa y también cuando se abren pestañas en segundo plano (por ejemplo, con el clic derecho y abrir en una pestaña nueva):
// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
if (document.hidden) {
document.addEventListener('visibilitychange', resolve, {once: true});
} else {
resolve();
}
});
async function initAnalytics() {
await whenFirstVisible;
// Initialise your analytics
}
initAnalytics();
Si bien esto puede tener sentido para las estadísticas y casos de uso similares, en otros casos, es posible que desees que se cargue más contenido para esos casos, por lo que te recomendamos que uses document.prerendering
y prerenderingchange
para segmentar específicamente las páginas de renderización previa.
Retener otro contenido durante la renderización previa
Las mismas APIs que se analizaron anteriormente se pueden usar para retener otro contenido durante la fase de renderización previa. Pueden ser partes específicas de JavaScript o elementos completos de la secuencia de comandos que prefieras no ejecutar durante la etapa de renderización previa.
Por ejemplo, con esta secuencia de comandos:
<script src="https://example.com/app/script.js" async></script>
Puedes cambiar esto a un elemento de secuencia de comandos insertado de forma dinámica que solo se inserta en función de la función whenActivated
anterior:
async function addScript(scriptUrl) {
await whenActivated;
const script = document.createElement('script');
script.src = 'scriptUrl';
document.body.appendChild(script);
}
addScript('https://example.com/app/script.js');
Esto puede ser útil para retener secuencias de comandos distintas que incluyen estadísticas o renderizar contenido en función del estado o de otras variables que pueden cambiar durante el período de una visita. Por ejemplo, se pueden retener las recomendaciones, el estado de acceso o los íconos del carrito de compras para garantizar que se presente la información más actualizada.
Si bien es más probable que esto suceda con el uso de la renderización previa, estas condiciones también son verdaderas para las páginas cargadas en las pestañas en segundo plano mencionadas anteriormente (por lo que se podría usar la función whenFirstVisible
en lugar de whenActivated
).
En muchos casos, lo ideal es que el estado también se verifique en los cambios generales de visibilitychange
; por ejemplo, cuando se vuelve a una página que estaba en segundo plano, los contadores de la canasta de compras deben actualizarse con la cantidad más reciente de artículos en la canasta. Por lo tanto, este no es un problema específico de la renderización previa, sino que la renderización previa solo hace que un problema existente sea más evidente.
Una forma en que Chrome mitiga parte de la necesidad de unir manualmente secuencias de comandos o funciones es que ciertas APIs se retienen, como se mencionó anteriormente, y tampoco se renderizan los iframes de terceros, por lo que solo el contenido adicional es el que se debe retener de forma manual.
Cómo medir el rendimiento
Para medir las métricas de rendimiento, las estadísticas deben 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, su objetivo es medir la experiencia del usuario. Por lo tanto, se miden en función del tiempo de activación. Esto suele generar una LCP de 0 segundos, lo que demuestra que esta es una excelente manera de mejorar tus Métricas web esenciales.
A partir de la versión 3.1.0, la biblioteca web-vitals
se actualizó para controlar las navegaciones renderizadas previamente de la misma manera que Chrome mide las métricas principales de la Web. Esta versión también marca las navegaciones renderizadas previamente para esas métricas en el atributo Metric.navigationType
si la página se renderizó de forma parcial o total.
Cómo medir las renderizaciones previas
Se puede ver si una página se renderizó previamente con una entrada activationStart
distinta de cero de PerformanceNavigationTiming
. Esto se puede registrar con una dimensión personalizada o algo similar cuando se registran las vistas de página, por ejemplo, con la función pagePrerendered
que se describió 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 se renderizan previamente en comparación con otros tipos de navegación y también te permitirá correlacionar cualquier métrica de rendimiento o métrica empresarial con estos diferentes tipos de navegación. Las páginas más rápidas generan más satisfacción entre los usuarios, lo que, a menudo, puede tener un impacto real en las medidas comerciales, como muestran nuestros casos de éxito.
A medida que midas el impacto comercial de la renderización previa de páginas para navegaciones instantáneas, podrás decidir si vale la pena invertir más esfuerzo en usar esta tecnología para permitir que se rendericen previamente más navegaciones o investigar por qué no se renderizan previamente las páginas.
Cómo medir las tasas de aciertos
Además de medir el impacto de las páginas que se visitan después de una renderización previa, también es importante medir las páginas que se renderizan previamente y que no se visitan posteriormente. Esto podría implicar que estás realizando la renderización previa en exceso y que estás agotando recursos valiosos del usuario con poco beneficio.
Para medir esto, se puede activar un evento de Analytics cuando se insertan reglas de especulación (después de verificar que el navegador admita 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 haya iniciado o completado, ya que, como se señaló anteriormente, una renderización previa es una sugerencia para el navegador y este puede optar por no renderizar páginas en la configuración del usuario, el uso actual de la memoria y otras heurísticas).
Luego, puedes comparar la cantidad de estos eventos con las vistas de página de renderización previa reales. Como alternativa, activa otro evento en la activación si eso facilita la comparación.
Luego, se puede aproximar el "porcentaje de hits correctos" observando la diferencia entre estas dos cifras. En el caso de las páginas en las que usas la API de Speculation Rules para renderizarlas previamente, puedes ajustar las reglas de manera adecuada para asegurarte de mantener una tasa de hits alta y mantener el equilibrio entre usar los recursos de los usuarios para ayudarlos y usarlos innecesariamente.
Ten en cuenta que es posible que se esté realizando una renderización previa debido a la renderización previa de la barra de direcciones y no solo a tus reglas de especulación. Si quieres diferenciarlos, puedes verificar el document.referrer
(que estará en blanco para la navegación de la barra de direcciones, incluidas las navegaciones de la barra de direcciones renderizadas previamente).
Recuerda también observar 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 te beneficias de esta mejora de rendimiento. El equipo de Chrome busca agregar herramientas adicionales para probar la elegibilidad de la prerenderización, quizás similares a la herramienta de prueba de bfcache, y también agregar una API para exponer por qué falló una prerenderización.
Impacto en las extensiones
Consulta la publicación exclusiva sobre Extensiones de Chrome: Extiende 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 expandir el alcance de lo que se puso a disposición en la versión 108 de Chrome. Aceptamos cualquier comentario en el repositorio de GitHub o a través de nuestro seguimiento de problemas. Esperamos escuchar y compartir casos de éxito de esta nueva y emocionante API.
Vínculos relacionados
- Codelab de reglas de especulación
- Depuración de reglas de especulación
- Presentamos la precarga de NoState
- Especificación de la API de Speculation Rules
- Repositorio de GitHub de Navigational speculation
- Extensiones de Chrome: Extiende la API para admitir la navegación instantánea
Agradecimientos
Imagen en miniatura de Marc-Olivier Jodoin en Unsplash