Эта лаборатория кода проведет вас через процесс интерпретации всего сетевого трафика для довольно сложного примера приложения. В конце упражнения вы приобретете навыки, необходимые для определения того, что загружает ваше собственное веб-приложение и когда оно отправляет каждый запрос.
Перейдите на панель сети.
Перейдите на панель «Сеть», чтобы увидеть сетевой трафик для демонстрационного приложения.
Чтобы просмотреть сайт, нажмите «Просмотреть приложение» . Затем нажмите Полноэкранный режим
.Нажмите «Control+Shift+J» (или «Command+Option+J» на Mac), чтобы открыть DevTools.
Откройте вкладку «Сеть» .
Перезагрузите страницу, чтобы увидеть сетевой трафик.
На панели «Сеть» отображаются все ресурсы, загруженные в результате первоначальной навигации:
Как интерпретировать записи
Каждая строка записанного сетевого трафика представляет собой одну пару запроса и ответа.
Первая строка с типом document — это начальный запрос навигации по HTML-коду веб-приложения. Это источник водопада; каждый из последующих запросов на дополнительные ресурсы (известные как подресурсы основного документа) исходит из этого исходного источника.
Вторая и третья строки, показывающие загружаемую stylesheet CSS и подресурс script , представляют собой зависимые запросы, инициированные основным документом.
Если посмотреть на то, когда делаются эти запросы, водопадная диаграмма показывает, что они не запускаются до самого конца процесса ответа на навигационный запрос.
В совокупности запросы к HTML-документу, CSS и JavaScript необходимы для отображения полной страницы во время первоначальной навигации.
Создайте несколько дополнительных запросов времени выполнения.
Поскольку панель «Сеть» все еще открыта и ведет запись, пришло время смоделировать что-то общее для многих веб-приложений: дополнительные запросы API, используемые для добавления дополнительных данных на страницу после завершения первоначальной навигации.
Запустите эти дополнительные запросы, нажав «Найти меня» в приложении, а затем «Разрешить» в появившемся всплывающем окне. Это позволит сайту получить доступ к вашему текущему местоположению:
Как только у веб-приложения появится местоположение для работы, нажатие кнопки «Найти ближайшие записи Википедии» приведет к нескольким дополнительным сетевым запросам. Вы должны увидеть что-то вроде этого:
Интерпретируйте новые записи
Как и раньше, каждая строка записанного сетевого трафика представляет собой одну пару запроса и ответа.
Первая строка новых записей представляет собой запрос с типом fetch , который соответствует тому , как веб-приложение запрашивает данные из API Wikipedia.
Следующие строки представляют собой изображения ( png или jpeg ), связанные с записями в Википедии. Хотя на скриншоте это немного сложно увидеть, их записи в столбце «Водопад» напрямую вытекают из ответа API.
Для всех этих дополнительных запросов время будет зависеть от того, как долго у вас была открыта страница, прежде чем вы нажмете «Найти ближайшие записи Википедии» . Самое важное здесь то, что параметр When отключен от первоначального запроса навигации. Об этом можно судить по большому промежутку, существующему на дисплее «Водопад», представляющему собой период времени, прошедший между первоначальной загрузкой и выполнением запроса API Wikipedia.
Запросы, сделанные после промежутка времени после навигации, попадают в категорию «запросов времени выполнения», в отличие от исходного набора запросов, используемых для отображения страницы при первом переходе на нее.
Подведение итогов
Выполнив шаги, описанные в этой лаборатории кода, вы теперь знакомы с инструментами, которые можно использовать для анализа того, что загружает любое веб-приложение.
Панель «Сеть» помогает вам ответить на вопрос о том, что загружается, с помощью URL-адресов в столбце «Имя» и данных в столбце «Тип», а также времени загрузки с помощью водопадного отображения.
Вы также видели, что запросы, сделанные веб-страницей, можно (обычно) сгруппировать в одну из двух категорий:
- Первоначальные запросы HTML, JavaScript, CSS (и, возможно, других ресурсов), сделанные сразу после перехода на новую страницу.
- Запросы времени выполнения, сделанные в результате взаимодействия пользователя со страницей. Часто это может начаться с запроса к API, а затем перейти к нескольким последующим запросам на основе полученных данных API.