El rendimiento de una web es un factor poco negociable para el usuario final. Por eso es habitual que los equipos técnicos evalúen cómo se comporta su plataforma al pasar por una CDN como la de Transparent Edge. Pero algunas pruebas pueden quedar distorsionadas al centrar la atención en indicadores poco precisos o emplear pruebas o herramientas online poco fiables. 

En este post abordamos los puntos más conflictivos y realizamos algunas recomendaciones para que las comparativas de rendimiento se ejecuten de la mejor manera, ¡toma nota!

Qué parámetros debemos medir: latencia vs TTFB

En el sentido estricto del término, la latencia es el tiempo que tarda en ir y volver un paquete de un punto a otro, sin procesamiento. Es decir, un servidor puede tener una latencia muy buena, pero dar unos tiempos de entrega malos, por diversas razones. 

La latencia suele calcularse mediante pings, pero no es una métrica adecuada desde el punto de vista de la entrega web. El tráfico ICMP no tiene nada que ver con el tráfico real de HTTP por TCP, ya que es más variable y no tiene en cuenta que los nodos intermedios entre usuarios y servidor normalmente hacen shaping. De manera que una latencia más baja por ICMP/ping no garantiza una mejor respuesta en la entrega de contenidos. 

La latencia queda, por tanto, descartada. Y, aunque no sea la métrica definitiva, sí nos da una respuesta más precisa el TTFB o Time to First Byte. Este dato mide el tiempo que transcurre entre el envío de una solicitud por parte de un usuario final hasta que se recibe el primer byte de la respuesta. Esto lo convierte en el indicador más interesante (también para los Core Web Vitals y expertos en performance web como Illya Grigorik) con el que interpretar las comparativas de rendimiento.

Cómo realizar una comparativa de rendimiento

Las pruebas de carga son la alternativa más recomendada, ayudan a comprender cómo funcionará un sistema bajo la carga de usuarios esperada. Pero hacer este test en frío para contenido en una CDN requiere tener en cuenta una serie de consideraciones. De no hacerlo, es muy probable que los resultados queden distorsionados, por lo que esas pruebas no habrán servido para nada. 

Cuatro  aspectos  importantes  a la hora de  realizar las pruebas

1. Registra si el contenido está en frío en CDN antes de realizar la prueba porque esto se refleja en el resultado. La entrega de contenido que hace la CDN es más rápida cuanto más tráfico del mismo site esté entregando. La razón es que se cachea en memoria. Es lo que llamamos HIT. Si el contenido solicitado no está en la caché, habrá que bajar a origen a buscarlo. Es lo que llamamos MISS. En este caso y, debido al salto de red adicional, el tiempo de entrega será ligeramente más elevado, incluso por encima del que tardaría el usuario en acceder directamente al origen del sitio.
2. Considera si el nodo tiene el contenido en caché. En el caso de Transparent Edge, por la propia arquitectura de la CDN, la caché de los distintos nodos no está compartida entre ellos. Que una petición haga HIT en uno, no implica que una petición igual dirigida a otro nodo de la misma zona geográfica vaya a ser también un HIT. Es importante tenerlo en cuenta al hacer pruebas en frío, si bien tiene menos relevancia en el caso de estar cursando tráfico real, ya que este se distribuye de manera equitativa entre los distintos nodos de la misma zona. 
3. Identifica qué uso se hace de VPNs ya que puede distorsionar los resultados. Una VPN, por definición, está añadiendo una latencia de red entre la IP de salida de la VPN y el otro extremo de la conexión en el cliente. Este salto no siempre es predecible ni consistente, por lo que puede desvirtuar las mediciones.
4. Ten en cuenta a la hora de analizar los datos que las pruebas sintéticas y el tráfico real muchas veces difieren por la simplificación que suponen las primeras, que no tienen en cuenta cosas como el cacheo de resolución DNS del navegador, el pinning de certificados SSL, las opciones de precarga de contenidos, etc.

Cuidado con los sesgos de algunas herramientas online

Más allá de esto, hay que tener en cuenta que las herramientas online que suelen emplearse para realizar este tipo de pruebas también pueden tener sus propios sesgos. 

Aunque generalmente dan un buen resultado, las herramientas online que chequean el tiempo de respuesta no dejan de ser clientes HTTP. Estas herramientas están alojadas habitualmente en datacenters cloud, lo que significa que  el peering de un datacenter concreto es determinante y puede dar un resultado mejor que el real. Por ejemplo,  si la página medida se encuentra en AWS y la herramienta de testing también, la latencia y el TTFB (time to first byte) van a ser mucho menores que los de un cliente real.

La única métrica fiable es la del usuario final. Las herramientas de RUM (real user monitoring) dan un indicativo real de cómo se comporta el site para los usuarios que lo visitarán. Todo lo demás son aproximaciones, más o menos realistas, de cómo se puede comportar el sitio web en producción.

Ayuda  con el análisis de datos

En Transparent Edge facilitamos siempre las cosas. Por eso, nos ponemos a disposición de clientes o potenciales clientes para ayudarles a hacer este tipo de test. Por ejemplo, si nos dicen desde dónde van a hacer las pruebas, podemos precalentar el contenido en los nodos que servirían a esa ubicación de cara a obtener unos resultados más similares a los de producción. Resuelve cualquier duda con nuestro equipo de expertos.