Comprendre l'état "bloqué" du journal du réseau Chrome

J'ai un journal réseau suivant dans Chrome:

Je n'y comprends rien: quelle est la différence entre les barres grises remplies et les barres grises transparentes.

Google donne une ventilation de ces champs dans la section Évaluation des performances du réseau de leur documentation DevTools.

Extrait de la synchronisation du réseau de ressources :

Bloqué / Blocage

Temps d'attente de la demande avant de pouvoir être envoyé. Ce temps comprend tout temps passé dans la négociation de proxy. De plus, cette durée inclura le moment où le navigateur attend qu'une connexion déjà établie devienne disponible pour une réutilisation, en respectant le maximum de six connexions TCP de Chrome par règle d'origine.

(Si vous oubliez, Chrome a un lien "Explication" dans l'info-bulle de survol et sous le panneau "Minutage".)

Fondamentalement, la principale raison pour laquelle vous verrez cela est que Chrome ne téléchargera que 6 fichiers par serveur à la fois et que les autres demandes seront bloquées jusqu'à ce qu'un emplacement de connexion devienne disponible.

Ce n'est pas nécessairement quelque chose qui doit être corrigé, mais un moyen d'éviter l'état bloqué serait de distribuer les fichiers sur plusieurs noms de domaine et / ou serveurs, en gardant à l'esprit CORS s'il est applicable à vos besoins, mais HTTP2 est probablement une meilleure option aller de l'avant. Le regroupement de ressources (comme la concaténation JS et CSS) peut également aider à réduire le nombre de connexions bloquées.

DevTools: [réseau] explique les barres vides précédant la requête

Enquêtes plus poussées et ont identifié qu'il n'y a pas de différence significative entre nos plages bloquées et en file d'attente. Les deux sont calculés à partir des delta des autres horodatages, plutôt que fournis par netstack ou renderer.

---

Actuellement, si nous attendons qu'une socket devienne disponible:

• nous l'appellerons bloqué si une négociation proxy a eu lieu
• nous l'appellerons mise en file d'attente si aucun travail proxy / ssl n'était requis.

https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing

Cela vient du site officiel de Chome-devtools et cela aide. Ici je cite:

• Mise en file d'attente Si une demande est mise en file d'attente, cela indique que:
  • La demande a été reportée par le moteur de rendu car elle est considérée comme moins prioritaire que les ressources critiques (telles que les scripts / styles). Cela arrive souvent avec les images.
  • La demande a été mise en attente pour attendre un socket TCP indisponible qui est sur le point de se libérer.
  • La demande a été mise en attente car le navigateur n'autorise que six connexions TCP par origine sur HTTP 1. Temps passé à faire des entrées de cache disque (généralement très rapide).
• Stalled / Blocking Temps passé par la demande avant de pouvoir être envoyée. Il peut attendre l'une des raisons décrites pour la file d'attente. De plus, ce temps comprend tout temps passé dans la négociation de proxy.

Mon cas est que la page envoie plusieurs demandes avec des paramètres différents lorsqu'elle était ouverte. La plupart sont donc «bloqués». Les demandes suivantes immédiatement envoyées sont "bloquées". Il vaudrait mieux éviter les demandes inutiles (être paresseux ...).

Étant donné que de nombreuses personnes arrivent ici pour déboguer leur site Web lent, je voudrais vous informer de mon cas qu'aucune des explications de Google n'a aidé à résoudre. Mes énormes temps de blocage (parfois 1 min) ont été causés par Apache fonctionnant sous Windows ayant trop peu de threads de travail pour gérer les connexions, par conséquent, ils étaient en file d'attente.

Cela peut s'appliquer à vous si votre journal apache contient la note suivante:

Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Ce problème est résolu dans Apache httpd.conf. Décommenter: inclure conf / extra / httpd-mpm.conf

Et éditez httpd-mpm.conf

<IfModule mpm_winnt_module>
   ThreadLimit              2000
   ThreadsPerChild          2000
   MaxConnectionsPerChild   0
</IfModule>

Notez que vous n'aurez peut-être pas besoin de 2000 threads ou plus. 2000 était OK pour mon cas.