Nuestro concepto de rapidez ha evolucionado. En apenas un siglo, hemos reducido el tiempo necesario para viajar al otro extremo del mundo de 28 días a 17 horas. Hemos desarrollado una vacuna contra un virus causante de una pandemia global en solo un año, es decir, en el 10 % del tiempo habitual. La inteligencia artificial ha reducido el tiempo necesario para las tareas de desarrollo de software en un 55 %. Como sociedad, nos basamos en las cifras, y en la necesidad de batir las ya existentes.
En Cloudflare no nos centramos en las métricas del pasado. No buscamos "caballos más rápidos". En materia de innovación, nos preguntamos más bien qué aspecto tiene para los usuarios, cómo acelera esto realmente Internet y cómo permite al cliente ser más rápido.
Esta semana de la innovación ayudamos a los usuarios a medir lo que importa. Analizaremos una gran variedad de temas que incluyen, entre otros, qué hace que seamos los más rápidos en Zero Trust y lo que hace que tengamos la red más rápida. También exploraremos en profundidad la purga de caché y explicaremos por qué la latencia de la purga global podría no ser el factor de referencia absoluto que nos intentan hacer creer. También abordaremos por qué el Tiempo hasta el primer byte (TTFB) suele ser una medida inadecuada. Y explicaremos en qué es mejor interesarse en su lugar.
Relacionados con estos temas, disponemos de varios nuevos y excelentes productos y funciones que realmente mejorarán tu velocidad y la de tus clientes. Incluyen desde la aceleración de las API y la compresión Brotli 11 de un extremo a otro, a la reducción de los tiempos de carga de las páginas en un 30 % con un solo clic, así como una página de inicio completamente nueva para el rendimiento de las aplicaciones.
Esta semana te ayudaremos a medir lo que importa. Te ayudaremos a obtener información sobre tu rendimiento, desde Zero Trust y las API hasta los sitios web y las aplicaciones. Y, por último, te ayudaremos a ser más rápido. Sin demora.
Demostramos que somos los más rápidos en lo que hacemos. Y facilitamos al máximo que nuestros usuarios logren esa velocidad.
Te damos la bienvenida a la Speed Week.
¿Más megapíxeles?
No hace falta ir muy lejos en la vida real para encontrar ejemplos de métricas sumamente promocionadas que probablemente no reflejan lo que realmente te importa.
Si lees sus anuncios año tras año, podrías pensar que los teléfonos inteligentes se han convertido en cámaras con aplicaciones y una antena. Los comunicados de prensa de cada nuevo modelo que sale al mercado hacen referencia a las mejoras en cuanto al número de megapíxeles respecto al modelo anterior.
El número de megapíxeles por sí solo no garantiza una mejor calidad de la imagen. Otros factores como el tamaño del sensor, la calidad de la lente, los algoritmos de procesamiento de imágenes y el rendimiento en condiciones de poca luz también desempeñan un papel importante a la hora de determinar el rendimiento general de una cámara. Es un hecho ampliamente aceptado desde hace ya más de una década. Entonces, ¿por qué las empresas siguen usando esta métrica? ¿Y por qué les parece tan importante a los usuarios?
De la misma forma, si lees el material de marketing de los proveedores de acceso a Internet, parece que el ancho de banda es lo único que importa.
Sin embargo, está categóricamente demostrado que el ancho de banda no es el único indicador de la velocidad. Hace apenas dos meses publicamos un artículo en el blog titulado "Acelerar el servicio de Internet en casa tiene poco que ver con la velocidad". En este artículo llegábamos a la siguiente conclusión: "Si bien el ancho de banda desempeña un papel importante, la latencia de la conexión, la velocidad real de Internet, adquiere aún mayor relevancia_"_. La publicación hace referencia a un estudio reciente de dos investigadores del MIT que defienden este punto y señalan que el punto de rendimiento decreciente es aproximadamente de 20 Mb/s, es decir, a partir de esa cifra más ancho de banda no significa que una página web se cargue mucho más rápido.
Aquí nos encontramos una vez más que la métrica de comparación publicitada y generalmente aceptada es incorrecta. Más ancho de banda no equivale a velocidades de Internet más rápidas.
En pocas palabras, ¿analizas realmente las métricas que te importan a la hora de elegir productos y proveedores? ¿O bien te has dejado llevar durante demasiado tiempo por las creencias imperantes?
Medir lo que importa en Internet
Al igual que en los sectores de los teléfonos inteligentes y los proveedores de acceso a Internet, en Cloudflare operamos en sectores donde los usuarios a menudo nos comparan con la competencia utilizando métricas que probablemente no miden lo que realmente les importa.
Las grandes empresas utilizan software para cambiar selectivamente entre redes de entrega de contenido (CDN) en función de la puntuación del Tiempo hasta el primer byte (TTFB) por región. Es decir, si Cloudflare de repente redujera a la mitad su TTFB en África, por ejemplo, podríamos observar una enorme afluencia de tráfico en esta región debido a estos clientes empresariales (probablemente sin ninguna mejora en la experiencia real de los visitantes de un sitio web).
El TTFB es una métrica que se suele utilizar para medir la rapidez con la que un servidor web responde a una solicitud, y los servicios comunes de pruebas web la incluyen. A mayor rapidez, mejor es el servidor web (en teoría). No obstante, ya hace años que sabemos que el TTFB por sí solo no refleja fielmente el rendimiento real.
La recepción del primer byte no es suficiente para determinar una buena experiencia del usuario final, puesto que la mayoría de las páginas tienen recursos de bloqueo de representación adicionales que se cargan tras la solicitud inicial del documento. El TTFB no tiene en cuenta los beneficios de la multiflexación de HTTP/2 y HTTP/3 que permiten que los navegadores carguen archivos en paralelo, ni funciones como Early Hints, Zaraz, Rocket Loader, HTTP/2 y en breve HTTP/3 Prioritization que eliminan el bloqueo de representación.
Sitespect escribió el año pasado que "El TTFB es una medida de la rapidez con la que un servidor web puede responder a una solicitud, y del tiempo necesario para que esa solicitud atraviese distintas capas de red hasta llegar al navegador de un usuario. Es una medida de la velocidad de la entrega de contenido, pero no es una medición de cuánto tiempo los usuarios finales esperan realmente hasta que pueden empezar a interactuar con tu sitio web. El TTFB ignora por completo todo lo que sucede después de esa capa de red: la carga, la descarga de recursos, la representación, etc. En otras palabras, el TTFB no es una medición centrada en los usuarios, sino una medición centrada en la red".
En Cloudflare estamos totalmente comprometidos con la Supervisión de usuarios reales (RUM) como herramienta para el futuro del rendimiento de los sitios web. Estamos invirtiendo mucho en esta área, tanto desde la perspectiva de la observación como desde la de la optimización. Esta semana lanzaremos una serie de nuevos productos cuyo objetivo es ayudar a los usuarios a comprender la experiencia real de sus usuarios finales (es decir, los visitantes del sitio web) y a proporcionar sugerencias sobre cómo mejorarla.
Para aquellos que no conozcan RUM: para optimizar los sitios web normalmente utilizamos tres métricas principales, conocidas como "Core Web Vitals". Se trata de un conjunto de métricas clave que se cree que son la representación mejor y más precisa para diferenciar entre un sitio web con un rendimiento deficiente y un sitio web con un buen rendimiento. Estas métricas clave son Largest Contentful Paint, First Input Delay y Cumulative Layout Shift.
Fuente: https://addyosmani.com/blog/web-vitals-extension/
LCP mide el rendimiento de la carga, normalmente cuánto tiempo es necesario para cargar la imagen o el bloque de texto más grande visible en el navegador. FID mide la interactividad. Por ejemplo, el tiempo que transcurre entre el momento en el que un usuario hace clic o pulsa un botón y el momento en el que el navegador responde y empieza a realizar alguna acción. Por último, CLS mide la estabilidad visual. Un buen o mal ejemplo de CLS es cuando vas a un sitio web en tu teléfono móvil, tocas en un enlace y la página se mueve en el último segundo, lo que hace que toques algo que no tenías intención de tocar. Esto representaría una puntuación de CLS más baja ya que la experiencia del usuario es deficiente.
Estas métricas nos permiten comprender cómo es la experiencia real del usuario (RUM) frente a la rapidez con la que el centro de datos de Cloudflare más cercano empieza a devolver datos (TTFB).
Un beneficio adicional de la Supervisión de usuarios reales es que incluye la ventaja de la velocidad mediante nuevos protocolos y funciones diseñados para mejorar la experiencia del cliente. Por ejemplo, el Tiempo hasta el primer byte (TTFB) es una conexión única entre el cliente y el servidor de Cloudflare más cercano. Esto es totalmente distinto a cómo un navegador web se conecta a un sitio web, cuando utiliza la multiplexación para obtener varios archivos al mismo tiempo en paralelo. También hay productos como Early Hints diseñados para aprovechar el "tiempo de reflexión del servidor" para enviar instrucciones al navegador a fin de que empiece a cargar recursos ya disponibles mientras el servidor acaba de compilar la respuesta completa.
Con ocasión de la Speed Week analizaremos en profundidad por qué el TTFB no es una métrica adecuada para los sitios web y las aplicaciones web y por qué RUM es el futuro. Además, publicaremos un artículo en el blog sobre la última métrica Core Web Vital, “Interaction to Next Paint” (INP), y qué implica para tu negocio.
También presentaremos un producto completamente nuevo que será la nueva página de inicio del rendimiento de aplicaciones en Cloudflare. Este nuevo producto mejorará las pruebas sintéticas de diversas ubicaciones globales con datos de supervisión de usuarios reales a fin de que los administradores comprendan lo mejor posible el rendimiento de su sitio web en el mundo real. Este producto estará disponible para todos los planes.
Somos los más rápidos, y podemos probarlo
No es ningún secreto que Cloudflare es rápido.
Sin embargo, es posible que no sea evidente para el lector común cuán rápidos somos, y en cuántas áreas. La computación más rápida. El DNS más rápido. La red más rápida. El acceso a la red Zero Trust (ZTNA) más rápido. La puerta de enlace web segura (SWG) más rápida. El almacenamiento de objetos más rápido. Y descubrimos áreas donde no somos empíricamente los más rápidos y esperamos demostrar que somos el número uno.
También estamos encontrando la forma más rápida posible de migrar a Cloudflare los clientes de proveedores y aplicaciones heredados. Mediante el uso de terminología confusa y de funciones difíciles de comprender, estos proveedores han logrado que las empresas dependan de ellos, por lo que estas se encuentran atrapadas con productos deficientes y temen abandonarlos. Estamos ayudando a estos clientes a escapar. Super Slurper ayuda a los clientes a abandonar S3, Turpentine les ayuda a migrar las configuraciones de VCL heredadas a Cloudflare, y nuestro programa Descalehttps://blog.cloudflare.com/descaler-program/ ayuda a migrar los clientes de Zscaler a Cloudflare en solo unas horas. Estamos desarrollando herramientas y productos a fin de ayudar a los clientes que desean trasladarse a la red más rápida, pero que se encuentran bloqueados.
Con ocasión de la Speed Week, abordaremos las últimas novedades de estos programas, y cómo nos esforzamos sin descanso para lograr que el proceso de migración sea lo más rápido y fácil posible para los clientes que desean pasar a Cloudflare y poner su negocio en la red más rápida.
El rendimiento importa, sea cual sea el área del producto
Cuando escuchas hablar de mejoras de rendimiento, suele ser desde la perspectiva de la mejora de la velocidad de los sitios web. Pero la velocidad adopta muchas formas. Veamos Zero Trust, por ejemplo.
La medición del rendimiento Zero Trust importa porque afecta a la experiencia de tus usuarios y a su capacidad para realizar su trabajo. Tanto si se trata de acceder a servicios mediante productos de control de acceso, de conectarse a la red pública mediante una puerta de enlace web segura, o de proteger los sitios externos en riesgo mediante el aislamiento remoto del navegador, todas estas experiencias deben realizarse sin dificultades. Pero, ¿qué pasaría si la puerta de enlace web segura de tu empresa estuviera en Londres y tú estuvieras en Johannesburgo? Esto puede significar para los usuarios una experiencia difícil, lenta y frustrante, mientras esperan el envío del tráfico a Londres y su regreso. Slack funciona con lentitud. Zoom funciona con lentitud. Los usuarios se sienten frustrados.
El mayor problema, sin embargo, es no ser consciente de estos problemas de rendimiento. Por ejemplo, si todos tus usuarios se encuentran ubicados físicamente en una oficina y empeora la conexión a los sistemas comerciales críticos como Salesforce o Workday, es probable que esto rápidamente se haga evidente. Sin embargo, ¿y si tus usuarios trabajan en remoto y están distribuidos por todo el mundo? Como empresa, necesitas poder comprender cómo es la experiencia de tus usuarios con los sistemas comerciales críticos e identificar cualquier problema de conexión y rendimiento que puedan tener a fin de garantizar su rápida resolución. Durante la Speed Week revelaremos nuestra última solución Zero Trust que proporcionará a los directores de informática y a las empresas importante información sobre cómo es la experiencia de sus usuarios con el rendimiento.
La Speed Week mostrará que Cloudflare es el proveedor Zero Trust más rápido. Nuestros análisis proporcionarán comparaciones de referencia actualizadas e incluirán competidores adicionales a fin de mostrar cómo somos los mejores y ofrecemos a los usuarios la experiencia Zero Trust más rápida.
Otro tema destacado de esta semana será la purga de caché. Cuando piensas en las CDN, es habitual considerarlas como una gran caché distribuida. Los archivos que solicitan los visitantes se obtienen de un origen y se almacenan en servidores CDN distribuidos globalmente. Esto permite a los visitantes descargar el archivo de la forma más rápida posible al obtenerlo de su centro de datos de Cloudflare más próximo, en lugar de tener que atravesar Internet hasta y desde el origen. El TTFB medirá el tiempo necesario para recibir un archivo individual desde la ubicación más cercana. RUM medirá el tiempo necesario para recibir varios archivos (almacenados en caché y no almacenados en caché) y ponerlos juntos en la página web solicitada. Pero, ¿qué pasa si el archivo cambia en origen?
Imaginemos que una empresa aloja una lista de precios como un archivo descargable en su sitio web. En esta situación, es importante comprender cuánto tiempo requiere eliminar las copias anteriores de la caché de Cloudflare a fin de garantizar que los clientes no vean precios incorrectos. Aquí es donde la medición de los tiempos de purga de caché es importante. El tiempo necesario para eliminar el archivo invalidado (obsoleto) de todos los servidores de todos los centros de datos de la CDN se conoce como el "tiempo de purga global". Durante la Speed Week explicaremos cómo hemos desarrollado nuestra nueva arquitectura de purga de caché para que sea ultrarrápida y, como resultado, cuáles son sus cifras de rendimiento (spoiler: son increíblemente rápidas).
Estos son solo algunos ejemplos de lo que tenemos preparado para este semana. También habrá publicaciones del blog sobre inteligencia artificial, la aceleración de las API, la plataforma para desarrolladores, redes, protocolos, compresión, transmisión, optimización de la interfaz de usuario ¡y mucho más!
La velocidad, en el ADN de Cloudflare
En Cloudflare, ponemos el rendimiento en el ADN de todo lo que hacemos.
Asegúrate de seguir el blog de Cloudflare y nuestras cuentas de las redes sociales para no perderte las novedades de la semana. Acompáñanos en Cloudflare TV cada día para ver debates en directo sobre los anuncios del día.
Te damos la bienvenida a la Speed Week.