Fecha de publicación: 7 de marzo de 2025
La API de Speculation Rules permite a los usuarios beneficiarse de un aumento del rendimiento mediante la recuperación o renderización previas de las navegaciones de páginas futuras para brindar navegaciones de páginas más rápidas o incluso instantáneas.
La API se diseñó específicamente teniendo en cuenta la facilidad de implementación, pero hay algunas consideraciones que los sitios complejos deben tener en cuenta antes de usarla. Esta guía ayuda a los propietarios de sitios a comprender estas consideraciones.
Planificación
Antes de implementar las reglas de especulación, vale la pena considerar cómo implementar la API (ya que hay algunas opciones) y también los costos de las especulaciones (que deberían guiarte sobre qué páginas especular).
Decide cómo implementar las reglas de especulación
Una de las primeras decisiones que debes tomar es cómo implementar las reglas de especulación en tu sitio, ya que existen varios métodos que puedes usar:
- Directamente en el código HTML de la página
- Cómo usar JavaScript
- Cómo usar un encabezado HTTP
En última instancia, cada método tiene el mismo efecto, pero puede haber ventajas en términos de facilidad de implementación y flexibilidad.
Los sitios deben elegir la opción que mejor se adapte a sus necesidades y, si es necesario, pueden usar una combinación de estas opciones. Como alternativa, se pueden implementar con un complemento (como el complemento de carga especulativa para WordPress) o bibliotecas o plataformas que pueden tomar la decisión por ti, pero aún así vale la pena conocer las opciones disponibles.
Incluye reglas de especulación directamente en el código HTML de la página
Para implementar las reglas de especulación directamente en la página, incluye el elemento <script type="speculationrules"> en su código HTML. Se puede agregar en el tiempo de compilación para sitios estáticos con plantillas o en el tiempo de ejecución por parte del servidor cuando se solicita la página. Los trabajadores de borde incluso pueden insertarlos en HTML (aunque el método de encabezado HTTP que se analiza más adelante en esta guía es probablemente más fácil para eso).
Esto te permite incluir reglas estáticas en todo el sitio, pero las reglas de documentos pueden seguir siendo dinámicas, ya que te permiten elegir las URLs que se renderizarán desde la página mediante reglas que activarán las clases de CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
La secuencia de comandos anterior renderizará previamente los vínculos con una clase prerender y, de manera similar, realizará la carga previa cuando un vínculo tenga una clase prefetch. Esto permite que los desarrolladores incluyan estas clases en el HTML para activar especulaciones.
Además de incluir vínculos a estas clases en el HTML inicial de una página, también se especularán los vínculos si tu app agrega esas clases de forma dinámica, lo que le permite activar (y quitar) las especulaciones según sea necesario. Esto puede ser más sencillo que crear o quitar reglas de especulación más específicas. También es posible incluir varias reglas de especulación por página si deseas que la mayoría del sitio use una regla base y reglas específicas de la página.
Como alternativa, si necesitas usar reglas de especulación más específicas, las reglas específicas de la página o de la plantilla pueden permitir diferentes reglas para ciertas páginas o tipos de páginas.
Por último, las páginas renderizadas del servidor también pueden tener reglas más dinámicas según la información que esté disponible para el servidor, como la información de estadísticas de esa página o los recorridos comunes de los usuarios para ciertas páginas.
Agrega reglas de especulación con JavaScript
Una alternativa para incluir las reglas en una secuencia de comandos en la página es insertarlas con JavaScript. Esto puede requerir menos actualizaciones de las plantillas de página. Por ejemplo, hacer que un administrador de etiquetas inserte las reglas puede ser una forma rápida de implementar las reglas de especulación (y también permite desactivarlas rápidamente si es necesario).
Esta opción también permite reglas dinámicas del cliente según la forma en que el usuario interactúa con la página. Por ejemplo, si el usuario agrega un artículo al carrito, puedes renderizar previamente la página de confirmación de la compra. Como alternativa, se puede usar para activar especulaciones en función de ciertas condiciones. Si bien la API incluye un parámetro de configuración de solicitud anticipada que permite reglas básicas basadas en la interacción, JavaScript permite que los desarrolladores usen su propia lógica para decidir cuándo y en qué páginas especular.
Como se mencionó anteriormente, un enfoque alternativo para insertar reglas nuevas es tener una regla de documento base en la página y hacer que JavaScript active reglas de documentos agregando clases apropiadas a los vínculos para que coincidan con la regla.
Agrega reglas de especulación con un encabezado HTTP
La última opción para los desarrolladores es incluir las reglas con un encabezado HTTP:
Speculation-Rules: "/speculationrules.json"
Existen algunos requisitos adicionales sobre cómo se entrega y usa el recurso de reglas (/speculationrules.json en este ejemplo).
Esta opción permite que las CDN implementen el contenido más fácilmente sin necesidad de alterar el contenido del documento. Esto significa que no es una opción alterar las reglas de especulación de forma dinámica con JavaScript. Sin embargo, las reglas de documentos con activadores de selectores CSS aún pueden permitir cambios dinámicos, por ejemplo, quitando la clase prerender de un vínculo.
Al igual que con la opción de JavaScript, implementar reglas de especulación con un encabezado HTTP permite que se implementen independientemente del contenido del sitio, lo que puede facilitar la adición y eliminación de las reglas sin tener que volver a compilar el sitio por completo.
Considera las implicaciones de costos
Antes de implementar reglas de especulación, te recomendamos que te tomes un tiempo para considerar las implicaciones de costos para tus usuarios y tu sitio con esta API. Los costos incluyen el ancho de banda (que cuesta dinero a los usuarios y a los sitios) y los costos de procesamiento (tanto del cliente como del servidor).
Ten en cuenta el costo para los usuarios
La carga especulativa consiste en hacer una suposición fundamentada sobre a dónde podría navegar un usuario. Sin embargo, si no se produce esa navegación, es posible que hayas desperdiciado recursos. Por este motivo, debes tener en cuenta el impacto en los usuarios, en particular:
- Ancho de banda adicional que se usa para descargar esa navegación futura, especialmente en dispositivos móviles, donde el ancho de banda puede ser más limitado.
- Costos de procesamiento adicionales para renderizar esas páginas cuando se usa el renderizado previo
Con predicciones completamente precisas, no hay costos adicionales, ya que los visitantes visitarán esas páginas a continuación, con la única diferencia de que esos costos se cargan por adelantado. Sin embargo, es imposible predecir el futuro con total precisión y, cuanto más agresiva sea la estrategia de especulación, mayor será el riesgo de desperdicio.
Chrome analizó cuidadosamente este problema y la API incluye varias funciones que hacen que el costo sea mucho más bajo de lo que crees. En particular, al reutilizar la caché HTTP y no cargar iframes de origen cruzado, el costo de renderizar previamente una navegación en el mismo sitio suele ser considerablemente menor que el de una página completa sin recursos almacenados en caché, lo que hace que las cargas especulativas sean menos costosas de lo que se podría suponer.
Sin embargo, incluso con estas protecciones, los sitios deben considerar cuidadosamente qué páginas especular y el costo para el usuario de esas especulaciones. Entre los buenos candidatos para la carga especulativa, se incluyen aquellos que se pueden predecir de manera razonable con un alto grado de confianza (quizás en función de estadísticas o recorridos comunes de los usuarios) y cuando el costo es bajo (por ejemplo, páginas menos enriquecidas).
También te recomendamos que consideres qué JavaScript se debe retrasar hasta la activación. Al igual que la carga diferida del contenido hasta que se necesita, esto puede hacer que las renderizaciones previas sean más económicas, pero proporcionan una experiencia del usuario mucho mejor. Con especulaciones más económicas, es posible que te sientas a gusto especulando con más frecuencia o con más entusiasmo.
Cuando esto no sea posible, se recomienda una estrategia menos agresiva que use reglas de avidez moderadas o conservadoras. Como alternativa, puedes usar la carga previa, que tiene un costo considerablemente menor que la renderización previa cuando la confianza es baja y, luego, actualizar a una renderización previa completa si aumenta la confianza, por ejemplo, cuando se coloca el cursor sobre un vínculo o se hace clic en él.
Considera la carga adicional del backend
Además de considerar los costos adicionales del usuario, los propietarios del sitio deben considerar sus propios costos de infraestructura. Si cada página genera dos, tres o incluso más cargas de página, es posible que los costos del backend aumenten si usas esta API.
Si te aseguras de que tus páginas y recursos se puedan almacenar en caché, se reducirá significativamente la cantidad de carga de origen y, por lo tanto, el riesgo general. Cuando se combinan con una CDN, tus servidores de origen deberían ver una carga adicional mínima, aunque debes tener en cuenta cualquier aumento de costos de la CDN.
También se puede usar un servidor o una CDN para controlar los resultados de la especulación, como lo identifica el encabezado HTTP de sec-purpose. Por ejemplo, el producto Speed Brain de Cloudflare solo permite especulaciones que ya están almacenadas en caché en el servidor perimetral de una CDN y no enviará solicitudes al origen.
Sin embargo, como las cargas especulativas suelen usarse para cargas de páginas del mismo origen, los usuarios ya tendrán recursos compartidos en la caché del navegador (siempre que se puedan almacenar en caché en primer lugar). Por lo tanto, una especulación no suele ser tan costosa como una carga de página completa.
Encuentra el equilibrio entre especular demasiado o muy poco
La clave para aprovechar al máximo la API de Speculation Rules es encontrar el equilibrio entre especular demasiado (es decir, cuando se pagan los costos innecesariamente y no se usa la especulación) y hacerlo de forma demasiado conservadora (ya sea demasiado poco o demasiado tarde, cuando se obtiene poco beneficio).
Cuando los costos son económicos (por ejemplo, páginas pequeñas generadas de forma estática almacenadas en caché en nodos perimetrales de CDN), puedes permitirte ser más agresivo con las especulaciones.
Sin embargo, en el caso de las páginas más grandes y enriquecidas que quizás no se puedan almacenar en caché en el borde de la CDN, se debe tener más cuidado. Del mismo modo, las páginas que consumen muchos recursos pueden agotar el ancho de banda de la red o la potencia de procesamiento, lo que puede afectar negativamente la página actual. El objetivo de la API es mejorar el rendimiento, por lo que las regresiones de rendimiento no son lo que queremos. Esta es otra razón para mantener las renderizaciones previas en una o dos páginas como máximo (ten en cuenta también que Chrome limita a dos o diez renderizaciones previas a la vez, según la rapidez).
Pasos para implementar reglas de especulación
Una vez que hayas decidido cómo implementar las reglas de especulación, debes planificar qué especular y cómo lanzarlo. Es posible que los sitios más simples, como los blogs personales estáticos, puedan ir directamente a la renderización previa completa de ciertas páginas, pero los sitios más complejos tienen complejidades adicionales que se deben tener en cuenta.
Comienza con la carga previa
Por lo general, la precarga es relativamente segura de implementar en la mayoría de los sitios, y este es el enfoque inicial que adoptan muchos, incluidos los lanzamientos a gran escala, como Cloudflare y WordPress.
Los principales problemas que debes tener en cuenta son que, si la carga previa de una URL causará cambios de estado y costos del servidor, en especial para las páginas que no se pueden almacenar en caché. Idealmente, los cambios de estado, por ejemplo, la precarga de una página /logout, no deberían implementarse como vínculos GET, pero, lamentablemente, esto no es inusual en la Web.
Estas URLs se pueden excluir específicamente de las reglas:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
La precarga se puede limitar a las navegaciones comunes de una página a otra, o para todos los vínculos del mismo origen cuando se coloca el cursor sobre ellos o se hace clic en ellos con el parámetro de configuración eagerness de moderate o conservative. La configuración conservative tiene el riesgo más bajo, pero también la recompensa potencial más baja. Si comienzas allí, intenta avanzar al menos a moderate, pero lo ideal es que lo hagas a eager, ya que obtendrás más beneficios de rendimiento (y, luego, actualiza a prerender cuando esto tenga sentido).
Renderizaciones previas de bajo riesgo
Las especulaciones de precarga son más fáciles de implementar, pero el mayor beneficio de rendimiento de la API es con la renderización previa. Esto puede tener algunas consideraciones adicionales cuando no se visita la página poco después de la especulación (que analizaremos en la siguiente sección), pero con una renderización previa de moderate o conservative, donde es probable que la navegación se realice poco después, el siguiente paso puede ser de riesgo relativamente bajo.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Precarga páginas comunes para mejorar las renderizaciones previas no inmediatas
Una táctica común es realizar la carga previa de una menor cantidad de páginas que se visitan con frecuencia durante la carga con una configuración de eager (ya sea especifícalas en una lista de URLs o usa selector_matches) y, luego, renderizarlas previamente con una configuración de moderate. Como es probable que la carga previa de HTML se haya completado cuando se coloca el cursor sobre el vínculo, esto ofrece un aumento en comparación con la renderización previa solo con el desplazamiento del cursor sin una carga previa.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
Renderizaciones previas anteriores
Si bien las reglas de documentos moderate permiten un uso de la API con un riesgo relativamente bajo y una facilidad de implementación asociada, a menudo no hay tiempo suficiente para una renderización previa completa. Para lograr las navegaciones instantáneas que permite esta API, es probable que debas ir más allá y renderizar las páginas con mayor rapidez.
Esto se logra con una lista estática de URLs (como el ejemplo de precarga anterior) o con selector_matches que identifica una pequeña cantidad de URLs (idealmente, una o dos páginas), con reglas de documentos que abarcan las otras URLs:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
Esto puede requerir un análisis de tráfico para tener la mejor oportunidad de predecir con precisión la siguiente navegación. Comprender los recorridos típicos de los clientes por tu sitio también puede ayudarte a identificar buenos candidatos para la carga especulativa.
El cambio a una renderización previa más anticipada también puede introducir más consideraciones sobre las estadísticas, los anuncios y JavaScript, y la necesidad de mantener una página renderizada previamente actualizada o incluso de cancelar o actualizar las especulaciones sobre los cambios de estado.
Analytics, anuncios y JavaScript
Cuando se usa la renderización previa, los sitios más complejos también deben considerar el impacto en las estadísticas. Por lo general, no deseas registrar una vista de página (o anuncio) cuando se especula sobre la página, y solo cuando se activa la especulación.
Algunos proveedores de estadísticas (como Google Analytics) y proveedores de anuncios (como Google Publisher Tag) ya admiten reglas de especulación y no registrarán vistas hasta que se active la página. Sin embargo, es posible que otros proveedores o estadísticas personalizadas que hayas implementado requieran una consideración adicional.
Puedes agregar verificaciones a JavaScript para evitar la ejecución de fragmentos de código específicos hasta que las páginas se activen o se vuelvan visibles, y hasta unir elementos <script> completos en esas verificaciones. Cuando las páginas usan administradores de etiquetas para insertar esas secuencias de comandos, es posible abordarlas todas de una sola vez retrasando la secuencia de comandos del administrador de etiquetas.
Del mismo modo, los administradores de consentimiento son una oportunidad para retrasar las secuencias de comandos de terceros hasta la activación. Google ha estado trabajando con varias plataformas de administración de consentimiento para que sean compatibles con la renderización previa, y con gusto ayudaremos a otros que quieran hacer lo mismo. PubTech es una de esas empresas que ofrece a los desarrolladores la opción de ejecutar o bloquear su JavaScript durante la renderización previa.
En el caso del código de la aplicación, puedes agregar un cambio de manera similar para retrasar la ejecución del código hasta la activación, especialmente cuando la página no requiere que se renderice el código JavaScript. Esta es una opción más rápida y segura, pero significa que todo el código se ejecutará de una vez cuando se active. Esto puede generar mucho trabajo en el momento de la activación, lo que puede afectar la INP, en especial, porque la página puede parecer completamente cargada y lista para interactuar.
Además, si algún contenido depende de JavaScript (por ejemplo, contenido renderizado del cliente), retrasar esto reducirá el impacto positivo que puede tener la renderización previa en las LCP y las CLS. Un enfoque más segmentado para permitir que se ejecute más JavaScript durante la fase de renderización previa generará una mejor experiencia, pero puede ser menos trivial de implementar.
Comenzar con la demora completa de muchas etiquetas de secuencia de comandos puede ser una buena estrategia para sitios más complejos en un principio. Sin embargo, para obtener los mayores beneficios de la API, el objetivo final debe ser permitir que se ejecute la mayor cantidad posible de JavaScript durante la renderización previa.
Es posible que los sitios con problemas de estadísticas o anuncios también deseen comenzar con la carga previa, ya que estos son menos preocupantes, mientras consideran lo que se debe hacer para admitir la renderización previa.
Actualiza las especulaciones de renderización previa
Cuando se renderizan páginas con anticipación a las navegaciones, existe el riesgo de que la página renderizada previamente quede desactualizada. Por ejemplo, una página renderizada previamente de un sitio de comercio electrónico puede incluir una cesta de confirmación de la compra, ya sea una cesta completa de artículos o incluso solo un contador que muestre la cantidad de artículos en la cesta en otras páginas. Si se agregan más artículos a un carrito y, luego, se navega a una página renderizada previamente, sería confuso para el usuario ver el estado de confirmación de la compra anterior.
Este no es un problema nuevo y, cuando los usuarios tienen varias pestañas abiertas en el navegador, experimentan el mismo problema. Sin embargo, con las páginas renderizadas previamente, esto es más probable y más inesperado, ya que el usuario no inició la renderización previa de forma consciente.
La API de Broadcast Channel es una forma de permitir que una página del navegador transmita actualizaciones como esta a otras páginas. Esto también resolvería el problema de las múltiples pestañas. Las páginas renderizadas previamente pueden escuchar mensajes de transmisión, aunque no pueden enviar sus propios mensajes de transmisión hasta que se activen.
Como alternativa, las páginas renderizadas previamente pueden obtener actualizaciones mediante el servidor (con un fetch() periódico o una conexión WebSocket), pero con posibles retrasos en las actualizaciones.
Cancela o actualiza las especulaciones de renderización previa
La actualización de una página renderizada previamente es el enfoque recomendado para seguir usando páginas renderizadas previamente y, al mismo tiempo, evitar confusiones para los usuarios. Cuando esto no es posible, se pueden cancelar las especulaciones.
Esto también se puede usar para mantenerse dentro de los límites de Chrome si los sitios desean renderizar previamente otras páginas que es más probable que se visiten.
Para cancelar las especulaciones, debes quitar las reglas de especulación de la página o quitar las clases o cualquier otro criterio de coincidencia si usas ese enfoque. Como alternativa, la página especulada puede llamar a window.close() si detecta que ya no es actual. Sin embargo, si la página puede detectar esto, la mejor opción sería actualizar su estado para que vuelva a estar actualizado.
También es posible volver a insertar estas reglas (o criterios de coincidencia) para que las páginas se vuelvan a renderizar previamente (aunque, una vez más, mantener una página existente actualizada suele ser la mejor opción, ya que genera menos desperdicios). Después de quitar las reglas de especulación, la inserción debe completarse en una microtarea nueva o más adelante para permitir que el navegador detecte las eliminaciones y cancele las especulaciones. En el siguiente ejemplo, se muestra un enfoque para borrar y quitar todas las secuencias de comandos de reglas de especulación:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
Si quitas las reglas, se cancelarán los simuladores (o la carga previa), pero si las vuelves a insertar, solo se especularán las reglas inmediatas o anticipadas (incluidas las reglas de lista de URLs que usan el valor predeterminado de inmediato). Sin embargo, se quitarán las especulaciones moderadas o conservadoras, pero no se volverán a activar automáticamente hasta que se vuelva a interactuar con el vínculo.
Esta opción de actualización no se limita a las reglas insertadas en JavaScript. Las reglas estáticas incluidas en el HTML también se pueden quitar o cambiar de la misma manera, ya que se trata de un cambio estándar del DOM. No se pueden quitar las reglas de especulación de HTTP, pero JavaScript puede quitar y volver a agregar los criterios de coincidencia (por ejemplo, las clases prerender).
Chrome también está considerando agregar compatibilidad con Clear-Site-Header para permitir que las respuestas del servidor cancelen las renderizaciones previas (por ejemplo, cuando se realiza una solicitud de actualización del carrito).
Mide el impacto
Después de implementar las reglas de especulación, debes medir el éxito y no solo suponer que es más rápido automáticamente. Como se mencionó anteriormente, la sobreespecificación puede causar regresiones de rendimiento si el cliente o el servidor están sobrecargados.
Cuando implementes la función con varios pasos (precarga, renderizaciones previas de bajo riesgo y, luego, renderizaciones previas anticipadas), debes realizar mediciones con cada paso.
Cómo medir el éxito
Las reglas de especulación deberían tener un impacto positivo en las métricas de rendimiento clave, como la LCP (y, posiblemente, también en la CLS y la INP), pero es posible que no sean evidentes en las métricas generales a nivel del sitio. Esto se debe a que los sitios pueden estar compuestos principalmente por otros tipos de navegación (por ejemplo, páginas de destino) o porque las navegaciones del mismo origen ya son lo suficientemente rápidas como para que, incluso, mejorarlas de forma significativa no afecte las métricas del percentil 75, como se informa en el Informe sobre la experiencia del usuario en Chrome (CrUX).
Puedes usar los tipos de navegación de páginas en CrUX para verificar qué porcentaje de navegaciones son navigate_cache o prerender y si aumenta con el tiempo. Sin embargo, para un análisis detallado, es posible que debas usar la supervisión de usuarios reales para segmentar tus datos en navegaciones especuladas y ver qué tan más rápidas son que otras navegaciones.
Cómo medir el uso y el desperdicio
Otra consideración clave es medir si estás especulando en las páginas correctas. Esto evita el desperdicio y garantiza que te enfoques en las mejores páginas para obtener ganancias de esta API.
Lamentablemente, la página que inicia las especulaciones no puede ver directamente el estado de los intentos de especulación. Además, no se puede suponer que se hayan activado los intentos, ya que el navegador puede retener las especulaciones en ciertas circunstancias. Por lo tanto, se deben medir en la página. Esto también requiere verificar dos APIs para ver si la página está especulando o lo hizo:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
Luego, esta página puede registrar el intento de especulación en los servidores de backend.
Una complicación con las estadísticas son los proveedores (como Google Analytics) que son compatibles con la renderización previa y que ignoran las llamadas a estadísticas hasta que se activa la página, incluso las llamadas a eventos independientes. Por lo tanto, los usuarios de Google Analytics deben usar otra opción de registro del servidor.
También es posible hacerlo del lado del cliente, en el que cada página renderizada previamente registra la renderización previa en el almacenamiento compartido y la página de llamada la lee. localStorage funciona mejor, ya que se puede leer cuando se sale de una página (ten en cuenta que no se puede usar sessionStorage, ya que tiene un manejo especial para las páginas renderizadas previamente). Sin embargo, ten en cuenta que localStorage no es seguro a nivel de las transacciones y que es posible que otras páginas lo actualicen al mismo tiempo si se renderizan varias páginas de antemano. Esta demo usa un hash único y entradas individuales para evitar problemas con esto.
Conclusión
Las reglas de especulación ofrecen la posibilidad de aumentar de forma significativa el rendimiento de tu página. En esta guía, se brindan consejos sobre las consideraciones que debes tener en cuenta cuando implementes esta API para evitar posibles problemas y aprovecharla al máximo.
Planificar la implementación de antemano evitará que se vuelva a hacer el trabajo. En particular, para los sitios más complejos, debe seguirse de un lanzamiento de varios pasos que comience con la precarga antes de pasar a la renderización previa de bajo riesgo y, luego, a la renderización previa anticipada. Por último, es importante medir las mejoras, así como el uso y el desperdicio, para asegurarte de que estás haciendo un uso óptimo de la API.