javascript - attribute - title html
Cómo reducir el tiempo de espera del servidor? (5)
El tiempo de espera, también conocido como tiempo hasta el primer byte, es el tiempo que tarda el servidor en enviar el primer byte desde que se inicia la conexión. Si esto es alto, significa que su servidor tiene que trabajar mucho para renderizar la página antes de enviarla. Necesitamos más información sobre lo que su sitio está haciendo para representar la página.
Estoy tratando de optimizar la velocidad de mi sitio y estoy usando la gran herramienta en pingdom.com . En este momento, más del 50% del tiempo que lleva cargar la página es el tiempo de "Espera", como se muestra en la siguiente captura de pantalla. ¿Qué puedo hacer para reducir esto? Además, ¿qué tan típica es esta figura? ¿Hay puntos de referencia sobre esto? ¡Gracias!
EDITAR: Ok ... déjame aclarar algunas cosas. No hay scripts del lado del servidor ni llamadas de bases de datos en curso. Solo HTML, CSS, JS e imágenes. Ya he hecho algunas cosas, como push js al final de la etiqueta de cuerpo para obtener descargas paralelas. Soy consciente de que main.html y templates.html se están agregando al tiempo de espera general al realizarse de forma sincronizada después de las descargas de js.js, ese no es el problema. Me sorprende la cantidad de tiempo de "espera" que hay para cada pedido. ¿La distancia del servidor afecta esto? ¿Qué hay de estar en un servidor compartido, eso afecta el tiempo de espera? ¿Hay alguna fruta madura para remediar esos problemas?
Este es un problema con el servidor ... Según Pingdom, "El navegador web está esperando los datos del servidor" es lo que define el tiempo de "Espera".
No hay mucho que puedas hacer desde un código javascript o código fuente para arreglarlo.
La razón más común para esto en el caso de Apache es el uso de DNS Reversal Lookup. Lo que esto significa es que el servidor intenta averiguar cuál es el nombre de su máquina, cada vez que realiza una solicitud. Esto puede llevar varios segundos, y eso explica por qué tiene un tiempo de ESPERA prolongado y luego una carga muy rápida, porque no se trata del ancho de banda.
La solución obvia para esto es deshabilitar hostnamelookup en /etc/httpd/conf/httpd.conf
HostnameLookups Off
Sin embargo ... esto generalmente NO es suficiente. El hecho es que, en muchos casos, apache aún realiza una búsqueda de reversión incluso cuando ha deshabilitado la búsqueda del nombre de host, por lo que debe examinar cuidadosamente cada línea de su configuración de apache. En particular, una de las razones más comunes para esto es LOGS. De forma predeterminada, en muchas instalaciones de red hat-centos, el formato de registro incluye% h, que significa "nombre de host", y requiere que apache realice una búsqueda inversa. Puedes ver esto aquí:
LogFormat "%h %l %u %t /"%r/" %>s %b /"%{Referer}i/" /"%{User-Agent}i/"" combined
LogFormat "%h %l %u %t /"%r/" %>s %b" common
Debe cambiar esos% h por% a para resolver este problema.
Si tiene varias solicitudes de servidor que la página está esperando, puede asegurarse de que esas solicitudes de servidor se envíen de forma asíncrona en paralelo para que las serialice.
La forma más lenta de obtener varias solicitudes es enviar una solicitud, esperar su respuesta, enviar la siguiente solicitud, esperar su respuesta, etc. ... Por lo general, es mucho más rápido enviar todas las solicitudes de forma asíncrona y luego procesar todas las respuestas a medida que llegan . Esto acorta el tiempo total de espera al tiempo de espera más largo para cualquier solicitud individual en lugar del tiempo de espera acumulativo de todas las solicitudes.
Si solo hace una sola solicitud, todo lo que puede hacer desde el lado del cliente es asegurarse de que la solicitud se envíe al servidor lo antes posible en la secuencia de carga de la página para que otras partes de la página puedan hacer sus negocios mientras se procesa la solicitud, lo que hace que la solicitud inicial se inicie antes (y, por lo tanto, finalice antes).
TTFB está directamente influenciado por la distancia "física" entre el navegador y el servidor. El proxy CDN es la mejor manera de acortar dicha distancia. Esto, junto con las capacidades nativas de almacenamiento en caché, ayudará a proporcionar una respuesta más rápida al cargar objetos en caché desde la ubicación POP (punto de ubicación) más cercana.
El efecto dependerá de la ubicación geográfica del usuario y la propagación de CDN. Aún así, puede esperar mejoras significativas , 50% -70% o más.
Hablando de la experiencia, vi casos en los que el 90% del contenido se almacenaba en caché y se enviaba directamente desde un proxy ubicado en un continente diferente, del otro lado del mundo.