Cada vez que un usuario visita tu página web, inicia una carrera para recibir contenido lo más rápido posible. El rendimiento es un factor crítico que influye en la forma en que los visitantes interactúan con tu sitio. Algunos podrían pensar que mover contenido por todo el mundo introduce una latencia significativa, pero durante un tiempo, las velocidades de transmisión de la red se han acercado a sus límites teóricos. Para poner esto en perspectiva, los datos de Cloudflare pueden recorrer el viaje de ida y vuelta de 11 000 kilómetros entre Nueva York y Londres en unos 76 milisegundos, es decir, en menos de un abrir y cerrar de ojos.
Sin embargo, persisten los retrasos en la carga de páginas web debido a la complejidad del procesamiento de las solicitudes, las respuestas y las configuraciones. Además de impulsar avances en el establecimiento de la conexión, la compresión, el hardware y el software, hemos desarrollado una nueva forma de reducir la latencia de la carga de páginas anticipando cómo los visitantes interactuarán con una página web determinada.
Hoy nos complace anunciar el último avance en velocidad: Speed Brain. Se basa en la API Speculation Rules para la captación previa del contenido de las próximas navegaciones probables del usuario. El objetivo principal de Speed Brain es descargar una página web en la caché del navegador antes de que un usuario acceda a ella, lo que permite que las páginas se carguen casi al instante cuando realmente tiene lugar la navegación.
Nuestro enfoque inicial utiliza un modelo conservador de captación previa del contenido estático de la página siguiente cuando un usuario inicia un evento de tocar o hacer clic. Durante el cuarto trimestre de 2024 y en 2025, ofreceremos modelos de especulación más agresivos, como la representación previa especulativa (no solo la captación previa de la página antes de la navegación, sino su completa representación) para ofrecer una experiencia aún más rápida. Con el tiempo, Speed Brain aprenderá a eliminar la latencia de tu sitio web estático, sin necesidad de ninguna configuración, y trabajará con los navegadores para garantizar la carga más rápida posible.
Por ejemplo, imagina un sitio web de comercio electrónico que vende ropa. Con la información de nuestros registros de solicitudes globales, podemos predecir con gran precisión que es probable que un visitante típico haga clic en "Camisas" cuando visualiza la página principal "Hombre > Ropa". En base a esto, podemos empezar a entregar contenido estático, como imágenes, antes de que el comprador haga clic en el enlace "Camisas". Como resultado, cuando inevitablemente hace clic, la página se carga al instante. Pruebas de laboratorio recientes de la implementación de nuestro modelo de carga agresiva han demostrado una reducción de hasta el 75 % de Largest Contentful Paint (LCP), el tiempo que tarda el elemento visible más grande (como una imagen, un vídeo o un bloque de texto) en cargarse y representarse en el navegador.
¿La mejor parte? Speed Brain está disponible para todos los tipos de plan de forma inmediata y gratuita. Simplemente activa la función Speed Brain para tu sitio web desde el panel de control o la API. Parece que funcione por arte de magia, pero la operativa subyacente se basa en ingeniería inteligente.
Ya hemos activado Speed Brain por defecto en todos los dominios gratuitos y estamos observando una reducción del LCP del 45 % de las captaciones previas realizadas con éxito. Los dominios Pro, Business y Enterprise deben activar Speed Brain manualmente. Si aún no lo has hecho, te recomendamos encarecidamente que actives Real User Measurements (RUM) mediante tu panel de control para que puedas ver el rendimiento de tu nueva página web mejorada. Como ventaja adicional, si activas RUM para tu dominio nos ayudarás a proporcionarte muy pronto reglas de captación y representación previas mejoradas y personalizadas para tu sitio web.
Resumen del funcionamiento de los navegadores
Antes de analizar cómo Speed Brain puede ayudar a cargar contenido de forma increíblemente rápida, debemos dar un paso atrás para revisar la complejidad de la carga de contenido en los navegadores. Cada vez que un usuario navega a tu página web, se deben completar una serie de ciclos de solicitud y respuesta.
Una vez que el navegador establece una conexión segura con un servidor, envía una solicitud HTTP para recuperar el documento base de la página web. El servidor procesa la solicitud, construye el documento HTML necesario y lo devuelve al navegador en la respuesta.
Cuando el navegador recibe un documento HTML, inmediatamente comienza a analizar el contenido. Durante este proceso, puede encontrar referencias a recursos externos como archivos CSS, JavaScript, imágenes y fuentes. Estos subrecursos son esenciales para representar correctamente la página, por lo que el navegador emite solicitudes HTTP adicionales para obtenerlos. Sin embargo, si estos recursos están disponibles en la caché del navegador, este puede recuperarlos localmente, lo que reduce significativamente la latencia de la red y mejora los tiempos de carga de las páginas.
A medida que el navegador procesa el código HTML, CSS y JavaScript, el motor de representación comienza a mostrar contenido en la pantalla. Una vez que se muestran los elementos visuales de la página, las interacciones del usuario, como hacer clic en un enlace, hacen que el navegador inicie de nuevo gran parte de este proceso para obtener nuevo contenido para la página siguiente. Este flujo de trabajo es típico de todas las sesiones de navegación: a medida que los usuarios navegan, el navegador obtiene y representa continuamente recursos nuevos o no almacenados en caché, lo que supone un retraso hasta que la nueva página se carga por completo.
Tomemos el ejemplo de un usuario que navega por el sitio de compras descrito anteriormente. A medida que el comprador pasa de la página de inicio a la sección "Hombres" del sitio, luego a la sección "Ropa" y finalmente a la sección "Camisas", el tiempo dedicado a recuperar cada una de esas páginas posteriores puede ir sumándose y contribuir a que el comprador acabe abandonando el sitio. antes de completar su transacción.
Idealmente, si en el momento en que se hace clic en cada uno de esos enlaces el navegador ya tiene páginas captadas y representadas previamente, esto eliminaría gran parte del impacto de la latencia de la red, con lo que el navegador podría cargar contenido al instante y proporcionar una experiencia de usuario más fluida.
¡Espera! Ya he oído esto antes (¿cómo accedimos a Speed Brain?)
Sabemos lo que estás pensando. La captación previa ya hace años que existe. Incluso se han realizado varios intentos de captación previa especulativa en el pasado. Ya has oído todo esto antes. ¿En qué se diferencia ahora?
Tienes razón, por supuesto. A lo largo de los años, los desarrolladores y los proveedores de navegadores se han esforzado constantemente por optimizar los tiempos de carga de las páginas y mejorar la experiencia del usuario en la web. Se han desarrollado muchas técnicas, que abarcan varias capas de la pila de Internet, desde la optimización de la conectividad de la capa de red hasta la precarga del contenido de las aplicaciones más cerca del cliente.
La captación previa inicial: falta de datos y flexibilidad
La captación previa web es una de esas técnicas que existe desde hace más de una década. Se basa en la suposición de que es probable que se necesiten determinados subrecursos en un futuro próximo, así que ¿por qué no obtenerlos de forma proactiva? Esto podría incluir cualquier elemento, desde páginas HTML hasta imágenes, hojas de estilo o scripts que el usuario pueda necesitar mientras navega por un sitio web. De hecho, el concepto básico de la ejecución especulativa no es nuevo, ya que es una técnica general que se ha empleado en diversas áreas de la informática durante años, siendo la predicción de saltos en las CPU un buen ejemplo.
En los inicios de la web, surgieron varias soluciones de captación previa personalizadas para mejorar el rendimiento. Por ejemplo, en 2005, Google presentó Google Web Accelerator, una aplicación del lado del cliente cuyo objetivo era acelerar la navegación de los usuarios de banda ancha. Aunque innovador, el proyecto duró poco debido a problemas de privacidad y compatibilidad (describiremos en qué se diferencia Speed Brain a continuación). La captación previa predictiva en ese momento carecía de la información basada en datos y de la compatibilidad de las API para capturar el comportamiento de los usuarios, especialmente de aquellos que gestionaban acciones confidenciales como eliminaciones o compras.
Listas estáticas y trabajo manual
Tradicionalmente, la captación previa se ha realizado mediante el uso del atributo <link rel="prefetch"> como una de las Sugerencias de recursos. Los desarrolladores tenían que especificar manualmente el atributo en cada página para cada recurso que querían que el navegador buscara de forma preventiva y almacenara en la caché. Este esfuerzo manual no solo era engorroso, sino que los desarrolladores a menudo carecían de información sobre qué recursos debían captarse previamente, lo que reducía la calidad de sus sugerencias especificadas.
De forma similar, Cloudflare ofrece una función de captación previa de URL desde 2015. En lugar de la captación previa en la caché del navegador, Cloudflare permite a los clientes la captación previa de una lista estática de recursos en la caché de CDN. La función permite la captación previa de los recursos antes de que realmente se necesiten, normalmente durante el tiempo de inactividad o cuando las condiciones de la red son favorables. Sin embargo, la captación previa de CDN presenta dificultades similares, ya que los clientes deben decidir manualmente qué recursos son buenos candidatos para la captación previa para cada página de la que son propietarios. Si está mal configurada, la captación previa de enlaces estáticos puede resultar un obstáculo y ralentizar el tiempo de carga de la página web.
Server Push y sus dificultades
"server push" de HTTP/2 fue otro intento de mejorar el rendimiento web enviando recursos al cliente antes de que este los solicitara. En teoría, esto reduciría la latencia al eliminar la necesidad de viajes de ida y vuelta adicionales para activos futuros. Sin embargo, la naturaleza dictatorial centrada en el servidor de "enviar" recursos al cliente planteó desafíos importantes, principalmente debido a la falta de contexto sobre lo que ya estaba almacenado en caché en el navegador. Esto no solo desperdiciaba ancho de banda, sino que tenía el potencial de ralentizar la entrega de recursos críticos, como código básico HTML y CSS, debido a las condiciones de carrera en las búsquedas del navegador al representar la página. La solución propuesta de cache-digest, que habría informado a los servidores sobre el contenido de la caché del cliente, nunca se implementó de forma generalizada, por lo que los servidores siguieron enviando los recursos a ciegas. En octubre de 2022, Google Chrome eliminó la compatibilidad con Server Push, y en septiembre de 2024, Firefox hizo lo mismo.
Un avance con Early Hints
Como sucesor, Early Hints se especificó en 2017, pero su adopción general no se produjo hasta 2022, cuando nos asociamos con navegadores y clientes clave para su implementación. Ofrece una alternativa más eficiente al "sugerir" a los clientes qué recursos cargar, lo que permite una mejor priorización en función de las necesidades del navegador. En concreto, el servidor envía un código de estado HTTP 103 Early Hints con una lista de activos de página clave que el navegador debería empezar a cargar mientras se sigue preparando la respuesta principal. Esto proporciona al navegador una ventaja en la búsqueda de recursos esenciales y evita la carga previa redundante si los activos ya están almacenados en la caché. Aunque Early Hints no se adapta a los comportamientos de los usuarios o a las condiciones dinámicas de las páginas (todavía), su uso se limita principalmente a la precarga de activos específicos en lugar de páginas web completas (en concreto, los casos en los que hay un largo "tiempo de reflexión" del servidor para generar el código HTML).
A medida que la web evoluciona, las herramientas que pueden manejar interacciones complejas y dinámicas de los usuarios serán cada vez más importantes para equilibrar los beneficios de rendimiento de la ejecución especulativa con sus posibles inconvenientes para los usuarios finales. Durante años, Cloudflare ha ofrecido soluciones basadas en el rendimiento que se adaptan al comportamiento del usuario y cuyo objetivo es equilibrar las decisiones acerca de la velocidad y la corrección en Internet, como Argo Smart Routing, Smart Tiered Cache y Smart Placement. Hoy avanzamos un paso más hacia un marco adaptable para entregar contenido a velocidad ultrarrápida.
Ya está aquí Speed Brain: ¿en qué se diferencia?
Speed Brain ofrece un eficaz enfoque para implementar estrategias predictivas de captación previa directamente en el navegador en función del conjunto de reglas devuelto por nuestros servidores. Basándose en las lecciones de intentos anteriores, traslada la responsabilidad de la predicción de recursos al cliente, lo que permite optimizaciones más dinámicas y personalizadas según la interacción del usuario (p. ej., pasar el cursor sobre un enlace) y las capacidades de su dispositivo. En lugar de que el navegador permanezca inactivo esperando a que el usuario solicite la siguiente página web, se basa en cómo un usuario interactúa con una página y comienza a solicitar la siguiente página web antes de que el usuario termine de hacer clic en un enlace.
Este funcionamiento, aparentemente por arte de magia, es posible gracias a la API Speculation Rules. Se trata de un estándar emergente en el espacio de rendimiento web de Google. Cuando la función Speed Brain de Cloudflare está activada, se añade un encabezado HTTP llamado Speculation-Rules a las respuestas de la página web. El valor de este encabezado es una URL que aloja una configuración de Reglas fija. Esta configuración indica al navegador que inicie solicitudes de captación previa para futuras navegaciones. Speed Brain no mejora el tiempo de carga de la primera página que se visita en un sitio web, pero puede mejorarlo para las páginas web posteriores que se visiten en el mismo sitio.
La idea parece bastante simple, pero la captación previa conlleva desafíos, ya que es posible que algunos contenidos de la captación previa nunca acaben utilizándose. Con la versión inicial de Speed Brain, hemos diseñado una solución con medidas de seguridad que aborda dos problemas importantes pero distintos que limitaban los esfuerzos de especulación anteriores: la configuración obsoleta de la captación previa y la captación previa incorrecta. La configuración de la API Speculation Rules que hemos elegido para esta versión inicial se ha diseñado cuidadosamente para equilibrar la seguridad de la captación previa y al mismo tiempo mantener una amplia aplicabilidad de las reglas para la totalidad del sitio.
Configuración obsoleta de la captación previa
Dado que los sitios web cambian inevitablemente con el tiempo, las configuraciones de captación previa estática suelen quedarse obsoletas, lo que lleva a una captación previa ineficiente o ineficaz. Esto ha sido especialmente cierto en el caso de técnicas como el atributo rel=prefetch o los conjuntos de URL de captación previa de CDN estáticas, que han obligado a los desarrolladores a mantener manualmente listas de URL de captación previa relevantes para cada página de su sitio web. La mayoría de las listas de captación previa estática se basan en la intuición del desarrollador y no en los datos reales de navegación del usuario, lo que podría dejar pasar importantes oportunidades de captación previa o desperdiciar recursos en captaciones previas innecesarias.
Captación previa incorrecta
Dado que las solicitudes de captación previa son como las solicitudes normales, excepto que tienen un encabezado de solicitud HTTP `sec-purpose`, incurren en la misma sobrecarga en el cliente, la red y el servidor. Sin embargo, la diferencia fundamental es que las solicitudes de captación previa anticipan el comportamiento del usuario y es posible que la respuesta no se acabe utilizando, por lo que toda esa sobrecarga podría ser un desperdicio. Por este motivo, la precisión de la captación previa es extremadamente importante, es decir, maximizar el porcentaje de páginas de captación previa que el usuario acaba visualizando. Una captación previa incorrecta puede dar lugar a ineficiencias y costes innecesarios, como almacenar recursos en la caché que no se solicitan, o desperdiciar ancho de banda y recursos de red, lo que es especialmente crítico en redes móviles con medición del uso o en entornos con poco ancho de banda.
Medidas de seguridad
Con la versión inicial de Speed Brain, hemos diseñado una solución con importantes medidas de prevención de efectos secundarios que elimina por completo la posibilidad de una configuración obsoleta de la captación previa y minimiza el riesgo de una captación previa incorrecta. Esta configuración fija se consigue aprovechando las reglas de documento y la función eagerness de la API Speculation Rules. Esta es nuestra configuración elegida:
{
"prefetch": [{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*", "relative_to": "document" },
]
},
"eagerness": "conservative"
}]
}
Reglas de documento
Las reglas de documento, indicadas por "source": "document" y la clave "where" en la configuración, permiten que la captación previa se aplique dinámicamente en toda página web. Esto elimina la necesidad de una lista de URL estáticas predefinida para la captación previa. Por lo tanto, eliminamos el problema de la configuración obsoleta de la captación previa, ya que los enlaces candidatos de la captación previa se determinan en función de la estructura de la página activa.
Nuestro uso de "relative_to": "document" en la cláusula where indica al navegador que limite la captación previa a los enlaces del mismo sitio. Esto presenta la ventaja añadida de que permite que nuestra implementación evite las captaciones previas de distintos orígenes para evitar cualquier implicación en la privacidad de los usuarios, ya que no los sigue por la web.
Eagerness
La función eagerness controla la agresividad con la que el navegador realiza la captación previa del contenido. Permite cuatro configuraciones:
immediate: la captación previa se utiliza lo antes posible en la carga de la página (por lo general, tan pronto como el navegador ve el valor de la regla, comienza la captación previa de la página siguiente).
eager: idéntico al valor "immediate" anterior, pero el activador de la captación previa depende además de pequeños eventos de la interacción del usuario, como mover el cursor hacia el enlace (próximamente).
moderate: realiza la captación previa si mantienes el puntero sobre un enlace durante más de 200 milisegundos (o en el evento de pulsación del ratón, pointerdown, si es anterior, y en dispositivos móviles donde no haya eventos de desplazamiento, o hover).
conservative: realiza la captación previa al tocar o colocar el puntero en el enlace.
Nuestra versión inicial de Speed Brain utiliza el valor conservative de eagerness para minimizar el riesgo de una captación previa incorrecta, que puede conllevar el desaprovechamiento no deseado de recursos al mismo tiempo que acelera considerablemente tus sitios web. Si bien perdemos las posibles mejoras de rendimiento que ofrecen los valores más agresivos de "eagerness", optamos por este enfoque más prudente para priorizar la seguridad de nuestros usuarios. De cara al futuro, tenemos previsto analizar valores más dinámicos de "eagerness" para aquellos sitios que podrían beneficiarse de una configuración más liberal, y también ampliaremos nuestras reglas para incluir la representación previa.
Otra medida de seguridad importante que implementamos es aceptar solo solicitudes de captación previa para contenido estático que ya esté almacenado en nuestra caché de CDN. Si el contenido no está en la caché, rechazamos la solicitud de captación previa. La recuperación de contenido directamente de nuestra caché de CDN para las solicitudes de captación previa nos permite evitar las preocupaciones sobre la elegibilidad de su caché. La razón es sencilla: si una página no es apta para el almacenamiento en caché, no queremos su captación previa en la caché del navegador, ya que podría tener consecuencias no deseadas y aumentar la carga de origen. Por ejemplo, la captación previa de una página de cierre de sesión podría cerrar la sesión del usuario antes de que el usuario haya completado realmente su acción. Las solicitudes de captación previa o representación previa con estado pueden tener efectos impredecibles, alterando potencialmente el estado del servidor para acciones que el cliente no ha confirmado. Al permitir solo la captación previa para las páginas que ya están en nuestra caché de CDN, estamos seguros de que esas páginas no afectarán negativamente a la experiencia del usuario.
Estas medidas de seguridad se implementaron para trabajar en entornos donde el rendimiento es una prioridad. A principios de julio de 2024, medimos el impacto de nuestro modelo de implementación conservadora de referencia en todas las páginas de la documentación para desarrolladores de Cloudflare. Descubrimos que podíamos realizar la captación previa del contenido correcto, contenido al que realmente accederían los usuarios, el 94 % del tiempo. Lo hicimos mientras mejorábamos el rendimiento de la navegación al reducir el LCP en el cuantil p75 en un 40 % sin efectos secundarios no deseados. ¡Los resultados fueron increíbles!
Explicación de la implementación de Cloudflare
Nuestra red global abarca más de 330 ciudades y opera a 50 milisegundos del 95 % de la población conectada a Internet. Este amplio alcance nos permite mejorar significativamente el rendimiento de los activos almacenables en caché para nuestros clientes. Al aprovechar esta red para la captación previa inteligente con Speed Brain, Cloudflare puede entregar contenido de la captación previa directamente desde la caché de CDN, reduciendo la latencia de la red prácticamente a cero.
Nuestra posición única en la red nos permite activar automáticamente Speed Brain sin necesidad de que nuestros clientes realicen cambios en la configuración de sus servidores de origen. ¡Es tan sencillo como accionar un interruptor! Ya está disponible nuestra primera versión de Speed Brain.
Cuando el servidor de Cloudflare recibe una solicitud de una página web con Speed Brain activado, devuelve un encabezado de respuesta HTTP "Speculation-Rules" adicional. El valor de este encabezado es una URL que aloja una configuración de Reglas fija (como he mencionado anteriormente).
Cuando el navegador comienza a analizar el encabezado de la respuesta, obtiene nuestra configuración de Speculation-Rules y la carga como parte de la página web.
La configuración indica al navegador cuándo debe realizar la captación previa de la siguiente página probable de Cloudflare a la que puede acceder el visitante, en función de cómo este interactúe con la página.
Cuando una acción del usuario (p. ej., pulsar el botón del ratón en el siguiente enlace de la página) activa la aplicación de Reglas, el navegador envía una solicitud de captación previa para esa página con el encabezado de solicitud HTTP "sec-purpose: prefetch".
Nuestro servidor analiza el encabezado de la solicitud para identificar la solicitud de captación previa. Si el contenido solicitado está presente en nuestra caché, lo devolvemos; de lo contrario, devolvemos un código de estado HTTP 503 y denegamos la solicitud de captación previa. Esto elimina el riesgo de efectos secundarios peligrosos al enviar solicitudes a servidores de origen o Cloudflare Workers que desconocen el uso de la captación previa. Solo se devuelve el contenido presente exclusivamente en la caché.
En una respuesta correcta, el navegador realiza con éxito la captación previa del contenido en la memoria, y cuando el visitante accede a esa página, el navegador carga directamente la página web desde la caché del navegador para su representación inmediata.
Patrones comunes de la resolución de problemas
La compatibilidad con Speed Brain se basa en la API Speculation Rules, un estándar web emergente. A partir de septiembre de 2024, la compatibilidad con este estándar emergente se limita a los navegadores basados en Chromium (versión 121 o posterior), como Google Chrome y Microsoft Edge. A medida que la comunidad web alcance un consenso sobre la estandarización de las API, esperamos ver una adopción más amplia entre otros proveedores de navegadores.
La captación previa, por naturaleza, no se aplica al contenido dinámico, ya que el estado de dicho contenido puede cambiar, lo que podría provocar la entrega de datos obsoletos o caducados al usuario final, así como una mayor carga de origen. Por lo tanto, Speed Brain solo funcionará para las páginas no dinámicas de tu sitio web que estén almacenadas en caché en nuestra red. No afecta a la carga de páginas dinámicas. Para sacar el máximo partido de Speed Brain, te sugerimos que utilices las reglas de caché para garantizar que todo el contenido estático (especialmente el contenido HTML) de tu sitio es apto para el almacenamiento en caché.
Cuando el navegador recibe un código de estado HTTP 503 en respuesta a una solicitud de captación previa especulativa (lo que se indica mediante el encabezado sec-purpose: prefetch), cancela el intento de captación previa. Aunque un error 503 que aparece en la consola del navegador puede parecer alarmante, es completamente inofensivo para la cancelación de la solicitud de captación previa. En nuestras primeras pruebas, el código de respuesta 503 ha causado preocupación a algunos propietarios de sitios. Estamos trabajando con nuestros socios para volver sobre esta cuestión y mejorar la experiencia del cliente, pero por ahora sigue la guía de la especificación, que sugiere una respuesta 503 para que el navegador pueda descartar de forma segura la solicitud especulativa. Estamos en conversaciones con Chrome, a raíz de los comentarios de los primeros usuarios que probaron la versión beta, y creemos que un nuevo código de respuesta dedicado que no indicara error sería más apropiado y causaría menos confusión. Mientras tanto, los registros de respuesta 503 para las solicitudes de captación previa relacionadas con Speed Brain son inocuos. Si tus herramientas dificultan ignorar estas solicitudes, puedes desactivar temporalmente Speed Brain hasta que encontremos una solución mejor con el equipo de Chrome.
Además, cuando un sitio web utiliza sus propias reglas de especulación personalizadas y la función Speed Brain de Cloudflare, ambos conjuntos de reglas pueden funcionar simultáneamente. Las medidas de seguridad de Cloudflare limitarán las reglas de especulación a las páginas almacenables en caché, lo que puede ser una limitación inesperada para aquellos con implementaciones existentes. Si observas este comportamiento, considera la posibilidad de desactivar una de las implementaciones de tu sitio para garantizar la coherencia del comportamiento. Ten en cuenta que si las respuestas de tu servidor de origen incluyen el encabezado Speculation-Rules, no se anulará. Por lo tanto, el potencial de conflictos entre conjuntos de reglas se aplica principalmente a las reglas de especulación en línea predefinidas.
¿Cómo puedo ver el impacto de Speed Brain?
En general, te sugerimos que utilices Speed Brain y la mayoría de las demás funciones de rendimiento de Cloudflare con nuestra herramienta de medición de rendimiento RUM activada. Nuestra función RUM ayuda a los desarrolladores y los operadores de sitios web a comprender cómo sus usuarios finales perciben el rendimiento de su aplicación, proporcionando visibilidad sobre estos aspectos:
Carga: ¿cuánto tiempo ha tardado el contenido en estar disponible?
Interactividad: ¿qué capacidad de respuesta tiene el sitio web cuando los usuarios interactúan con él?
Estabilidad visual: ¿cuánto se mueve la página mientras se carga?
Con RUM activado, puedes acceder a la sección Web Analytics del panel de control para ver información importante sobre cómo Speed Brain ayuda a reducir la latencia en tus métricas Core Web Vitals, como Largest Contentful Paint (LCP) y el tiempo de carga.
Ejemplo de panel de control RUM para un sitio web con una gran cantidad de contenido de captación previa que activó Speed Brain alrededor del 16 de septiembre.
¿Qué hemos observado en nuestra implementación hasta ahora?
Hemos activado esta función por defecto en todos los planes gratuitos y hemos observado lo siguiente:
Dominios
Cloudflare tiene actualmente decenas de millones de dominios que utilizan Speed Brain. Hemos medido el LCP en el cuantil 75 (p75) para estos sitios y hemos observado una mejora de entre el 40 % y el 50 % (de promedio, alrededor del 45 %).
Observamos esta mejora al comparar las captaciones previas de navegación con las cargas de página normales (sin captación previa) para el mismo conjunto de dominios.
Solicitudes
Antes de la activación de Speed Brain, el p75 de los sitios web gratuitos en Cloudflare experimenta un LCP de aproximadamente 2,2 segundos. Con Speed Brain activado, estos sitios se benefician de un importante ahorro de latencia del LCP. En conjunto, Speed Brain ahorra aproximadamente como mínimo 0,88 segundos y hasta 1,1 segundos en cada captación previa correcta.
Navegadores aplicables
Actualmente, la API Speculation Rules solo está disponible en los navegadores Chromium. En Cloudflare Radar podemos ver que aproximadamente el 70 % de las solicitudes de los visitantes proceden de navegadores Chromium (Chrome, Edge, etc.).
En toda la red
Cloudflare observa cientos de miles de millones de solicitudes de contenido HTML cada día. De estas solicitudes, aproximadamente la mitad se almacenan en caché (¡asegúrate de que tu contenido HTML se pueda almacenar en caché!). Alrededor del 1 % de esas solicitudes son para la captación previa de navegación realizada por los visitantes. Esto representa un ahorro significativo cada día para los visitantes de los sitios web que tienen Speed Brain activado. ¡Cada 24 horas, Speed Brain puede ahorrar más de 82 años de latencia!
¿Y después?
Lo que ofrecemos hoy para Speed Brain es solo el principio. De cara a 2025, tenemos previsto explorar y lanzar varias interesantes novedades.
Aprovechar el aprendizaje automático
Nuestra posición única en Internet nos proporciona valiosa información sobre los patrones de navegación web, que podemos aprovechar para mejorar el rendimiento web y garantizar la privacidad de los usuarios individuales. Con un enfoque generalizado de aprendizaje automático basado en datos, podemos definir factores de predicción más precisos y específicos del sitio para la captación previa de las páginas de los usuarios.
Estamos en proceso de desarrollar un modelo especulativo adaptable que mejora significativamente nuestra solución actual de carácter conservador. Este modelo utiliza un método de preservación de la privacidad para generar un gráfico transversal de los usuarios para cada sitio basado en los encabezados Referrer del mismo sitio. Para dos páginas cualesquiera conectadas por un salto de navegación, nuestro modelo predice la probabilidad de que un usuario típico se mueva entre ellas, utilizando información extraída de nuestros datos agregados de tráfico.
Este modelo nos permite adaptar conjuntos de reglas con valores de "eagerness" personalizados para cada enlace de página siguiente relevante de tu sitio. En el caso de las páginas en las que el modelo predice una alta confianza en la navegación del usuario, el sistema realizará agresivamente su captación o representación previa. Si el modelo no proporciona una regla para una página, adopta por defecto nuestro enfoque conservador existente, manteniendo las ventajas del modelo de referencia de Speed Brain. Estos indicadores guían a los navegadores para la captación y la representación previas de las páginas adecuadas, lo que ayuda a acelerar la navegación de los usuarios, al mismo tiempo que se mantienen nuestras medidas de seguridad actuales.
En las pruebas de laboratorio, nuestro modelo de aprendizaje automático mejoró la latencia del LCP en un 75 % y predijo la navegación de los visitantes con una precisión de aproximadamente el 98 %, lo que garantizaba la captación previa de las páginas correctas para evitar el desaprovechamiento de recursos para los usuarios. A medida que avanzamos hacia la ampliación de esta solución, nos centramos en el entrenamiento periódico del modelo para adaptarlo a los distintos comportamientos de los usuarios y a los sitios web en evolución. El uso de un enfoque de aprendizaje automático en línea reducirá drásticamente la necesidad de las actualizaciones manuales y las variaciones de contenido, al mismo tiempo que garantiza una alta precisión (¡la solución de carga Speed Brain que se vuelve más inteligente con el tiempo!).
Observabilidad más precisa mediante RUM
Como hemos mencionado, creemos que nuestras herramientas RUM ofrecen la mejor información sobre cómo Speed Brain ayuda al rendimiento de tu sitio web. En el futuro, tenemos previsto ofrecer la posibilidad de filtrar las herramientas RUM por tipo de navegación para que puedas comparar cómo el navegador representa el contenido de la captación previa frente al contenido sin captación previa.
Representación previa
Actualmente ofrecemos la posibilidad de la captación previa de contenido almacenable en caché. La captación previa descarga el recurso de documento principal de la página antes de la navegación del usuario, pero no indica al navegador que realice una representación previa de la página ni que descargue ningún subrecurso adicional.
En el futuro, la solución Speed Brain de Cloudflare realizará la captación previa del contenido en nuestra caché de CDN y luego trabajará con los navegadores para saber cuáles son las mejores perspectivas para la representación previa. Esto ayudará a acercar aún más el contenido estático a la representación instantánea.
Argo Smart Browsing: Speed Brain y Smart Routing
Speed Brain, en su implementación inicial, proporciona una increíble mejora del rendimiento sin abandonar el carácter conservador en su implementación; tanto desde el punto de vista de "eagerness" como del consumo de recursos.
Como he indicado anteriormente en la publicación, las pruebas de laboratorio de un modelo más agresivo, basado en el aprendizaje automático y un valor más alto de "eagerness", dieron como resultado una reducción del 75 % del LCP. Estamos investigando la posibilidad de agrupar esta implementación adicional más agresiva de Speed Brain con Argo Smart Routing en un producto llamado "Argo Smart Browsing".
Los clientes de Cloudflare podrán seguir utilizando Speed Brain, pero aquellos que quieran mejorar aún más el rendimiento podrán activar Argo Smart Browsing con un solo clic. Con Argo Smart Browsing, el contenido estático almacenable en caché no solo se cargará hasta un 75 % más rápido en el navegador, gracias a los modelos más agresivos, sino que en momentos en los que el contenido no se pueda almacenar en caché y la solicitud deba reenviarse a un servidor de origen, se enviará a través de la ruta de red más eficaz, lo que supondrá de promedio un aumento del rendimiento del 33 %. Las optimizaciones de rendimiento se aplican a casi todos los segmentos del ciclo de vida de las solicitudes, independientemente de si el contenido es estático o dinámico, o si está almacenado en caché o no.
Conclusión
Para empezar a utilizar Speed Brain, ve a Velocidad > Optimización > Optimización de contenido > Speed Brain en el panel de control de Cloudflare y actívalo. ¡Eso es todo! La función también se puede activar a través de la API. Los dominios del plan gratuito tienen activado Speed Brain por defecto.
Recomendamos encarecidamente a los clientes que también activen RUM, que se encuentra en la misma sección del panel de control, para dar visibilidad a las mejoras de rendimiento que ofrece Speed Brain, así como a otras funciones y productos de Cloudflare.
Estamos encantados de seguir desarrollando productos y funciones que aceleran de forma fiable el rendimiento web. Si eres un ingeniero interesado en mejorar el rendimiento de la web para todos, ¡únete a nosotros!