| Россия, Сочи, РГПУ им. А.И.Герцена, 1997 |
Инспектор
Вы можете этот курс.
Опубликован: 16.02.2009 | Уровень: специалист | Доступ: платный
Лекция 8:
Приложение
Firebug NET Panel для Firefox
Другим, более популярным инструментом для анализа загрузки сайта в Firefox является Firebug (со встроенной NET Panel). Он отслеживает все пакеты, которые передает или запрашивает Firefox, позволяя тем самым построить вполне точную диаграмму загрузки страницы. Естественно, позволяет увидеть и все HTTP-заголовки (как запроса, так и ответа) для полученных файлов. К сожалению, на данный момент Firebug не учитывает время, затраченное на DNS-запросы, редиректы и отображение страницы.
Однако ситуация обещает исправиться, да еще и кардинальным образом: уже сейчас доступна альфа-версия Firebug 1.4a1, в которой для каждого загружаемого объекта страницы теперь выводится полная статистика затрачиваемого времени. Конечно, есть еще куда стремиться: можно добавить и общую диаграмму загрузки, и затраты времени на все компоненты вместе, а не по отдельности. Но и этот шаг будет весьма значительным.
На этой диаграмме теперь можно увидеть, когда же наша страница считается загруженной как частично, так и полностью (первая и третья стадии загрузки соответственно): две вертикальные линии синего и красного цвета показывают моменты событий DOMContentLoaded и самого load. Очевидно, что после события load могут происходить дополнительные загрузки компонентов, которые находятся в четвертой стадии, что, естественно, не всегда совпадает с фактической загрузкой и отображением компонентов страницы.
Но давайте рассмотрим загрузку страницы в текущей версии инструмента:
На диаграмме загрузки для webo.in хорошо отслеживается стадия предзагрузки (заканчивающаяся c получением файла c.css?20081010 ). На этой же стадии у пользователя оказываются загруженными 2 изображения (оба запрошены через new Image().src, одно из них — "на будущее). После того как страница появилась в браузере пользователя (на это ушло порядка 200 мс с момента запроса страницы), сработало событие готовности документа к дальнейшим действиям. По этому событию Firefox запросил 3 файла: d.css?20081010, g.js?20080920 и j.js?20080924.
g.js (являясь сжатым скриптом Google Analytics) отправил данные о посещении на сервер статистики с помощью файла __ utm.gif. Стоит заметить, что все вызовы внешних ресурсов из HTML-файла осуществлялись при использовании DOM-методов добавления элементов, и это позволило максимально их распараллелить. Далее Firefox (так как кэш был отключен) запросил файл b.png повторно (основываясь уже на данных из файла d.css, содержащего информацию о стилях для фона элементов). При наличии в кэше файл просто отобразился бы на странице, и запроса не произошло.
После получения всех файлов на странице сработало событие window.onload, по которому загрузился последний файл (скрытая таблица стилей, используемая на других страницах сайта). Для пользователя это произошло абсолютно прозрачно: страница уже была полностью готова к взаимодействию, не требовалось никакого дополнительного времени ожидания.
В данном случае размер страницы составляет порядка 100 Кб в сжатом виде и около 200 Кб в несжатом. Однако это не помешало ей загрузиться (если не брать в расчет некоторые файлы "на будущее" и отключенное кэширование) менее чем за 500 мс.
Yslow для Firebug для Firefox
В качестве полезного дополнения к Firebug (для Firefox) стоит рассмотреть и YSlow. На данный момент этот инструмент, пожалуй, является наиболее адекватным для анализа скорости загрузки страницы.
Все аспекты производительности разбиты на разделы. В случае невыполнения каких-либо советов дается ссылка на полный его вариант на английском языке. Естественно, что советы не идеальны, и в некоторых случаях допустимо не следовать им буквально. Однако при прочих равных условиях более высокая оценка (максимум 100) соответствует более оптимизированному сайту.
Web Inspector для Safari
Аналогично уже рассмотренной Firebug Net Panel, Web Inspector представляет диаграмму загрузки, основываясь на фактических данных. Однако есть и ряд недостатков: в частности, время отображения (выполнения) элемента не отделено от времени его загрузки, что хорошо видно для встроенных изображений.
HttpWatch
HttpWatch (http://www.httpwatch.com/) может быть установлен как для IE, так и для Firefox. На данный момент кроме самих HTTP-заголовков он предоставляет достаточно подробную диаграмму загрузки сайта, что является хорошим подспорьем при анализе производительности.
Полная версия продукта является платной.
Fiddler
Fiddler (http://www.fiddlertool.com/fiddler/) устанавливается как дополнение к IE и позволяет анализировать все загружаемые файлы (заголовки, размер, время загрузки из разных точек земного шара).
Live HTTP Headers
Live HTTP Headers (http://livehttpheaders.mozdev.org/) позволяет просматривать HTTP-заголовки для Firefox в режиме реального времени. Может выступать достаточно удобным дополнением в Firefox, если нужно отладить общение браузера с сервером в плане кэширования или сжатия (проверить соответствующие заголовки на "живом" соединении).
Прокси-эмулятор каналов Sloppy
После рассмотрения всех методов ускорения загрузки стоит заметить, что та или иная техника оптимизации направлена в первую очередь на пользователей с медленным каналом — именно они в наибольшей мере почувствуют выигрыш от наших кропотливых манипуляций с проектом. Но как же проверить это еще на этапе разработки — ведь в большинстве случаев тестовый сервер располагается на рабочем компьютере, да и интернет-канал у профессиональных веб-разработчиков тоже не самый плохой. Выход есть: эмулировать такие соединения, подключаясь через специальную программу, которая нарочно "затормозит" (но не Интернет, а только доступ к тестовому сайту) соединение, имитируя подключение пользователя, скажем, с ADSL-128 Kbps.
Для этого нам подойдет небольшая и очень простая программа Sloppy — прокси-сервер. Он эмулирует доступ к указанному сайту через канал с задаваемой полосой пропускания: от модемного 9,6 Кб/с до выделенного в 512 Кб/с. В том случае, если скорость подключения к интернету 1 Мб или больше, любой проект будет загружаться достаточно быстро, поэтому тестировать его специально не имеет смысла (только в общем порядке). А влияние издержек на установление множества дополнительных соединений можно установить при тестировании на менее мощных каналах.
Из доступных настроек у нас есть: адрес сайта, который будем тестировать, выбор скорости (из набора 9.6, 14.4, 28.8, 56, 128, 256 и 512 Кб), а также порт, по которому мы будем получать страницу. Благодаря "прокси-природе" его можно использовать для тестирования как локального проекта, так и любого внешнего проекта в сети. Конечно, в этом случае нужен доступ в Интернет, тогда как просто для теста локального сервера этого совсем не требуется (после загрузки самого приложения).
Sloppy интересен еще и тем, что распространяется как JNLP-файл, то есть использует Java Web Start для запуска; при этом сам код загружается с сайта проекта, впрочем, можно загрузить исходный код отдельно.
Analyze.WebSiteOptimization.com
Пожалуй, самый старый и наиболее известный онлайн-сервис для проверки клиентской оптимизации выбранного сайта. Выдает набор советов (аналогичных рекомендациям Yahoo). Поскольку анализ основан на собственном алгоритме, то не распознает data:URI и mhtml-изображения. Также не всегда верно трактует скрипты внутри страницы.
Octagate.com/service/SiteTimer/
С помощью данного инструмента можно построить диаграмму загрузки сайта. К плюсам можно отнести то, что дополнительно показан RSS-поток (при соответствующем объявлении). К несчастью, сервис не распознает data:URI и mhtml -изображения; также построение самой диаграммы загрузки оставляет желать лучшего.
Tools.Pingdom.com
Сервис позиционирует себя как инструмент для построения диаграммы загрузки, однако на данный момент не распознает сжатия файлов и выделения фоновых картинок.
