Понимание состояния сетевого журнала Chrome

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

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

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

Выдержка из ресурса сети :

Стойловое / Blocking

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

(Если вы забыли, Chrome имеет ссылку «Объяснение» во всплывающей подсказке и под панелью «Время».)

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

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

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

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

---

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

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

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

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

• Queuing Если запрос поставлен в очередь, он указывает, что:
  • Запрос был отложен механизмом рендеринга, потому что он считается более низким приоритетом, чем критические ресурсы (такие как скрипты / стили). Это часто случается с изображениями.
  • Запрос был отложен для ожидания недоступного сокета TCP, который вот-вот освободится.
  • Запрос был отложен, потому что браузер допускает только шесть TCP-соединений на источник по HTTP 1. Время, затрачиваемое на создание записей в кэш-памяти диска (обычно очень быстрое).
• Время ожидания / блокировки Время ожидания запроса до его отправки. Может ожидаться любая из причин, описанных для очереди. Кроме того, это время включает любое время, потраченное на переговоры по доверенности.

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

Поскольку многие люди приезжают сюда для отладки своего медленного веб-сайта, я хотел бы сообщить вам о моем случае, который ни одно из объяснений Google не помогло разрешить. Мои огромные задержки (иногда 1 мин) были вызваны тем, что Apache, работающий в Windows, имел слишком мало рабочих потоков для обработки соединений, поэтому они находились в очереди.

Это может относиться к вам, если в вашем журнале apache есть следующее примечание:

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

Эта проблема решена в Apache httpd.conf. Раскомментировать: включите conf / extra / httpd-mpm.conf

И отредактируйте httpd-mpm.conf

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

Обратите внимание, что вам может не понадобиться 2000 потоков или может потребоваться больше. 2000 год был в порядке для моего случая.