Статьи

Перевод: Николай Мациевский aka sunnybear
Опубликована: 27 февраля 2008

Скорость загрузки JavaScript-библиотек

Примечание: ниже перевод заметки John Resig (автора jQuery) "JavaScript Library Loading Speed", в которой он рассматривает, как сжатие, обфускация и архивирование влияет на производительность наиболее распространенных на данный момент JavaScript-библиотек. Мои комментарии даны курсивом.

Опубликована: 5 февраля 2008

Введение

Недавно командой PBWiki был проведен весьма впечатляющий анализ производительности JavaScript. Они собирались разобраться, насколько быстро грузятся JavaScript-библиотеки (конечно, их скорость загрузки будет заметно влиять на скорость загрузки всей страницы). Они развернули тестовое окружение для получения информации от различных браузеров, затем собрали все результаты в итоговом отчете. В нем достаточно много информации, которая может быть полезна как разработчикам веб-приложений, так и браузеров: структурированная таким образом информация достаточно обширна.

Методы упаковки JavaScript

При загрузке JavaScript-кода обычно предполагается, что чем меньше загружаемый файл, тем быстрее он загрузится. Что это несколько далеко от истины, прекрасно подтверждает дальнейшее исследование. Рассматривается скорость загрузки библиотеки jQuery в трех формах: обычной, уменьшенной (при помощи Yahoo Compressor) и упакованной (используется Packer). Если упорядочить их по размерам, то будет примерно так: самый маленький вариант, естественно, упакованный, затем уменьшенный, затем нормальный. Однако, упакованная версия добавляет некоторые накладные расходы: ее нужно сначала распаковать (выполнять достаточно тяжелый eval и replace) с помощью того же JavaScript на стороне клиента. Эта распаковка может занять достаточно продолжительное время при загрузке страницы. Это означает, что использование уменьшенной версии, в конце концов, будет значительно быстрее, чем упакованной — даже при достаточно большом размере файла.

Сравнение упаковки JavaScript (при загрузке jQuery, все варианты)

ВариантСреднее времяЧисло примеров
Уменьшенный519.721412611
Упакованный591.663612606
Нормальный645.481812589

В следующий раз при использовании любой техники сжатия помните о такой формуле:

Время_загрузки = Время_на_скачивание + Время_на_исполнение

Производительность JavaScript-библиотек

Из этого исследования можно еще получить данные по влиянию производительности различных JavaScript-библиотек на загрузку страницы. Таким образом, более простая и меньшая по размеру библиотека будет загружаться быстрее аналогов. По результатам видно, что jQuery загружается достаточно быстро относительно других библиотек (200–400мс — существенный выигрыш в скорости).

Среднее время загрузки инструментария (не кешированная, не архивированная, не уменьшенная версия)

ИнструментарийСреднее времяЧисло примеров
jquery-1.2.1732.19353152
dojo-1.0.1911.32553143
prototype-1.6.0923.70743144
yahoo-utilities-2.4.0927.46043141
protoculous-1.0.21136.54973136

Сейчас, возможно, вы возразите, что нечестно тестировать загрузку только некешировнных страниц, ибо, согласно исследованиям Yahoo по кешированию, всего примерно 50% посетителей не будут иметь возможности кешировать содержание страницы. Поэтому также важно убедиться, что не только первоначальная, но и кешированная версия страницы также загружается максимально быстро.

Среднее время загрузки инструментария (кешированная, архивированная и уменьшенная версия)

ИнструментарийСреднее времяЧисло примеров
yahoo-utilities-2.4.0122.78673042
jquery-1.2.1131.18413161
prototype-1.6.0142.73323040
dojo-1.0.1171.26003161
protoculous-1.0.2276.19293157

Если брать во внимание кешированную версию, то разница становится уже не столь очевидна (всего 10–30мс — за исключением Dojo/Scriptaculous). Так как результаты получены полностью с помощью кешированных локальных копий скриптов, мы можем измерить отношения времени загрузки скриптов ко времени их исполнения (инициализации).

После всего вышесказанного я считаю, что такой тип анализа должен быть подвергнут в будущем тщательной проверке. Использование материалов, предоставленных самими пользователями заместо актуальных наборов данных (live datasets) для создания базиса показателей производительности должно быть весьма плодотворным для всех вовлеченных в данный процесс сторон: для пользователей, а также для производителей как платформ для разработок (framework), так и самих браузеров.

Далее John попытался сравнить производительность браузеров, но из-за плохих исходных данных, результаты получились несколько странными. Более подробно его пояснение можно прочитать здесь.

Читать дальше

Все комментарии (habrahabr.ru)