Мои предыдущие две статьи были посвящены инструментам отладки, так что я уместно продолжить эту тему. При отладке интерфейсного кода вы, как правило, тратите много времени на анализ того, как CSS и JavaScript влияют на отображение вашей страницы; Не менее важно то, как сетевые запросы влияют на ваш сайт. Во многих случаях мы работаем локально и забываем, что размер страницы, задержка, загрузка и блокировка скриптов могут сильно повлиять на восприятие вашего сайта пользователем. Поэтому наличие хорошего набора инструментов для проверки сетевого трафика жизненно важно для завершения вашего набора инструментов отладки.
К счастью, все основные современные браузеры предоставляют инструменты отладки, которые позволяют вам проверять сетевой трафик, а сторонние инструменты, такие как Fiddler и Charles, не только позволяют вам видеть сетевые запросы, но и предлагают расширенные возможности для взаимодействия с вашим сайтом.
Мы рассмотрим оба типа инструментов.
Анализ трафика на основе браузера
Как я уже упоминал, каждый крупный браузер имеет встроенные средства отладки. Это включает:
- Инструменты разработчика Internet Explorer F12
- Инструменты веб-разработчика Firefox и дополнение Firebug
- Инструменты разработчика Chrome
- Стрекоза оперы
- Веб-инспектор Safari
Каждый набор имеет свои уникальные возможности, но у каждого есть возможность собирать сетевой трафик. Если мы посмотрим на следующие изображения, вы увидите, что, хотя пользовательские интерфейсы могут различаться, собранные и отображаемые данные очень похожи:
Конечным результатом является список сетевых запросов браузера, связанных с загрузкой ресурсов или данных наших страниц. Сетевой инструмент может перехватить эти запросы, чтобы показать вам важные данные, такие как:
Fiddler примет запрос вашего URI и заменит его локальным файлом.
- Тип запроса (GET, POST и т. Д.)
- Что запрашивается
- URI
- Статус
- Размер
- Сколько времени ушло на выполнение запроса
Поэтому, если мы посмотрим на результаты Firebug, мы увидим, что запрос отозвал главную страницу и связанные с ней файлы CSS и JavaScript, включая ресурсы из Amazon AWS. Из-за ограничений изображения я не могу показать вам все, что он загрузил, но были также возвращены изображения и файлы SWF Flash.
Копать глубже
Имея эту информацию, я могу теперь перейти к конкретным запросам, чтобы определить, правильно ли я получаю данные или почему у меня может быть длительный запрос. Предположим, я смотрю на запрос файла JavaScript Webtrend. Загрузка заняла 1,2 секунды, и я хочу посмотреть, как обрабатывается запрос. Я могу расширить запрос и определить, был ли он разархивирован (это так):
и если это было уменьшено:
В этом случае файл не был уменьшен, и я могу связаться с разработчиком, чтобы определить, имеет ли смысл это делать. Конечно, это файл 2K, но каждый байт имеет значение, и эта информация позволяет мне лучше оптимизировать мой сайт.
Время сети
Сетевая задержка может быть убийственной, особенно для одностраничных приложений, которые зависят от внешних API или нескольких файлов сценариев. Большинство браузеров пытаются асинхронно загружать ресурсы, когда они могут, но некоторые, такие как файлы JavaScript, могут вызывать события блокировки. Важно иметь возможность закрепить их, чтобы максимально оптимизировать загрузку ресурсов. Если мы посмотрим на это изображение, вы увидите, что загрузка файла заняла 1,4 секунды:
При наведении на временные шкалы мы получаем диалог, который дает нам представление о том, как продвигался запрос:
Частично это произошло потому, что он был заблокирован от загрузки на 760 мс. Если это оказалось распространенной проблемой, вы можете использовать загрузчик скриптов, такой как RequireJS, чтобы лучше управлять загрузкой скриптов и зависимостями.
Ajax Requests
Поскольку динамические приложения настолько распространены, жизненно важно иметь возможность проверять вызовы XHR. Ранее вы видели тонну сетевых запросов и пытались отфильтровать их все, чтобы обнаружить, что ваши вызовы XHR неэффективны. Из-за этого большинство инструментов позволяют вам выбирать, какие типы запросов вы хотите отображать. Здесь я фильтрую запросы XHR, чтобы я мог оценить запрос и ответ:
Детализируя запрос, я могу оценить важные детали запроса, такие как заголовки и статус, метод запроса, файлы cookie и, что наиболее важно, ответ, который был возвращен:
В этом случае был возвращен HTML, но ответом может быть что угодно, включая текст, JSON или XML. Самое замечательное в том, что я могу полностью это проверить на случай, если у меня возникнут какие-либо проблемы.
Печенье
Файлы cookie невероятно полезны, и, поскольку мы широко их используем, простой способ проверки их ценностей облегчает жизнь. Инструменты разработчика позволяют легко сделать это, показывая вам, какие куки были отправлены и получены:
Если вы когда-либо занимались разработкой на стороне сервера без инструментов на стороне клиента, вы поймете, почему это так здорово.
В целом, отличительной чертой этого является то, что эта возможность находится прямо в вашем браузере, что делает ее невероятно удобной для запуска отладчика и проверки. Иногда, однако, вам нужно немного больше лошадиных сил.
Сторонние HTTP прокси инструменты
Приложения HTTP-прокси, такие как Fiddler и Charles Web Debugging Proxy, являются главными братьями анализаторов сетевого трафика на основе браузера. Они могут перехватывать не только сетевые запросы от браузера, но и другие приложения на вашем компьютере, что делает их гораздо более универсальными для отладки. Они также имеют тенденцию предлагать более богатые функции, такие как:
- Полоса с дросселированием
- Автоответчики на конкретные запросы
- Замена активов на лету (например, файл JavaScript)
- SSL-прокси
- Плагин экосистемы
- Настраиваемые скрипты
- Запись и воспроизведение сценариев тестирования
Я широко использую Fiddler на основе Windows, невероятно многофункциональный (это бесплатно!). Он также интенсивно используется внутри Microsoft из-за его мощного набора функций. Эрик Лоуренс, разработчик Fiddler, ранее работал в Microsoft и до сих пор поддерживает приложение.
Если мы посмотрим на пользовательский интерфейс, вы увидите сходство в выводе с тем, что мы видели в инструментах браузера. Все сетевые запросы отображаются вместе с ключевой информацией о запросах.
И, детализировав запрос, я смог увидеть подробные сведения об этом, включая минимизированный источник библиотеки jQuery:
Большая часть этой информации может быть извлечена с помощью инструментов на основе браузера, но что произойдет, если вы захотите узнать, взрывается ли конкретная библиотека на вашем сайте? Вы можете определенно поменять библиотеки и устранить неполадки. Лучшим способом было бы создать автоответчик Fiddler, который перехватывает ваш запрос и заменяет производственную библиотеку на ваш выбор. Подумайте об этом на секунду. Fiddler примет запрос вашего URI и заменит его локальным файлом. Давайте проверим это.
Во-первых, мне нужно определить URI, который я хочу заменить. В этом случае я вижу, что тема моего блога работает под управлением jQuery v1.2.6. Это безумие, но прежде чем я добавлю его и нанесу ущерб моему сайту, я бы хотел посмотреть, работает ли jQuery v1.8.3, как ожидалось.
Я нажимаю на запись для jQuery v1.2.6. В правом столбце Fiddler я выбираю вкладку «Автоответчик» и отмечаю «Включить автоматические ответы». Отключить респондента так же просто, как перетащить URI в редактор правил. Вы заметите, что он запускает правило, сравнивая URI. Если он совпадает, он ответит событием по вашему выбору.
Поскольку я хочу протестировать jQuery 1.8.3, я хочу, чтобы правило меняло производственную версию с локальной копией jQuery, которая есть на моем компьютере.
Я сохраняю правило и перезагружаю свою страницу. Конечный результат заключается в том, что хотя URI может выглядеть одинаково, проверка результатов проверяет, что jQuery v1.8.3 фактически был введен, что позволяет мне проверить это на лету, не внося никаких изменений в сайт:
С точки зрения отладки, я не могу не подчеркнуть, насколько это полезно, особенно когда вы пытаетесь зафиксировать ошибку в старых версиях фреймворка или библиотеки.
Мой хороший друг Джонатан Сэмпсон сделал отличный скринкаст об использовании этой функции.
Экосистема дополнений
Сетевая задержка может быть убийственной, особенно для одностраничных приложений.
Fiddler извлекает выгоду из обширной дополнительной экосистемы, которая расширяет ее функциональность через интерфейс iFiddlerExtension . Существуют дополнения, которые позволяют:
- Стресс-тестирование
- Аудит безопасности
- Распределение трафика для сравнения двух профилей трафика
- Форматирование JavaScript
Сам по себе Fiddler имеет множество функций — их слишком много, чтобы описать в этом посте. Вот почему есть книга на 330 страниц о том, как в полной мере воспользоваться ею. Это всего $ 10 и поможет вам изучить все преимущества этого замечательного инструмента.
OSX и Linux
Если вы используете OSX или Linux, лучшим вариантом является прокси-сервер отладки Charles. Это отличное и хорошо поддерживаемое приложение, и хотя оно коммерческое, оно стоит каждого копейки. Я искал хорошие альтернативы, которые сосредоточены на веб-разработке, и Чарльз действительно выделялся.
Интерфейс похож на Fiddler, но он предлагает два разных взгляда на сетевой трафик:
Стиль полностью зависит от вас. Я склонен склоняться к структурированному представлению, потому что оно кажется немного более организованным, но немного больше работы, чтобы выяснить, где находится конкретный URI.
Как и Фиддлер, Чарльз также предлагает возможность автоответчика. Он называется «Map Local …», и вы можете получить к нему щелчок правой кнопкой мыши по определенному URI. Это позволяет вам выбрать локальный файл для работы.
Когда я перезагружу страницу, я теперь заменю jQuery v1.2.6 на локальную копию jQuery v1.9, которая была на моем компьютере.
Еще одна замечательная особенность Чарльза — возможность регулировать запросы вашей сети для имитации определенной скорости полосы пропускания. Я помню времена модемов 56k и их ярких скоростей, поэтому их использование возвращает приятные воспоминания (гм, верно):
Чарльз также может работать на Windows, поскольку он предлагает полный кроссплатформенный пользовательский интерфейс.
Какой инструмент использовать
Я использую все эти инструменты все время, потому что я тестирую на всех основных браузерах. Наличие этой возможности действительно облегчает поиск неисправностей. Естественно, выбор между использованием сниффера на основе браузера или прокси-сервера с жестким ядром приложения полностью зависит от ваших потребностей в отладке.
Если вам просто нужно проверить трафик и проверить результаты, браузерный анализатор, скорее всего, вам идеально подойдет.
С другой стороны, если вам нужен детальный контроль над тем, как реагируют URI, или вам нужна гибкость при создании пользовательских тестовых сценариев, то вам нужно использовать такой инструмент, как Fiddler или Charles. Самое замечательное в том, что у нас есть солидный выбор, чтобы помочь нам в этом, особенно с ростом сложности наших проектов.