Comprendre l’état du journal du réseau Chrome

Google fournit une ventilation de ces champs dans la section Evaluation des performances réseau de leur documentation DevTools.

Extrait du timing du réseau de ressources :

Calé / bloquant

Heure à laquelle la demande a été attendue avant de pouvoir être envoyée. Ce temps comprend tout le temps passé dans la négociation de procuration. De plus, cette fois, le navigateur attend qu’une connexion déjà établie soit disponible pour être réutilisée, conformément à la règle de connexion maximale de six TCP par connexion établie par Chrome.

(Si vous oubliez, Chrome dispose d’un lien “Explication” dans l’info-bulle et sous le panneau “Timing”.)

En gros, la raison principale pour laquelle vous verrez cela est que Chrome ne téléchargera que 6 fichiers par serveur à la fois et que les autres requêtes 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 une façon d’éviter l’état bloqué serait de dissortingbuer les fichiers sur plusieurs noms de domaine et / ou serveurs, en gardant CORS à l’esprit si applicable à vos besoins, cependant 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 la quantité de connexions bloquées.

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

A enquêté plus loin et identifié qu’il n’y a pas de différence significative entre nos gammes Stalled et Queuing. Les deux sont calculés à partir du delta des autres horodatages, plutôt qu’à partir de netstack ou du moteur de rendu.

---

Actuellement, si nous attendons qu’une socket soit disponible:

• nous l’appellerons bloqué si une négociation par procuration a eu lieu
• nous l’appellerons en attente si aucun travail proxy / ssl n’était requirejs.

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

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

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

Mon cas est que la page envoie plusieurs demandes avec des parameters différents quand il était ouvert. Donc, la plupart sont “bloqués”. Les demandes suivantes envoyées immédiatement sont “bloquées”. Éviter les demandes inutiles serait mieux (être paresseux …).