Fastly proporciona el primer byte antes que nadie
Poco después de nuestra entrada del blog del 2 de noviembre, que repasaba nuestras ventajas con respecto a la CDN de Akamai, volvemos con nuevos datos que arrojan un 29 % de mejora en el tiempo hasta el primer byte en comparación con la CDN de Edgio. Veamos más a fondo por qué esta métrica es representativa del rendimiento general.
Como comentamos en la entrada anterior, resulta complicado comparar distintas CDN. Surgen muchas preguntas básicas, como qué métrica usar, qué conjunto de datos buscar y qué sitios analizar. Vamos a repasar nuestra metodología y fundamento para demostrarte que tu sitio es más rápido (y seguro) si te pasas a Fastly
Garantizar una cantidad suficiente de datos
El tiempo hasta el primer byte (TTFB) es la única métrica relacionada con datos de uso reales que se puede atribuir directamente a la CDN encargada de su distribución a un número elevado de sitios web. Otras métricas, como el Largest Contentful Paint (LCP), pueden verse afectadas por aspectos como la ejecución de JavaScript en el lado del cliente, una configuración deficiente del sitio web y la integración de contenidos de terceros. Además, en el caso de los despliegues con CDN múltiples, la distribución del dominio y el primer byte pueden correr a cargo de una CDN, mientras que otras se ocupan de distribuir otros contenidos. No existe, pues, ningún método para relacionar los contenidos distribuidos después del TTFB con CDN concretas, a diferencia de lo que ocurre con el primer byte.
El problema no es que se distribuyan los contenidos desde una CDN al principio y otra después, sino que las grandes empresas suelen contar con CDN múltiples, cada una enfocada a un tipo de contenido. Los vídeos pueden proceder de una, las imágenes de otra y así sucesivamente. Cada vez que visitas un sitio web en cuestión, las CDN múltiples contribuyen al LCP, pero sus datos son imposibles de separar.
Como queríamos estar en lo cierto, fuimos un paso más allá y estudiamos los datos para confirmar si la mejora del TTFB con Fastly guardaba relación directa con el LCP relativo de los clientes, y logramos confirmarlo. Profundizaremos en este tema más adelante, pero quedémonos con que las mejoras en el rendimiento (un 29 % superior al de la CDN de Edgio) no eran casos aislados ni requerían hacer sacrificios en otros aspectos, sino que venían con un LCP superior bajo el brazo.
Creemos que la mejor manera de analizar todo esto es emplear datos obtenidos de usuarios reales que utilizan navegadores reales a lo largo y ancho del mundo. Para ello, tuvimos que fijarnos en el TTFB y utilizar tanto el informe sobre la experiencia de uso en Chrome (CrUX) de Google como su conjunto de datos.
Por qué elegimos el tiempo hasta el primer byte
CrUX es el conjunto de datos oficial del programa Métricas web, una iniciativa de Google cuyo objetivo es proporcionar una guía unificada de los indicadores esenciales de una excelente experiencia de uso en la web. Google puso en marcha este programa para explicar qué considera importante, cómo lo cuantifica y cómo define un buen rendimiento; de modo que quienes se encargan de gestionar los sitios web sepan qué deben hacer para obtener reconocimiento por parte de Google en forma de una mejor clasificación en los resultados, una mayor optimización en buscadores (SEO) y, por tanto, un volumen de tráfico superior.
Como estos datos proceden de usuarios reales de Chrome de todo el mundo y se recopilan a lo largo del tiempo, podemos dar por hecho que representan experiencias reales de visitas a sitios web y que no son sintéticos. Estos datos expresan con más exactitud la manera en que la proporción de aciertos de caché (CHR), la proximidad a los servidores, el enrutamiento optimizado, un equilibrio de carga eficiente y otros factores afectan al rendimiento de un sitio web, ya que se recopilan en distintas zonas geográficas y horas del día, con sus correspondientes altibajos en el tráfico, e indican cómo un sitio gestiona la carga en determinados momentos. Por lo tanto, son una buena forma de saber qué ocurre cuando no llevas las riendas del experimento y qué experiencia tienen los usuarios con tu sitio web en internet. Otra de las ventajas de CrUX es que cuenta con una API muy intuitiva que nos permite realizar consultas sobre los datos correspondientes una y otra vez. Además, se trata de una fuente fiable y basada en una enorme cantidad de datos.
El TTFB es una de las métricas web de Google, pero no se considera una de las principales a pesar de que se recoge junto a otras de las que figuran en el informe de CrUX. Esto significa que, al contrario que el LCP y otros aspectos, el TTFB no quita puntos a tu sitio web en caso de que esté por debajo de lo recomendado por Google. De todas formas, un buen TTFB sigue siendo clave para el rendimiento web, ya que el TTFB precede y, por tanto, afecta al LCP. Cuando Google mide el LCP, tiene en cuenta el TTFB y otras métricas de forma indirecta. En otras palabras, conviene prestarle atención cuando no es posible acudir a otras métricas, como ocurre en este caso.
Inconvenientes de los datos de CrUX:
El conjunto de datos de CrUX muestra las métricas del TTFB y el LCP, entre otros aspectos, como valores del P75. Esto significa que las cifras proporcionadas representan el valor más bajo de una métrica para el 75 % de los usuarios que obtienen mejores resultados durante los últimos 28 días. El 25 % restante, que se corresponde con las puntuaciones más bajas, se despeja de la ecuación para reflejar el rendimiento de un sitio web con mayor precisión y dejar algo de margen para lo que escapa a su control. Este subconjunto incluye dispositivos o conexiones que funcionan con lentitud, además de problemas transitorios cuyas repercusiones en los tiempos de carga no deben restar puntos en lo relativo al rendimiento. Al no contabilizarlo, Google se asegura de que los parámetros reflejen con exactitud el rendimiento de un sitio web y no se vean sesgados por culpa de casos aislados.
En dispositivos móviles, estos datos se obtienen únicamente del navegador Chrome, y nunca en iOS. Aunque siguen abarcando una gran diversidad de experiencias, se limitan a usuarios de Chrome en dispositivos Android, ya que iOS impone restricciones a la recopilación de datos en las aplicaciones. En ordenadores personales, también se obtienen únicamente del navegador Chrome (nada de Firefox, Safari, Edge y demás), pero en este caso sí se incluyen sistemas operativos como macOS, Windows y Linux. Por último, no se tienen en cuenta el tráfico ni los datos de China.
En nuestra opinión, el valor que aportan los datos reales de CrUX compensa con creces la falta de representación de iOS y los datos de China, por ejemplo. Además, es de esperar que las diferencias de rendimiento sean similares o iguales en iOS y otros navegadores, ya que el TTFB hace referencia a los primeros datos que llegan a un navegador, y el tipo de navegador y dispositivo no debería afectar demasiado a los resultados.
Si quieres obtener más información, aquí se explican los criterios que sigue Google a la hora de incluir datos de uso en CrUX: https://developer.chrome.com/docs/crux/methodology/?hl=es-419#user-eligibility
Por qué escogimos la lista de CrUX
Como ya explicamos en la entrada anterior, para la prueba del TTFB con Akamai nuestro conjunto de datos fue la lista Fortune 500. Sin embargo, a la hora de realizar las presentes pruebas tuvimos claro que el número de empresas de la Fortune 500 que usase Edgio para distribuir el primer byte sería bajísimo. Esto planteaba el riesgo de que los datos fueran muy parciales, así que recurrimos a la lista de CrUX para obtener una representación equilibrada de los sitios web más populares. En un principio probamos los 10 000 sitios web más populares, pero luego los ampliamos a 50 000 para que la muestra de Edgio y la comparativa de promedios fuesen suficientemente amplias. Por último, en nuestra investigación nos decantamos por los valores medianos para eliminar la distorsión que pudieran introducir sitios web muy lentos.
(Si quieres más información acerca de la lista de CrUX, con una evaluación de precisión externa incluida, visita https://zakird.com/papers/toplists.pdf)
Cómo supimos qué CDN tiene el mejor tiempo hasta el primer byte
Utilizamos nuestra herramienta interna de detección de CDN para ejecutar ocho detecciones con respecto a cada origen desde el 1 de diciembre de 2023 a las 18:13 hasta el 4 de diciembre de 2023 a las 10:27. Cada una de ellas consistió en enviar una consulta al servidor de DNS público de Google y detectar la CDN comparando el siguiente contenido con un archivo de configuración de proveedores y valores conocidos:
Registros de nombre canónico (*.fastly.net, *.edgekey.net, etc.)
Asignaciones de IP a ASN
Las mejoras en el TTFB y el LCP van de la mano con Fastly
Para ir un paso más allá, nos fijamos en la relación existente entre el TTFB y el LCP (Fastly frente a Edgio) para asegurarnos de que el TTFB del que disfrutan nuestros clientes traía consigo un mayor rendimiento en lo relativo a otras métricas, como el LCP. Si alguna empresa hubiera utilizado algún método que mejorara el TTFB a costa del LCP o los tiempos de carga en su totalidad, lo habríamos descubierto en este paso, al igual que si la superioridad de Fastly se limitara al TTFB y tuviera peores resultados que la competencia en cuanto al LCP. Nos complace anunciar que nuestros resultados del LCP fueron netamente mejores: ¡Edgio fue un 22 % más lento!
La velocidad importa
Se ha demostrado una vez tras otra que cualquier retardo en la experiencia online puede conllevar una pérdida en fidelidad y en otros terrenos, además de aumentar el riesgo de que se abandonen carritos de la compra y procesos similares.
La velocidad a la que se ofrecen datos a los lectores, clientes y demás usuarios puede marcar la diferencia entre el éxito y el fracaso de una interacción. Lo bueno es que, como acabamos de demostrar, según qué CDN elijas, tu sitio puede distribuirse a una velocidad mucho mayor.
La velocidad siempre ha sido la razón de ser de Fastly, y la seguirá siendo. Nos encantaría mostrarte las ventajas competitivas que aporta pasarse a una CDN moderna.
Resultados al completo
Cada uno de los números agregados que se muestran a continuación es la mediana de las puntuaciones del P75 de todos los orígenes de sitios web de cada CDN, recopiladas a partir de datos de 28 días de usuarios correspondientes de Chrome (Fastly: 5/11/2023 - 2/12/2023; Edgio: 7/11/2023 - 4/12/2023)
Principales 50 000 orígenes de CrUX (proveedor del dominio):
1213 orígenes de Fastly:
TTFB: 554 ms
LCP: 1994 ms
121 orígenes de Edgio:
TTFB: 713 ms (159 ms/29 % más lento que Fastly)
LCP: 2426 ms (432 ms/22 % más lento que Fastly)
