Ahora estoy trabajando en un proyecto para un cliente. Este es un sitio de comercio electrónico, por lo que estoy muy interesado en algunos aspectos del rendimiento. Para empezar, estos son varios indicadores que caracterizan el tiempo de carga de un sitio. A continuación, este es el momento de inicio de la presentación de la página, lo cual es importante para aquellos visitantes que, después de ingresar al sitio, desean ver su contenido lo más rápido posible (naturalmente, todos los visitantes del sitio entran en esta categoría). Entre los indicadores de rendimiento que me interesan están aquellos que reflejan los detalles de las actividades de mi cliente. Por ejemplo: "¿Qué tan rápido se carga la imagen principal del producto?" Un análisis de todos estos indicadores puede proporcionar información valiosa sobre el estado del proyecto.
Sin embargo, hay un indicador que, como parece, los desarrolladores front-end a menudo no prestan suficiente atención. Ya es hora del primer byte (Tiempo hasta el primer byte, TTFB). Puede comprender esto, puede perdonar a los desarrolladores, y al menos parcialmente, esta actitud hacia TTFB, especialmente teniendo en cuenta el hecho de que ven este indicador como algo que depende solo del back-end de los proyectos. Pero si tratamos de expresar literalmente brevemente el problema con respecto a este indicador, entonces podemos decir lo siguiente: "Aunque un buen valor TTFB no necesariamente significa que el sitio web que demuestra que se puede considerar rápido, un indicador TTFB pobre casi seguro indica problemas con el rendimiento del proyecto".
Incluso si tenemos en cuenta el hecho de que el desarrollador front-end puede estar en una posición en la que no puede influir de forma independiente en el backend y TTFB, es importante tener en cuenta el hecho de que los valores altos de TTFB pueden afectar significativamente el rendimiento del sitio. Como resultado, los esfuerzos de un desarrollador front-end que lucha por la velocidad del sitio web se parecerán a un juego de recuperación. Esto se aplica, por ejemplo, a la optimización de imágenes y a minimizar el volumen de materiales que conforman las secciones más importantes del proyecto, y a la descarga asincrónica de fuentes web. Esto no quiere decir que, sabiendo esto, puede renunciar y abandonar las optimizaciones de front-end. Pero si el TTFB es demasiado alto, entonces todas esas optimizaciones recuerdan tratar de solucionar un problema en condiciones en las que ya ha hecho daño y cuando es demasiado tarde para solucionarlo. De hecho, es por eso que es muy importante para aquellos que están desarrollando el front-end monitorear de cerca el indicador TTFB, y es muy importante, cuando sus valores son demasiado altos, tomar medidas para mejorarlo.
¿Qué es el TTFB?
TTFB no parece muy informativo ( imagen a tamaño completo )TTFB es un indicador que se ve, por decirlo suavemente, opaco. Tanto está influenciado por él que tengo la sensación de que estamos todo el tiempo simplemente ignorando su análisis serio. Muchos especulan que TTFB es solo el tiempo que le toma al servidor preparar una respuesta, pero de hecho, es solo una pequeña parte de lo que afecta a TTFB.
Lo primero que me gustaría llamar su atención es que al aprender lo que la gente suele sorprender. Estamos hablando del hecho de que TTFB incluye el tiempo que la solicitud del cliente pasa por la red al servidor y el tiempo que tarda la ruta de respuesta del servidor al cliente. Este es el llamado "tiempo de ida y vuelta" (Tiempo de ida y vuelta, RTT). TTFB no es solo un tiempo que el servidor dedica a preparar una respuesta. También es el tiempo que se dedica a la forma en que los datos van de cliente a servidor y de servidor a cliente (estos datos, por supuesto, contienen el "primer byte" que nos interesa).
Ahora, armados con este conocimiento, podemos entender fácilmente la razón por la cual cuando se visualizan sitios desde dispositivos móviles, el indicador TTFB a menudo es simplemente indecentemente grande. Es muy posible que antes, en tales situaciones, hubiera preguntado algo como esto: "Estoy seguro de que el servidor no sabe que estoy viendo el sitio desde un dispositivo móvil. ¿Cómo entonces aumenta TTFB? La razón de esto es que, por regla general, las conexiones de red móvil son conexiones de alta latencia. Si el indicador RTT, que refleja el tiempo requerido para que los datos viajen desde el teléfono al servidor y viceversa, es, por ejemplo, 250 ms, entonces TTFB aumentará en el valor correspondiente.
Si quisiera que los lectores de este material sacaran solo una idea importante de él, entonces formularía esta idea de la siguiente manera: "Los retrasos en la red afectan a TTFB".
¿Qué más afecta a TTFB? De hecho, mucho de todo. Aquí hay una lista lejos de ser completa de lo que contribuye a la formación de este indicador. Los elementos de esta lista están en orden aleatorio.
- Retrasos en la red. Como ya se mencionó, TTFB incluye el tiempo que lleva entregar una solicitud al servidor y devolver una respuesta del servidor. Tome, por ejemplo, el tiempo requerido para una sesión de intercambio de datos entre un dispositivo ubicado en Londres y un servidor ubicado en Nueva York. Idealmente, cuando se usa una conexión de fibra óptica, esto es 28 ms. Pero esto se basa en muchos supuestos muy optimistas. En realidad, debe esperar algo así como 75 ms . Por eso es tan importante usar CDN. Incluso ahora, en la era de Internet, la proximidad geográfica de un determinado negocio y sus clientes es una ventaja.
- Enrutamiento Si usa CDN (¡y debería ser así!), Entonces la solicitud de su cliente, por ejemplo, de Leeds, puede ser redirigida al centro de datos MAN solo para que resulte que el recurso que el cliente necesita no está en la caché de PoP correspondiente . Luego, la solicitud será redirigida al servidor real con sus materiales para transmitir al cliente lo que necesita. Si este servidor está ubicado, por ejemplo, en Virginia, entonces todo lo anterior conducirá a un aumento serio en TTFB sin razón aparente.
- Trabaja con archivos. Incluso si el servidor simplemente lee datos estáticos de su sistema de archivos, como imágenes o archivos de estilo, lleva algún tiempo completar esta operación. Esta vez también es parte de TTFB.
- Priorización El protocolo HTTP / 2 tiene mecanismos para priorizar el procesamiento de solicitudes. Como resultado, puede resultar que las solicitudes de baja prioridad se retrasen en el servidor, dando lugar a solicitudes de alta prioridad. Incluso si no tiene en cuenta los mecanismos de priorización de HTTP / 2 y asume que todo funciona sin problemas, estos retrasos esperados pueden contribuir a TTFB.
- Ejecutando aplicaciones. Esto, de hecho, es bastante obvio, pero me gustaría señalar que el tiempo requerido para ejecutar las aplicaciones del servidor afecta seriamente a TTFB.
- Consultas de bases de datos. Si necesita solicitar algo de la base de datos para formar la página, el tiempo para completar dicha operación también se incluirá en TTFB.
- Llamadas a la API Si se necesitan datos de ciertas API (internas o externas) para preparar la página, las llamadas a estas API afectarán a TTFB.
- Representación del servidor Es bastante obvio que la representación del lado del servidor lleva tiempo, esta vez es fácil de evaluar, pero esto no niega la contribución de esta operación a TTFB.
- Alojamiento barato Si usa un alojamiento barato, tratando de ahorrar tanto como sea posible y sacrificando el rendimiento, esto generalmente significa que varios otros proyectos usan el servidor en el que se encuentra su proyecto. Quizás una cantidad considerable. Como resultado, alguien que utiliza un alojamiento barato puede esperar una caída en el rendimiento del servidor, lo que puede afectar la capacidad del proyecto para procesar solicitudes. De hecho, estamos hablando del hecho de que la potencia del hardware del servidor no es suficiente para satisfacer las necesidades de la aplicación.
- Ataques DDoS, alta carga en el proyecto. Aquí continuamos el tema discutido en el párrafo anterior de esta lista. Es decir, si la carga en el servidor crece y el proyecto no proporciona un escalado flexible de las capacidades del servidor, esto lleva al hecho de que el equipo comienza a funcionar al límite. Y, como resultado, el rendimiento de la aplicación cae.
- WAF, equilibradores de carga. Los servicios, como WAF o equilibradores de carga ubicados frente a la aplicación del servidor, aumentan el TTFB.
- Algunas características de CDN. El uso de CDN es un factor que ciertamente tiene un efecto beneficioso en TTFB, pero algunas características de CDN pueden empeorarlo. Por ejemplo, esto es plegado de solicitud , ESI , etc.
- Retrasos en la "última milla". Cuando hablamos de una computadora de Londres que accede a un servidor ubicado en Nueva York, generalmente simplificamos demasiado la situación, casi reduciéndola al hecho de que la computadora y el servidor están directamente conectados entre sí. Pero en realidad, todo es mucho más complicado. La señal entre la computadora y el servidor pasa por muchos intermediarios. Nuestro enrutador lo envía al proveedor; desde una red inalámbrica, se mete en un cable tendido en el fondo del océano ... Los retrasos en la "última milla" incluyen todas las dificultades que se interponen en el camino de la transferencia de datos entre dispositivos finales.
Un TTFB de 0 ms es un sueño imposible. Por lo tanto, es importante tener en cuenta que no hay nada en la lista que siempre afecte negativamente a TTFB o que empeore este indicador. Esta lista se entiende mejor como una descripción de la estructura TTFB de un proyecto. Mi objetivo no es criticar ciertas tecnologías, sino mostrar cómo ciertas tecnologías pueden influir en TTFB. Y, para ser sincero, dada la cantidad de cosas que suceden antes de que el cliente reciba el primer byte de la respuesta del servidor, ya es sorprendente que los sitios se estén cargando en general.
Descubriendo el misterio con TTFB
Ahora, con suerte, TTFB ya no se ve tan misterioso. Y si dedica un poco de tiempo a la implementación de API
Server Timing , puede comenzar a medir los indicadores de tiempo del servidor y enviarlos a los sistemas del cliente. Esto permitirá a los desarrolladores web detectar y eliminar posibles cuellos de botella en el rendimiento que antes estaban ocultos a sus ojos.
La API de sincronización del servidor permite a los desarrolladores ampliar las respuestas de las consultas con el encabezado HTTP de
Server-Timing opcional. Contiene información de tiempo medida por la propia aplicación.
Fue este mecanismo el que utilizamos el año pasado cuando trabajamos en el iPlayer de la BBC.
Se puede agregar un nuevo encabezado de temporización del servidor a cualquier respuesta ( imagen a tamaño completo )
Tenga en cuenta que la sincronización del servidor también ejerce presión sobre el sistema. En el curso de su trabajo, debe medir los indicadores relevantes y completar el encabezado
Server-Timing . El navegador solo permite que el desarrollador front-end vea estos datos utilizando las herramientas apropiadas.
Ahora, directamente en el navegador, puede ver la estructura TTFB ( imagen a tamaño completo )Si desea implementar la API de sincronización del servidor, eche un vistazo a
este material .
Resumen
Es muy importante que los desarrolladores web comprendan en qué medida TTFB afecta lo que llaman "rendimiento del sitio". El tiempo para el primer byte es un cierto borde, después de cruzar, podemos hablar sobre la optimización del sitio web. Cuanto más bajo sea este indicador, mejor.
Estimados lectores! ¿Optimizas tus proyectos web con TTFB?
