У меня есть следующий сетевой журнал в chrome:
Я ничего не понимаю в этом: какая разница между заполненными серыми полосками и прозрачными серыми полосками.
У меня есть следующий сетевой журнал в chrome:
Я ничего не понимаю в этом: какая разница между заполненными серыми полосками и прозрачными серыми полосками.
Google дает разбивку этих полей в разделе Оценка производительности сети в их документации DevTools.
стойловое/Блокировка
Время ожидания запроса, ожидающего до его отправки. Это время включает в себя любое время, проведенное в переговорах по доверенности. Кроме того, это время будет включать, когда браузер ожидает, что уже установленное соединение станет доступным для повторного использования, подчиняясь Chrome максимум шесть TCP-соединение за происхождения.
(Если вы забудете, у Chrome есть ссылка "Объяснение" в подсказке наведения и под панелью "Сроки".)
В принципе, основная причина, по которой вы это увидите, заключается в том, что Chrome будет одновременно загружать только 6 файлов на сервер, а другие запросы будут остановлены до тех пор, пока не будет доступно соединение.
Это не обязательно то, что требуется для исправления, но один из способов избежать застопоренного состояния - это распространять файлы через несколько доменных имен и/или серверов, сохраняя CORS, если это применимо к вашим потребностям, однако HTTP2, вероятно, является лучшим вариантом в будущем. Связывание ресурсов (например, конкатенация JS и CSS) также может помочь уменьшить количество остановленных соединений.
DevTools: [сеть] объясняет пустой байт, предшествующий запросу
Дальнейшее исследование и установили, что нет существенной разницы между нашими диапазонами Stalled и Queuing. И то и другое вычисляются из дельта других временных меток, а не предоставляется из netstack или рендерера.
В настоящее время, если мы ожидаем, что сокет станет доступным:
- мы будем называть это заторможенным, если произошло какое-то согласование прокси.
- мы будем называть это очередностью, если не требуется работа прокси /ssl.
Это происходит с официального сайта Chome-devtools, и это помогает. Здесь я цитирую:
- QueuingЕсли запрос поставлен в очередь, он указывает, что:
- Запрос был отложен механизмом рендеринга, поскольку он считал более низким приоритет, чем критические ресурсы (например, скрипты/стили). Это часто происходит с изображениями.
- Запрос был удержан в ожидании недоступного сокета TCP, который собирается высвободить.
- Запрос был приостановлен, потому что браузер разрешает только шесть TCP-соединений для каждого источника по HTTP 1. Время, затрачиваемое на создание записей в кэше диска (обычно очень быстро).
- стойловое/БлокировкаВремя ожидания запроса, ожидающего до его отправки. Он может ждать любой из причин, описанных для Queuing. Кроме того, на этот раз включено любое время, проведенное в согласовании прокси.
В моем случае страница отправляет несколько запросов с разными параметрами, когда они были открыты. Поэтому большинство из них "заглох". Следующие запросы сразу же отправляются "застопорились". Избежать ненужных запросов было бы лучше (быть ленивым...).