Примечание: ниже перевод заметки John Resig (автора jQuery) "JavaScript Library Loading Speed", в которой он рассматривает, как сжатие, обфускация и архивирование влияет на производительность наиболее распространенных на данный момент JavaScript-библиотек. Мои комментарии даны курсивом.
Опубликована: 5 февраля 2008
Недавно командой PBWiki был проведен весьма впечатляющий анализ производительности JavaScript. Они собирались разобраться, насколько быстро грузятся JavaScript-библиотеки (конечно, их скорость загрузки будет заметно влиять на скорость загрузки всей страницы). Они развернули тестовое окружение для получения информации от различных браузеров, затем собрали все результаты в итоговом отчете. В нем достаточно много информации, которая может быть полезна как разработчикам веб-приложений, так и браузеров: структурированная таким образом информация достаточно обширна.
При загрузке JavaScript-кода обычно предполагается, что чем меньше загружаемый файл, тем быстрее он загрузится. Что это несколько далеко от истины, прекрасно подтверждает дальнейшее исследование. Рассматривается скорость загрузки библиотеки jQuery в трех формах: обычной, уменьшенной (при помощи Yahoo Compressor) и упакованной (используется Packer). Если упорядочить их по размерам, то будет примерно так: самый маленький вариант, естественно, упакованный, затем уменьшенный, затем нормальный. Однако, упакованная версия добавляет некоторые накладные расходы: ее нужно сначала распаковать (выполнять достаточно тяжелый eval
и replace
) с помощью того же JavaScript на стороне клиента. Эта распаковка может занять достаточно продолжительное время при загрузке страницы. Это означает, что использование уменьшенной версии, в конце концов, будет значительно быстрее, чем упакованной — даже при достаточно большом размере файла.
Сравнение упаковки JavaScript (при загрузке jQuery, все варианты)
Вариант | Среднее время | Число примеров |
---|---|---|
Уменьшенный | 519.7214 | 12611 |
Упакованный | 591.6636 | 12606 |
Нормальный | 645.4818 | 12589 |
В следующий раз при использовании любой техники сжатия помните о такой формуле:
Время_загрузки = Время_на_скачивание + Время_на_исполнение
Из этого исследования можно еще получить данные по влиянию производительности различных JavaScript-библиотек на загрузку страницы. Таким образом, более простая и меньшая по размеру библиотека будет загружаться быстрее аналогов. По результатам видно, что jQuery загружается достаточно быстро относительно других библиотек (200–400мс — существенный выигрыш в скорости).
Среднее время загрузки инструментария (не кешированная, не архивированная, не уменьшенная версия)
Инструментарий | Среднее время | Число примеров |
---|---|---|
jquery-1.2.1 | 732.1935 | 3152 |
dojo-1.0.1 | 911.3255 | 3143 |
prototype-1.6.0 | 923.7074 | 3144 |
yahoo-utilities-2.4.0 | 927.4604 | 3141 |
protoculous-1.0.2 | 1136.5497 | 3136 |
Сейчас, возможно, вы возразите, что нечестно тестировать загрузку только некешировнных страниц, ибо, согласно исследованиям Yahoo по кешированию, всего примерно 50% посетителей не будут иметь возможности кешировать содержание страницы. Поэтому также важно убедиться, что не только первоначальная, но и кешированная версия страницы также загружается максимально быстро.
Среднее время загрузки инструментария (кешированная, архивированная и уменьшенная версия)
Инструментарий | Среднее время | Число примеров |
---|---|---|
yahoo-utilities-2.4.0 | 122.7867 | 3042 |
jquery-1.2.1 | 131.1841 | 3161 |
prototype-1.6.0 | 142.7332 | 3040 |
dojo-1.0.1 | 171.2600 | 3161 |
protoculous-1.0.2 | 276.1929 | 3157 |
Если брать во внимание кешированную версию, то разница становится уже не столь очевидна (всего 10–30мс — за исключением Dojo/Scriptaculous). Так как результаты получены полностью с помощью кешированных локальных копий скриптов, мы можем измерить отношения времени загрузки скриптов ко времени их исполнения (инициализации).
После всего вышесказанного я считаю, что такой тип анализа должен быть подвергнут в будущем тщательной проверке. Использование материалов, предоставленных самими пользователями заместо актуальных наборов данных (live datasets) для создания базиса показателей производительности должно быть весьма плодотворным для всех вовлеченных в данный процесс сторон: для пользователей, а также для производителей как платформ для разработок (framework), так и самих браузеров.
Далее John попытался сравнить производительность браузеров, но из-за плохих исходных данных, результаты получились несколько странными. Более подробно его пояснение можно прочитать здесь.