Tengo un siguiente registro de red en Chrome:
No entiendo nada: ¿cuál es la diferencia entre las barras grises rellenas y las barras grises transparentes?
Tengo un siguiente registro de red en Chrome:
No entiendo nada: ¿cuál es la diferencia entre las barras grises rellenas y las barras grises transparentes?
Respuestas:
Google da un desglose de estos campos en la evaluación del rendimiento de la red sección de su documentación de DevTools.
Atascado / Bloqueo
Tiempo que la solicitud pasó esperando antes de que pudiera enviarse. Este tiempo incluye todo el tiempo dedicado a la negociación de poder. Además, este tiempo incluirá cuando el navegador esté esperando que una conexión ya establecida esté disponible para su reutilización, obedeciendo las seis conexiones TCP máximas de Chrome por regla de origen.
(Si olvida, Chrome tiene un enlace "Explicación" en la información sobre herramientas al pasar el mouse y debajo del panel "Tiempo").
Básicamente, la razón principal por la que verá esto es porque Chrome solo descargará 6 archivos por servidor a la vez y otras solicitudes se detendrán hasta que esté disponible una ranura de conexión.
Esto no es necesariamente algo que deba corregirse, pero una forma de evitar el estado estancado sería distribuir los archivos a través de múltiples nombres de dominio y / o servidores, teniendo en cuenta CORS si corresponde a sus necesidades, sin embargo, HTTP2 es probablemente una mejor opción avanzando. La agrupación de recursos (como la concatenación JS y CSS) también puede ayudar a reducir la cantidad de conexiones estancadas.
file:///C:/...
DevTools: [red] explica las barras vacías antes de la solicitud
Investigé más y he identificado que no hay una diferencia significativa entre nuestros rangos Stalled y Queuing. Ambos se calculan a partir del delta de otras marcas de tiempo, en lugar de proporcionarse de netstack o renderizador.
Actualmente, si estamos esperando que un socket esté disponible:
- lo llamaremos estancado si se produce alguna negociación de poder
- lo llamaremos en cola si no se requiere trabajo proxy / ssl.
Esto viene del sitio oficial de Chome-devtools y ayuda. Aquí cito:
- En cola Si una solicitud está en cola, indica que:
- El motor de renderizado pospuso la solicitud porque se considera de menor prioridad que los recursos críticos (como scripts / estilos). Esto sucede a menudo con imágenes.
- La solicitud se puso en espera para esperar un socket TCP no disponible que está a punto de liberarse.
- La solicitud se puso en espera porque el navegador solo permite seis conexiones TCP por origen en HTTP 1. Tiempo dedicado a hacer entradas de caché de disco (generalmente muy rápido).
- Tiempo bloqueado / bloqueado La solicitud pasó esperando antes de que pudiera enviarse. Puede estar esperando cualquiera de los motivos descritos para hacer cola. Además, este tiempo incluye todo el tiempo dedicado a la negociación de poder.
Mi caso es que la página está enviando múltiples solicitudes con diferentes parámetros cuando estaba abierta. Así que la mayoría están "estancados". Las siguientes solicitudes enviadas inmediatamente se "estancan". Evitar solicitudes innecesarias sería mejor (ser perezoso ...).
Como muchas personas llegan aquí para depurar su sitio web lento, me gustaría informarle sobre mi caso, que ninguna de las explicaciones de Google ayudó a resolver. Mis enormes tiempos de inactividad (a veces 1 minuto) fueron causados por Apache que se ejecuta en Windows con muy pocos hilos de trabajo para manejar las conexiones, por lo tanto, estaban en cola.
Esto puede aplicarse a usted si su registro de Apache tiene la siguiente nota:
Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting
Este problema se resuelve en Apache httpd.conf. Descomentar: Incluir conf / extra / httpd-mpm.conf
Y edite httpd-mpm.conf
<IfModule mpm_winnt_module>
ThreadLimit 2000
ThreadsPerChild 2000
MaxConnectionsPerChild 0
</IfModule>
Tenga en cuenta que es posible que no necesite 2000 subprocesos o que necesite más. 2000 estuvo bien para mi caso.