Cómo reducir el tiempo de espera del servidor?

Question

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!

EDIT: Ok .. quiero 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?

Answer 1

Este es un problema con el servidor ... De acuerdo con Pingdom, "El navegador web está a la espera de datos del servidor" es lo que define el tiempo de "espera".

No hay mucho que pueda hacer desde un javascript o un código para solucionarlo.

Answer 2

El tiempo de espera, también conocido como time to first 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.

Answer 3

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 manera más lenta de obtener varias solicitudes es enviar una solicitud, esperar su respuesta, enviar la siguiente solicitud, esperar su respuesta, etc. ... Generalmente es mucho más rápido enviar todas las solicitudes de forma asincrónica y luego procesar todo 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 puede estar haciendo sus negocios mientras se procesa la solicitud, lo que hace que la solicitud inicial se inicie antes (y, por lo tanto, finalice antes).

Answer 4

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 desactivar hostnamelookup en /etc/httpd/conf/httpd.conf

HostnameLookups Off 

Sin embargo ... esto no suele ser 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. Puede 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.

Answer 5

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 extensión de CDN. Aún así, puede esperar significant improvement, 50% -70% o más.

Hablando por experiencia, vi casos en los que el 90% del contenido se almacenaba en caché y se enviaba directamente desde un servidor proxy ubicado en un continente diferente, del otro lado del mundo.