Fastly tiene un tiempo hasta el primer byte más rápido. Y eso se nota.

Comparar CDN no es tarea fácil. Podemos preguntarnos muchas cosas, como qué métrica o qué conjunto de datos usar y en qué sitios web fijarse, pero en Fastly nos gustan los retos, así que vamos a ir a por todas. Aunque las cifras hablan por sí solas, vamos a dedicar este artículo a detallar nuestra metodología y nuestro razonamiento para que veas por qué tu tráfico gana en velocidad (¡y en seguridad!) con Fastly.

Por qué elegimos el tiempo hasta el primer byte

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 otros aspectos de la distribución de 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 u otra según la ocasión, sino que las empresas más grandes, como las que figuran en la lista Fortune 500, 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 estos contenidos llegan al sitio web en cuestión, las CDN múltiples contribuyen al LCP, pero sus datos son imposibles de separar. 

Como queríamos asegurarnos, fuimos un paso más allá y estudiamos los datos para constatar que la mejora del TTFB con Fastly repercutía de forma positiva en el LCP relativo para los clientes, y estábamos en lo cierto. Profundizaremos en este tema más adelante, pero quedémonos con que las mejoras en el rendimiento (un 32 % superior al de otras CDN y un 43 % superior a la de Akamai) 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 conjunto de datos de CrUX

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 no quita puntos a tu sitio web en caso de que esté por debajo de lo recomendado por Google. Google prefiere fijarse en aspectos como el LCP por los motivos explicados anteriormente, pero lo cierto es que un buen TTFB hace mucho a favor del rendimiento de un sitio web. Al fin y al cabo, el TTFB va antes que el LCP, por lo que afecta a esta métrica. 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 los tiempos del TTFB y el LCP, entre otros aspectos, como valores 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 no dejan de abarcar una gran diversidad de experiencias, se limitan a usuarios de Chrome en dispositivos Android porque 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é elegimos la lista Fortune 500

Sabemos que es fundamental representar a empresas de muchos sectores y queríamos tener en cuenta a grandes organizaciones, experiencias web de gran complejidad y distintos casos de uso que requieren presencia digital. Utilizamos la lista Fortune 500 como punto de partida, ya que incluye las 500 empresas de Estados Unidos con mayores ingresos de todos los sectores, cada una con unas necesidades y unos objetivos concretos con respecto a sus sitios web. Estas empresas suelen ser grandes, complejas y disponer de una amplia presencia digital en la que una CDN puede desempeñar un papel más importante en el día a día que en un sitio web personal o de una empresa con menor alcance. Sacamos nuestra lista con los dominios de las empresas Fortune 500 de este sitio web el 17 de octubre. La lista original de Fortune solo está disponible mediante pago y, como queríamos que todo el mundo pudiera contrastar nuestros datos, decidimos utilizar esta versión.

Cómo supimos qué CDN tiene el mejor tiempo hasta el primer byte

Una vez elegida la lista Fortune 500 como punto de partida, utilizamos nuestra herramienta interna de detección de CDN para llevar a cabo 20 detecciones en cada origen entre el 17 de octubre a las 23:19 y el 18 de octubre a las 16:07. Cada una de ellas consistió en enviar una consulta al servidor de DNS público de Google, hacer una petición HTTP al origen y detectar la CDN comparando el siguiente contenido con un archivo de configuración de proveedores y valores conocidos: 

• Encabezados de respuesta HTTP (server, X-cache, etc.)

• Registros de nombre canónico (*.fastly.net, *.edgekey.net, etc.)

• Asignaciones de IP a ASN

Encontramos dos orígenes de sitios web con CDN múltiples para el nombre del host del origen. En estos casos, el primer byte de las peticiones se puede distribuir mediante distintas CDN, por lo que decidimos excluirlos del análisis. También encontramos 35 orígenes de sitios web que se pasaban del límite de 60 segundos para los encabezados, así que también se quedaron fuera. Conviene mencionar que 34 de ellos corrían a cargo de Akamai y que uno no tenía CDN. Si los hubiéramos incluido en el análisis, Fastly habría ampliado su ventaja hasta el 46 % frente a la CDN de Akamai y hasta el 34 % frente a otras CDN. 

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 Akamai y otros proveedores) 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. Y, sorpresa, nuestro LCP también le saca dos dígitos de ventaja a Akamai. El LCP de Akamai es un 21 % más lento que el de Fastly y el de las demás CDN es un 7 % más lento.

La lista Fortune 500 es demasiado pequeña y contiene demasiados despliegues de CDN múltiples como para comprobar el LCP de manera eficaz, ya que no se puede atribuir a una sola CDN el resultado que obtienen entre varias. Solo se pueden comparar sitios web con despliegues completos en los que una CDN distribuye tanto el dominio como todo el contenido. Muy pocas empresas de la lista Fortune 500 contaban con distribución de todo el sitio, así que decidimos ampliar el conjunto de datos. Para ello, utilizamos el mismo método de detección de CDN con la lista de los 10 000 sitios principales de CrUX, que consistió en realizar 20 peticiones de detección de CDN durante un intervalo de 24 horas. Si todos los proveedores de dominios y activos procedían de una única CDN, considerábamos que un sitio la utilizaba para la distribución de todo el sitio. Incluso con este volumen de datos, solo pudimos confirmar la distribución de todo el sitio para 176 dominios distribuidos por Fastly y algo más del triple en el caso de Akamai.

A continuación, enviamos una consulta a la API de CrUX para conocer el LCP de los dominios con distribución de todo el sitio y, como también aparecía representado en estos datos, nos fijamos en la relación entre la ventaja en el TTFB con Fastly y la diferencia en el LCP con Fastly. Los datos indicaron un rendimiento del LCP muy favorable para la distribución con Fastly, que sacaba un 21 % de ventaja a la CDN de Akamai y un 7 % de ventaja a otras CDN.

Resultados al completo

Los datos agregados de abajo representan la media de las puntuaciones del P75 de todos los orígenes de sitios web gestionados por cada CDN.

Orígenes de sitios web de empresas Fortune 500 (proveedor de dominios):

25 orígenes de Fastly:

• TTFB: 843 ms

116 orígenes de Akamai:

• TTFB: 1208,4 ms (365,4 ms/43 % más lento que Fastly)

Todas las CDN excepto los 354 orígenes de Fastly:

• TTFB: 1111,3 ms (268,3 ms/32 % más lento que Fastly)

10 000 orígenes principales de CrUX (distribución de todo el sitio):

176 orígenes de Fastly:

• LCP: 2274,3 ms

555 orígenes de Akamai:

• LCP: 2757,8 ms (483,5 ms/21 % más lento que Fastly)

Todas las CDN excepto los 5741 orígenes de Fastly:

• LCP: 2444,7 ms (170,4 ms/7 % más lento que Fastly)