Сравнение эффективности минимизаторов CSS- и JavaScript-кода

    Логотипы модулей-минимизаторов из Bundle Transformer

    Разработчики, использующие Bundle Transformer, часто спрашивают у меня: «Какой минимизатор обладает самой высокой степенью сжатия?». В принципе, в сентябре прошлого года в своей статье «Вышел Bundle Transformer 1.6.2 или что изменилось за полгода?» я уже проводил сравнение минимизаторов по степени сжатия кода, но это сравнение было поверхностным и не было подкреплено цифрами.

    В этой краткой статье мы проведем сравнение наиболее популярных алгоритмов минимизации CSS- и JS-кода на примере адаптеров-минимизаторов из Bundle Transformer. В качестве исходных файлов будут использоваться файлы bootstrap.css и bootstrap.js из Twitter Bootstrap версии 2.3.2. Измерять размеры файлов мы будем с помощью YSlow.

    Сравнение минимизаторов CSS-кода


    Размер исходного файла bootstrap.css составляет 127,3 КБ, а после применения GZip-сжатия — 27,9 КБ. В таблице приведена информация о размерах файлов, полученных путем применения к файлу bootstrap.css различных алгоритмов CSS-минимизации:
    Адаптер-минимизатор Алгоритм минимизации Размер после минимизации Экономия Размер после минимизации с GZip-сжатием Экономия при GZip-сжатии
    YuiCssMinifier YUI CSS Compressor for .Net 2.2.0.0 106,0 КБ 16,73% 24,5 КБ 12,19%
    MicrosoftAjaxCssMinifier Microsoft Ajax CSS Minifier 4.92 105,7 КБ 16,97% 24,5 КБ 12,19%
    KryzhanovskyCssMinifier CSSO 1.3.7 105,6 КБ 17,05% 24,6 КБ 11,83%
    WgCssMinifier WebGrease Semantic CSS Minifier 1.3.0 - - - -

    Из таблицы видно, что наилучший результат показал минимизатор CSSO (CSS Optimizer) от компании Яндекс. Основным достоинством данного минимизатора является поддержка структурной минимизации CSS-кода (о структурной минимизации можно более подробно прочитать на сайте методологии БЭМ).

    К сожалению, структурный минимизатор от компании Microsoft — WebGrease Semantic CSS Minifier, выбыл из борьбы, потому что не смог минимизировать файл bootstrap.css.

    Другой минимизатор от Microsoft — Microsoft Ajax CSS Minifier наоборот показал очень хороший результат по сравнению со своим основным конкурентом YUI CSS Compressor for .Net.

    Сравнение минимизаторов JS-кода


    Размер исходного файла bootstrap.js составляет 61,9 КБ, а после применения GZip-сжатия — 16,9 КБ. В таблице приведена информация о размерах файлов, полученных путем применения к файлу bootstrap.js различных алгоритмов JS-минимизации:
    Адаптер-минимизатор Алгоритм минимизации Размер после минимизации Экономия Размер после минимизации с GZip-сжатием Экономия при GZip-сжатии
    CrockfordJsMinifier JSMin от 22.05.2007 34,5 КБ 44,26% 11,1 КБ 34,32%
    EdwardsJsMinifier Packer 3.0 31,3 КБ 49,43% 10,4 КБ 38,46%
    YuiJsMinifier YUI JS Compressor for .Net 2.2.0.0 28,8 КБ 53,47% 10,0 КБ 40,83%
    ClosureLocalJsMinifier Closure Compiler Application от 11.04.2013 (режим Simple) 28,1 КБ 54,60% 9,7 КБ 42,60%
    MicrosoftAjaxJsMinifier Microsoft Ajax JS Minifier 4.92 28,3 КБ 54,28% 9,8 КБ 42,01%
    UglifyJsMinifier UglifyJS 2.3.6 28,3 КБ 54,28% 9,8 КБ 42,01%

    Как и следовало ожидать, 1-е место занял минимизатор Closure Compiler от компании Google. Следует также отметить, что в режиме Advanced можно достичь еще более лучших результатов.

    Как и в случае с CSS-минимизацией Microsoft Ajax JS Minifier обошел YUI JS Compressor for .Net. Кроме того, при сжатии файла bootstrap.js Microsoft Ajax JS Minifier и UglifyJS показали одинаковый результат и оба заняли 2-е место.

    Старейшие минимизаторы JSMin и Packer показали худшие результаты. Кроме того, код, минимизированный Packer, содержал ошибки.

    Выводы


    Безусловно, в битве минимизаторов победили поисковые гиганты Яндекс и Google.

    Но и компания Microsoft не сидела сложа руки: хоть команда Рона Логана еще не выпустила стабильную версию WebGrease Semantic CSS Minifier, но они смогли поднять Microsoft Ajax Minifier на совершенно новый уровень.

    UglifyJS по-прежнему можно считать JS-минимизатором №2 в мире.

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

    Опрос


    В заключении статьи предлагаю вам принять участие в опросе:

    Only registered users can participate in poll. Log in, please.

    Какой алгоритм минимизации CSS-кода вы используете в своих проектах?

    • 23.5%CSSO (CSS Optimizer)89
    • 4.4%CSSTidy17
    • 0.2%Efficient stylesheet minifier Мэдса Кристенсена1
    • 6.3%Microsoft Ajax CSS Minifier24
    • 1.5%WebGrease Semantic CSS Minifier6
    • 41.2%YUI CSS Compressor156
    • 22.4%Другой85

    Какой алгоритм минимизации JavaScript-кода вы используете в своих проектах?

    • 28.1%Closure Compiler140
    • 8.8%JSMin44
    • 6.2%Microsoft Ajax JS Minifier31
    • 0.8%Packer4
    • 28.9%UglifyJS144
    • 19.6%YUI JS Compressor98
    • 7.4%Другой37
    Share post

    Similar posts

    Comments 26

      0
      А скорость развертования такого кода не считали?
      Мне кажется что после разных процесов минификации будет и разная скорость исполнения, т.к. структура тоже немного изменяется в процесе.
        0
        Нет, такого исследования я не проводил.
          0
          А что может стать причиной замедления? Это же не обусфикация, где расставляют ненужные условия и прочие хитрости, чтобы код невозможно было понять?
            +6
            На самом деле, все JS-минимизаторы, кроме JSMin, производят обфускацию кода путем сокращения имен переменных и функций. A Closure Compiler (особенно в режиме Advanced), UglifyJS и Microsoft Ajax JS Minifier могут сильно изменять структуру JS-кода (например, удалять неиспользуемый код).
              +1
              сокращение имен переменных — это ясно но не думаю что это замедляет интерпритацию кода, удаление неиспользуемого кода — не ясно, как может замедлить, скорее наоборот ускорит интерпритацию
                +1
                А я и не говорю о замедлении. Просто скорость исполнения минимизированного кода может быть разной.
            +1
            Тут зависит, в основном, от того, как написан сам код. Почитать про это можно, если не ошибаюсь, у Стояна Стефанова. Дело в том, что назначая переменные должным образом, можно добиться существенного ускорения после сжатия, насчет подробностей врать не буду.
            +2
            Следует также отметить, что в режиме Advanced Google Closure Compiler может угробить работоспособность кода сотней разных способов. Хотя да, сжимает при этом впечатляюще.

            Что касается минимификации css — подход Яндекса с их BEM'ом мне кажется наиболее интересным, поскольку позволяет сжимать не только содержимое css, но и сами классы-идентификаторы.

            В целом, на мой взгляд тест показывает только то, что особой разницы между минимификаторами в тестируемой конфигурации нет, а значимый результат даёт только глубокая интеграция с соответствующими инструментами.
              +2
              Да, «случайный» код GCC с ADVANCED_OPTIMIZATIONS сломает наверняка, но если изначально писать под него, то проблем с этим почти нет. В довесок к отличному сжатию идет статический анализ типов и тривиальных ошибок, правильный автокомплит в IDE и более сильная «обфускация» кода.

              Попробовал сжать свой проект во всех трех режимах и получились такие цифры:
              583K WHITESPACE_ONLY
              442K SIMPLE_OPTIMIZATIONS
              224K ADVANCED_OPTIMIZATIONS

              Если писать, порой избыточные, JSDoc аннотации кажется сложным, то можно использовать TypeScript с патчем от Michael Bolin, который позволяет компилировать TS код в аннотированный и пригодный для GCC JS код.
                +2
                пригодный для GCC JS код.

                читал по диагонали. охренел. %)
                  +3
                  Ага, gcc -O2 main.js ;)
              +15
              >достичь еще более лучших результатов.
              А так хорошо начал.
              Ну а результат предсказуем — разница на уровне погрешности, использовать можно что привык/что удобно.
                +7
                Справедливости ради, после применения GZip-сжатия CSSO всё же проигрывает.
                  +1
                  Почему-то совершенно забыли минификатор Sass (поставить SCSS-вход и compressed-вывод). На нашем проекте он пару месяц назад показывал лучшие результаты, чем csso.
                    +1
                    Все-таки Sass – это, прежде всего, препроцессор (транслятор с промежуточного языка), и функции минимизации в нем – это просто дополнительный функционал. Мы же в данной статье рассматриваем только чистые минимизаторы, причем наиболее популярные. Если добавить Sass в наш список минимизаторов, то туда придется еще добавить и другие препроцессоры, содержащие встроенные минимизаторы (например, LESS и TypeScript).

                    В любом случае данная статья не может охватить весь спектр минимизаторов CSS- и JS-кода. Например, в наш список не вошли некоторые малораспространенные или устаревшие минимизаторы: CSSTidy, Efficient stylesheet minifier Мэдса Кристенсена, CssMin, CSS::Minifier, Dojo ShrinkSafe, JSMin+, JavaScript::Minifier и т.д.
                      +3
                      А будь добр, приведи примеры того, что SASS сжимает лучше, чем CSSO? Для того же бутстрапа CSSO выдаёт лучший результат.
                        +1
                        Мы мерили с автором csso-rails. Я создал там тикет, чтобы обновили CSSO, так как без этого тестировать не так удобно (хотя попробую чуть позже).
                          +3
                          Да, действительно, сейчас csso лучше Sass — 182,9 кБ (gz 94.2) против 196,7 кБ (gz 96.0).

                          Тогда начну переходить на csso-rails :D.
                        +3
                        Простой вывод из статьи — при использовании GZip-сжатия CSS-минимизаторами пользоваться не обязательно, поскольку сжатый исходный код всего на 12% больше, чем сжатый идеально минимизированный код.

                        С Javascript ситуация интереснее: неминимизированный сжатый код на целых 74% больше.

                        И, конечно, эти несчастные 10-30 кБ закешируются на клиенте после первой же загрузки страницы.
                          +2
                          И, конечно, эти несчастные 10-30 кБ закешируются на клиенте после первой же загрузки страницы.

                          Вчера заходил с мобильного телефона по gprs на один новостной сайт, и очень нехорошо думал о разработчиках, «раздувших» главную страницу до 400кб. И толку от кэширования, если я дальше первой страницы не пойду, получив искомую информацию? Вообщем, это я к тому, что «в век высоких скоростей и толстого оптоволокна» о размере файлов всё-таки думать стоит. Как бы ни хотелось махнуть рукой…
                            +1
                            Это решается отдельной мобильной версией сайта. Почти все известные новостные сайты имеют такую.
                              0
                              Конечно решается, если брать и решать. Но часто и густо заходишь на сайт, загружаешь его полностью, а потом в футере видишь ссылочку «версия для мобильных устройств» — удоооооообно :-)
                            +2
                            Когда у вас огромный проект, где счета за трафик в месяц идут на суммы годовой зарплаты хорошего программиста каждые 10-30 килобайт смогут существенно сэкономить деньги. И нагрузку на сервера в том числе.
                            0
                            Когда вижу сравнения, где из, скажем, 100 Кб CSS-файлика делают минификацией 80 кб, и сравнивают с минификатором, дающим на том же файле 79.5 Кб, начинаю задумываться — авторы сравнения вообще понимают, что эти два результирующих файла могут передавать настолько похожее время, что игра не стоит свечей? Грубо — пакетов придется отправить столько же. Ну хорошо, на один меньше, но его вес не особо будет заметен.

                            Если уж об уменьшении сайтов задумываться — страничку можно при помощи js из кусочков (с разным кешированием) собрать на лету, да и тот же less.js никуда не делся, строгай себе less-файлы, они поменьше будут, и на них кеш тоже отдельно настраивается. Но ведь — ТЬФУ! — всякие популярные CMS и блог-платформы такого разбиения не позволяют из коробки (хотя, глядя в код иных шаблонов для WP, об оптимизации этого добра не хочется и думать), так что остается либо делать шаблон самому, притом так, как самому себе и нравится, либо успокаивать себе, что «мой минификатор жмет на 2% круче» :)
                              +2
                              По-моему, из сравнения минимизаторов CSS-кода можно сделать только один вывод — они все примерно равны. Но выделять победителя на основании 0,30% разницы в экономии, и уж тем более говорить
                              показал очень хороший результат по сравнению
                              как минимум смешно.
                                0
                                Из результатов опроса можно сделать вывод, что наибольшую распространенность получили кроссплатформенные минимизаторы, написанные на Java (Closure Compiler и YUI Compressor) и JavaScript под Node.js (UglifyJS и CSSO). Больше всего, меня удивил UglifyJS, который слегка обогнал по популярности Closure Compiler. Крокфорд был прав, когда говорил, что JavaScript постепенно занимает нишу, изначально отведенную для Java.

                                Only users with full accounts can post comments. Log in, please.