Уменьшение размера

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

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

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

Ниже приводится сравнение времени загрузки различных вариантов уменьшения jQuery.

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

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

Именно поэтому упакованный вариант, будучи наименьшим по размеру, может проигрывать в производительности другим, менее экстремальным способам представления информации.

Подводя итог всем вышеприведенным выкладкам, можно сделать следующее заключение. Если использовать gzip-сжатие для текстовых файлов, то наилучшим выбором будет применение YUI Compressor для дополнительной минимизации CSS- и JavaScript-файлов. Результирующий файл будет в среднем самым маленьким из возможных вариантов сжатия и будет загружаться в браузере максимально быстро.

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

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

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

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

Но давайте на этом закончим со сжатием текстовых файлов и перейдем к более интересным случаям — уменьшению в размере различных форматов изображений.

PNG против GIF

Переносимый сетевой графический формат (англ. Portable Network Graphics, PNG) разрабатывается как более эффективная, гибкая и свободная от патентов замена GIF-формату. PNG был задуман для хранения отдельных растровых изображений и дальнейшего их распространения по компьютерным сетям. PNG был создан в 1995 году в ответ на давление со стороны Unisys и их патента на алгоритм LZW-сжатия, используемый в GIF. Хотя срок действия патента Unisys уже закончился, причины на переход от GIF к PNG остались практически прежними. Заменив GIF-изображения теми же самыми, но в формате PNG, можно ускорить загрузку страниц и сэкономить трафик пользователей.

Алгоритмы сжатия

PNG использует алгоритм deflate-сжатия обычно со скользящим окном в 32/Кб. Deflate является улучшенной версией алгоритма сжатия Lempel-Ziv (LZ77), который применяется в zip- и gzip -файлах. Созданный Phil Katz для второй версии PKZip, deflate совмещает LZ77 с кодированием Huffman и является на 10-30% более эффективным, чем LZW, при сжатии без потери информации. Так же как и gzip, некоторые инструменты по PNG-сжатию предполагают опциональный параметр "степень сжатия", который варьируется от 1 до 9. По умолчанию выставляется 6. Практически всегда лучшим выбором для максимального сжатия является 9.

Неудивительно, что изображения, сохраненные как PNG, обычно на 10-30% меньше по размеру, чем GIF, хотя в некоторых редких случаях они могут быть несколько больше (чаще всего это проявляется для небольших изображений). Обычно изображения с большими однотонными областями сжимаются лучше, чем градиентные с большим количеством переходов между цветами.

Возможности PNG

В PNG присутствует набор возможностей, которые делают его привлекательным для использования во многих отраслях, где требуется применение ограниченной палитры. Поддержка в PNG 16-битной серой шкалы прекрасно подходит для создания точных радиологических изображений. PNG предварительно фильтрует данные по конкретному изображению при помощи предсказательных функций. Одной из них является "Вверх" (англ. Up ), которая ищет похожие наборы данных в вертикальных шаблонах для полноцветных PNG. PNG с индексированными цветами (8 битов или меньше) обычно не выигрывает от использования фильтрации, поэтому стоит использовать "Ничего" (англ. none ), если есть возможность выбора. Для полноцветных или серых изображений лучше применять "Адаптивный" (англ. Adaptive ) алгоритм.

Как говорит Greg Roelofs, "PNG в основном используется для создания 24-битных изображений в RGB-палитре, например картин с рассчитанным освещением с минимальным числом текстур или математических объектов. Они все обладают искусственно сглаженными цветовыми переходами, которые хорошо сжимаются при помощи PNG-фильтров. Некоторые фракталы могут вести себя таким же образом, но у многих из самых лучших примеров имеется достаточно "зашумленных" областей, которые сжимаются весьма слабо".

Для веб-страниц вполне можно использовать PNG8 (8-битный формат), с помощью которого дизайнеры могут заменить существующие GIF-изображения. У PNG также может быть альфа-значение для каждого цвета в палитре, которое фактически означает, что используется RGBA-палитра, а не RGB-XOR-маска, как GIF. Это позволяет варьировать прозрачность цвета в больших пределах, сохраняя преимущества 8-битного изображения перед 32-битным. PNG могут также содержать только один уровень прозрачности, совсем как GIF89a. Алгоритм сжатия PNG для повторяющихся горизонтальных шаблонов совпадает с LZW-сжатием в GIF.

Многослойный PNG-файл также может быть отображен на экране по загрузке только 25% всего файла, в то время как GIF требует загрузки 50% размера перед распознаванием. За исключением весьма редких случаев замена GIF-изображений на PNG-эквиваленты способна существенно уменьшить их размер.

Ниже приведены некоторые из возможностей PNG-формата.

• 8-битные (индексированная палитра), 16-битные серые или 48-битные полноцветные изображения.
• Градация альфа-прозрачности до 16 битов.
• Гамма-коррекция (хотя эта возможность может быть проблематичной).
• Улучшенный по сравнению с LZW алгоритм сжатия.
• Двумерная схема для многоуровневых изображений (Adam7).
• Метаданные (сжатые или несжатые).
• Формат, свободный от патентов.