Общие сведения о сетевом журнале сети Chrome "Stalled"

У меня есть следующий сетевой журнал в chrome:

Я ничего не понимаю в этом: какая разница между заполненными серыми полосками и прозрачными серыми полосками.

Ответ 1

Google дает разбивку этих полей в разделе Оценка производительности сети в их документации DevTools.

Выдержка из Время ресурсной сети:

стойловое/Блокировка

Время ожидания запроса, ожидающего до его отправки. Это время включает в себя любое время, проведенное в переговорах по доверенности. Кроме того, это время будет включать, когда браузер ожидает, что уже установленное соединение станет доступным для повторного использования, подчиняясь Chrome максимум шесть TCP-соединение за происхождения.

(Если вы забудете, у Chrome есть ссылка "Объяснение" в подсказке наведения и под панелью "Сроки".)

В принципе, основная причина, по которой вы это увидите, заключается в том, что Chrome будет одновременно загружать только 6 файлов на сервер, а другие запросы будут остановлены до тех пор, пока не будет доступно соединение.

Это не обязательно то, что требуется для исправления, но один из способов избежать застопоренного состояния - это распространять файлы через несколько доменных имен и/или серверов, сохраняя CORS, если это применимо к вашим потребностям, однако HTTP2, вероятно, является лучшим вариантом в будущем. Связывание ресурсов (например, конкатенация JS и CSS) также может помочь уменьшить количество остановленных соединений.

Ответ 2

DevTools: [сеть] объясняет пустой байт, предшествующий запросу

Дальнейшее исследование и установили, что нет существенной разницы между нашими диапазонами Stalled и Queuing. И то и другое вычисляются из дельта других временных меток, а не предоставляется из netstack или рендерера.

В настоящее время, если мы ожидаем, что сокет станет доступным:

мы будем называть это заторможенным, если произошло какое-то согласование прокси.

мы будем называть это очередностью, если не требуется работа прокси /ssl.

Ответ 3

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

Это происходит с официального сайта Chome-devtools, и это помогает. Здесь я цитирую:

QueuingЕсли запрос поставлен в очередь, он указывает, что:
Запрос был отложен механизмом рендеринга, поскольку он считал более низким приоритет, чем критические ресурсы (например, скрипты/стили). Это часто происходит с изображениями.

Запрос был удержан в ожидании недоступного сокета TCP, который собирается высвободить.

Запрос был приостановлен, потому что браузер разрешает только шесть TCP-соединений для каждого источника по HTTP 1. Время, затрачиваемое на создание записей в кэше диска (обычно очень быстро).

стойловое/БлокировкаВремя ожидания запроса, ожидающего до его отправки. Он может ждать любой из причин, описанных для Queuing. Кроме того, на этот раз включено любое время, проведенное в согласовании прокси.

Ответ 4

В моем случае страница отправляет несколько запросов с разными параметрами, когда они были открыты. Поэтому большинство из них "заглох". Следующие запросы сразу же отправляются "застопорились". Избежать ненужных запросов было бы лучше (быть ленивым...).