Páginas de carga instantánea con Speculation Rules
Aprende cómo mejorar los Core Web Vitals haciendo que las páginas carguen instantáneamente con la nueva API de speculation rules
Mejora instantáneamente los Core Web Vitals con la 'Speculation Rules API'
¿Alguna vez te preguntaste por qué algunas páginas parecen cargar instantáneamente? ¡Probablemente es porque esa página implementó Speculation Rules!
La Speculation Rules API mejora la velocidad de las futuras cargas de página en aplicaciones multipágina (MPAs) ya sea mediante prefetching o incluso prerenderizándolas. Los desarrolladores pueden configurar las speculation rules para sugerir al navegador que haga prefetch o prerender de documentos para cargas de página más rápidas (o instantáneas). Las speculation rules reemplazan técnicas anteriores como `<link rel="prefetch">` para la precarga de recursos o la función obsoleta exclusiva de Chrome `<link rel="prerender">`.
Las speculation rules funcionan a nivel de documento, lo que las hace adecuadas para MPAs que involucran navegaciones de página completa. Las aplicaciones de página única (SPAs) que principalmente usan llamadas a APIs o actualizaciones parciales de contenido no se beneficiarían tanto de esta API para sus cambios de ruta internos. Sin embargo, las Speculation Rules aún pueden beneficiar a las SPAs al prerenderizar el estado inicial de la aplicación desde una página de aterrizaje, compensando potencialmente el tiempo de carga inicial.
Table of Contents!
Inicio rápido de Speculation Rules
¿Ya sabes qué son las speculation rules? ¡Genial! Aquí tienes algunos fragmentos de código listos para usar y comenzar de inmediato. Solo elige el fragmento adecuado para ti y colócalo en el <head> de tu página (¡siéntete libre de cambiar preload por prefetch y/o el eagerness)!
<!--
Speculation rules para WordPress por corewebvitals.io
hace prefetch de todos los enlaces internos
omite enlaces que coincidan con wp-login, wp-admin, wp content
omite enlaces que tengan el atributo nofollow
omite enlaces que tengan un query string, por ejemplo: /search->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"and": [{ "href_matches": "\/*"},{ "not": { "href_matches": [ "\/wp-login.php", "\/wp-admin\/*", "\/*\\?*", "\/wp-content\/*", ] }
},{ "not": { "selector_matches": "a[rel~=\"nofollow\"]" }
}]
},
"eagerness": "moderate"
}]
}
</script> <!-- Speculation rules activadas por data-preload por corewebvitals.io -->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"selector_matches": "a[data-preload]"
},
"eagerness": "moderate"
}]
}
</script> Consejo: si necesitas construir rápidamente tus propias speculation rules, ¿por qué no pruebas el generador de speculation rules
Beneficios de las Speculation Rules
Mejora de la user experience (UX): Al predecir y precargar contenido, las Speculation Rules aseguran cargas de página casi instantáneas, haciendo que la navegación se sienta fluida para los usuarios. Esto iguala el rendimiento de las aplicaciones de página única incluso para sitios web multipágina tradicionales sin la complejidad y dependencia de JavaScript. Tiempos de carga más rápidos significan una mejor experiencia de navegación, lo que probablemente aumentará la interacción del usuario y reducirá las tasas de rebote.
Ventajas de SEO: Dado que la velocidad de página mejorada es un factor de posicionamiento directo y un mejor Time to First Byte resultará en un mejor Largest Contentful Paint, implementar speculation rules sin duda mejorará los Core Web Vitals y te dará esa ventaja en PageSpeed Insights.
Complejidad reducida: Las cargas de página casi instantáneas solían ser posibles usando una SPA o escribiendo lógica de prefetch personalizada para MPAs.
Para muchos casos de uso, la desventaja de una SPA es el tiempo de arranque inicial, que puede ser considerable ya que dependen en gran medida de JavaScript y la mayor complejidad en comparación con una MPA. Las speculation rules no tienen estos problemas. Esto hace que las cargas rápidas sean alcanzables para una gama más amplia de sitios web, especialmente los centrados en contenido.
La API también simplifica el proceso de decidir qué páginas prerenderizar al delegar gran parte de la lógica al navegador. Esto es una gran mejora respecto a métodos anteriores que dependían de JavaScript para realizar estas verificaciones e inyectar páginas para precargar. Los navegadores pueden tener en cuenta de forma nativa el contexto del usuario, como poca memoria en dispositivos móviles o modo de ahorro de batería, al decidir si prerenderizar. Esta adaptación dinámica ayuda a conservar los recursos del usuario y asegura una experiencia más fluida incluso bajo restricciones.
Otros beneficios: El encabezado HTTP Speculation-Rules permite un despliegue más fácil a través de Redes de Distribución de Contenido (CDNs), eliminando la necesidad de modificar el contenido del documento directamente. El Control Granular con Document Rules permite a los desarrolladores definir condiciones precisas para el prefetching o prerendering basándose en patrones de URL o selectores CSS. Esto reduce la especificación manual de URLs y permite conjuntos de speculation rules a nivel de todo el sitio. La configuración de "eagerness" proporciona un control detallado sobre cuándo ocurre la especulación, equilibrando la velocidad de precarga con el consumo de recursos. Esto ayuda a reducir la precarga innecesaria y previene el desperdicio de recursos.
Mecánica de las Speculation Rules
Las speculation rules se definen usando una estructura JSON y se pueden implementar de dos formas:
- Script en línea: Incluir el JSON dentro de una etiqueta `<script type="speculationrules">` ya sea en el `<head>` o `<body>` del documento HTML principal.
- Encabezado HTTP: Entregar las reglas usando el encabezado HTTP `Speculation-Rules` en la respuesta del documento. Este encabezado apunta a un archivo JSON que contiene las reglas, facilitando despliegues CDN más fáciles sin modificar el contenido HTML directamente.
La estructura JSON usa arrays de "prefetch" y "prerender" para contener reglas para cada tipo de carga especulativa. Cada regla puede usar diferentes fuentes: ya sea una lista de URLs o document rules
- urls (una lista de URLs) Un array de URLs para hacer prefetch o prerender.
- where (document rules) Un objeto que usa condiciones para determinar qué enlaces en la página deben ser prefetcheados o prerenderizados.
Cada regla se define como un objeto que incluye propiedades como:
- requires Un array de cadenas para establecer restricciones sobre las especulaciones. Actualmente, la única cadena válida es "anonymous-client-ip-when-cross-origin", que indica que un prefetch cross-origin debe anonimizar la dirección IP del cliente.
- target_hint Una cadena que proporciona una pista sobre el nombre del destino navegable, permitiendo al agente de usuario optimizar el proceso de carga. No tiene implicaciones normativas más allá de ser una pista.
- referrer_policy Una política de referencia para aplicar a las URLs prefetcheadas o prerenderizadas.
- relative_to (Solo para fuente "list") Especifica si las URLs proporcionadas en el array "urls" son relativas a la URL base del documento ("document") o a la ubicación del archivo JSON de speculation rules ("ruleset").
- eagerness Controla cuán agresivamente el navegador debe hacer prefetch o prerender. Las configuraciones disponibles son "immediate", "eager", "moderate" y "conservative", cada una con diferentes activadores.
- expects_no_vary_search Una cadena utilizada para proporcionar una pista de variación de búsqueda de URL, permitiendo a los desarrolladores señalar si se espera que la URL especulada tenga una respuesta diferente según los parámetros de búsqueda.
Finalmente, cada regla tiene una configuración de eagerness que te permite definir cuándo deben ejecutarse las especulaciones, separando cuándo especular de qué URLs realizar especulaciones. La configuración de eagerness está disponible tanto para reglas de lista como de documento y tiene cuatro configuraciones: immediate, eager, moderate y conservative.
- immediate: Se usa para especular lo antes posible, tan pronto como se observan las speculation rules.
- eager: Actualmente se comporta de manera idéntica a la configuración immediate, pero en el futuro, se ubicará en algún punto entre immediate y moderate.
- moderate: Realiza especulaciones si pasas el cursor sobre un enlace durante 200 milisegundos (o en el evento pointerdown si ocurre antes, y en móvil donde no hay evento de hover).
- conservative: Especula al presionar con el puntero o al tocar.
Prefetch o Prerender
La Speculation Rules API admite dos formas principales de carga especulativa: prefetching y prerendering. Aunque ambas técnicas pueden resultar en cargas de página más rápidas, difieren en su complejidad y consumo de recursos.
- Prefetching, es la forma 'más ligera' de carga especulativa. Descarga y almacena en caché el HTML de la URL de destino sin renderizar la página ni sus subrecursos. Este enfoque mejora principalmente el Time To First Byte. Un Time to First Byte mejorado conducirá a mejores métricas de renderizado como el Largest Contentful Paint y First Contentful Paint.
- Prerendering hace mucho más que solo descargar el HTML. Descarga el HTML, todos los subrecursos y renderiza la página completa en una pestaña oculta e invisible. Al navegar a esta página, esto resulta en una visualización casi instantánea. Esta técnica mejora el Largest Contentful Paint de más formas que solo mejorando el Time to First Byte. También descarga y renderiza el elemento LCP. El prerendering también puede eliminar el Cumulative Layout Shift porque las dimensiones de los recursos ya son conocidas después del prerendering.
Entonces, ¿qué es mejor? ¿Prerendering o Prefetching? Eso depende de la página y del 'visitante promedio'. Si bien el prerendering puede ser más rápido por diseño, también usa muchos más recursos, tanto en el cliente como en el servidor. La elección entre prerendering o prefetching depende de:
- Capacidades del dispositivo del usuario: El prerendering podría no ser la mejor opción si un alto porcentaje de visitantes accede desde dispositivos con memoria limitada
- Especificidad de las reglas de prerender o prefetch. 'Algunos enlaces tienen más probabilidad de ser clickeados y algunas páginas tienen más probabilidad de convertir'. Esas páginas son candidatas perfectas para una regla de prerender. Otras páginas podrían ser más adecuadas para prefetch.
CoreWebVitals.io quisiera advertir contra el prerendering excesivo debido a sus demandas de recursos, particularmente en dispositivos móviles o conexiones lentas. Los beneficios potenciales del prerendering deben sopesarse contra el riesgo de degradación del rendimiento y desperdicio de recursos.
Configurar el 'Eagerness' correcto - el acto de equilibrio
Qué configuración de eagerness usar depende de tu sitio. Para un sitio estático muy simple, especular de forma más agresiva puede tener poco costo y ser beneficioso para los usuarios. Los sitios con arquitecturas más complejas y cargas de página más pesadas pueden preferir reducir el desperdicio especulando con menos frecuencia hasta obtener señales más positivas de intención por parte de los usuarios para limitar el desperdicio.
La configuración de eagerness en la Speculation Rules API influye en cuándo un navegador debe hacer prefetch o prerender contenido basándose en la navegación prevista del usuario. Esta configuración ofrece un equilibrio entre maximizar los beneficios de la precarga y minimizar el desperdicio de recursos.
El eagerness predeterminado para las reglas de lista es immediate. Las opciones moderate y conservative pueden usarse para limitar las reglas de lista a URLs con las que un usuario interactúa en una lista específica. En muchos casos, las document rules con una condición where apropiada pueden ser más adecuadas.
El eagerness predeterminado para las document rules es conservative. Dado que un documento puede consistir en muchas URLs, el uso de immediate o eager para document rules debe emplearse con precaución.
La elección del eagerness depende de la estructura del sitio web, los patrones de comportamiento del usuario y la evaluación del desarrollador sobre el consumo potencial de recursos versus los beneficios de la user experience. Por ejemplo, un sitio estático sencillo podría beneficiarse de una configuración "eager", lo que llevaría a tiempos de carga más rápidos. Por el contrario, los sitios web con arquitecturas complejas y cargas de página exigentes pueden optar por un enfoque menos agresivo "moderate" o "conservative" para limitar el uso de recursos hasta que se detecte una intención más clara del usuario.
Al configurar el eagerness, los desarrolladores deben considerar la user experience, los costos de recursos y las limitaciones del navegador. La especulación excesiva puede sobrecargar el ancho de banda, la memoria y la CPU del usuario, pudiendo degradar el rendimiento, especialmente en redes o dispositivos con restricciones. Chrome impone límites en las páginas prefetcheadas y prerenderizadas simultáneamente para mitigar el uso excesivo. Además, factores como los modos de Ahorro de Datos configurados por el usuario, condiciones de batería baja o extensiones del navegador pueden anular las speculation rules, priorizando la conservación de recursos.
Verificar y depurar las speculation rules
Para verificar cualquier speculation rule en una página, abre Chrome DevTools, ve al panel Application y navega a Background Services > Speculative Loads > Speculations. (abre el panel de Speculations antes de cargar la página que deseas depurar) Este panel proporciona información sobre:
- El número de especulaciones exitosas.
- URLs individuales siendo prerenderizadas o prefetcheadas.
- El estado de cada especulación.
La pista Network en el panel Performance muestra la actividad de red relacionada con los recursos prerenderizados sin necesidad de cambiar el contexto de DevTools. Además, puedes cambiar el contexto de DevTools a una página prerenderizada para inspeccionarla como una página normal.
Monitoreo y análisis de Speculation Rules
- Real User Monitoring (RUM): Utiliza herramientas de RUM para medir la experiencia real del usuario. Observa métricas como el Largest Contentful Paint (LCP) para evaluar el impacto de las speculation rules en los tiempos de carga de página. Busca mejoras en el LCP para páginas prerenderizadas en comparación con páginas no prerenderizadas.
- Pruebas A/B: Realiza pruebas A/B para comparar diferentes configuraciones de speculation rules e identificar la configuración más óptima para tu sitio web y base de usuarios específicos.
Consideraciones - lo negativo
Consumo de recursos: El uso excesivo de la especulación puede impactar negativamente el ancho de banda, la memoria y el uso de CPU.
Compatibilidad de navegadores: No todos los navegadores soportan completamente la Speculation Rules API, así que verifica la compatibilidad del navegador antes de implementarla.
Privacidad: Los desarrolladores deben ser conscientes de cómo las speculation rules podrían revelar los patrones de navegación del usuario e implementar medidas de privacidad apropiadas.
La Speculation Rules API ofrece un enfoque poderoso para mejorar el rendimiento y la user experience de las aplicaciones web. Al comprender su mecánica, beneficios y consideraciones, los desarrolladores pueden aprovechar esta API para construir sitios web más rápidos y atractivos.
Código de Speculation Rules para WordPress
El equipo de Core Performance de WordPress ha creado un plugin de Speculation Rules que hace que agregar soporte de document rules a cualquier sitio WordPress sea cuestión de un solo clic. El plugin ofrece dos grupos de configuraciones:
- Modo de especulación: Elige entre prefetch y prerender. El prerendering resultará en tiempos de carga más rápidos que el prefetching. Sin embargo, el prefetching podría ser una opción más segura para contenido interactivo.
- Eagerness: Elige entre conservative (típicamente al hacer clic), moderate (típicamente al pasar el cursor) o eager (ante la más mínima sugerencia). La configuración de eagerness determina qué tan rápido se activan las cargas especulativas.
