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

[@trijin]

А скорость развертования такого кода не считали?
Мне кажется что после разных процесов минификации будет и разная скорость исполнения, т.к. структура тоже немного изменяется в процесе.

[@Taritsyn]

Нет, такого исследования я не проводил.

[@hell0w0rd]

А что может стать причиной замедления? Это же не обусфикация, где расставляют ненужные условия и прочие хитрости, чтобы код невозможно было понять?

[@Taritsyn]

На самом деле, все JS-минимизаторы, кроме JSMin, производят обфускацию кода путем сокращения имен переменных и функций. A Closure Compiler (особенно в режиме Advanced), UglifyJS и Microsoft Ajax JS Minifier могут сильно изменять структуру JS-кода (например, удалять неиспользуемый код).

[@hell0w0rd]

сокращение имен переменных — это ясно но не думаю что это замедляет интерпритацию кода, удаление неиспользуемого кода — не ясно, как может замедлить, скорее наоборот ускорит интерпритацию

[@Taritsyn]

А я и не говорю о замедлении. Просто скорость исполнения минимизированного кода может быть разной.

[@Goobs]

Тут зависит, в основном, от того, как написан сам код. Почитать про это можно, если не ошибаюсь, у Стояна Стефанова. Дело в том, что назначая переменные должным образом, можно добиться существенного ускорения после сжатия, насчет подробностей врать не буду.

[@antarx]

Следует также отметить, что в режиме Advanced Google Closure Compiler может угробить работоспособность кода сотней разных способов. Хотя да, сжимает при этом впечатляюще.

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

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

[@lacki]

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

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

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

[@funca]

пригодный для GCC JS код.

читал по диагонали. охренел. %)

[@lacki]

Ага, gcc -O2 main.js ;)

[@R0ckwi11]

>достичь еще более лучших результатов.
А так хорошо начал.
Ну а результат предсказуем — разница на уровне погрешности, использовать можно что привык/что удобно.

[@oshibka404]

Справедливости ради, после применения GZip-сжатия CSSO всё же проигрывает.

[@Iskin]

Почему-то совершенно забыли минификатор Sass (поставить SCSS-вход и compressed-вывод). На нашем проекте он пару месяц назад показывал лучшие результаты, чем csso.

[@Taritsyn]

Все-таки Sass – это, прежде всего, препроцессор (транслятор с промежуточного языка), и функции минимизации в нем – это просто дополнительный функционал. Мы же в данной статье рассматриваем только чистые минимизаторы, причем наиболее популярные. Если добавить Sass в наш список минимизаторов, то туда придется еще добавить и другие препроцессоры, содержащие встроенные минимизаторы (например, LESS и TypeScript).

В любом случае данная статья не может охватить весь спектр минимизаторов CSS- и JS-кода. Например, в наш список не вошли некоторые малораспространенные или устаревшие минимизаторы: CSSTidy, Efficient stylesheet minifier Мэдса Кристенсена, CssMin, CSS::Minifier, Dojo ShrinkSafe, JSMin+, JavaScript::Minifier и т.д.

[@kizu]

А будь добр, приведи примеры того, что SASS сжимает лучше, чем CSSO? Для того же бутстрапа CSSO выдаёт лучший результат.

[@Iskin]

Мы мерили с автором csso-rails. Я создал там тикет, чтобы обновили CSSO, так как без этого тестировать не так удобно (хотя попробую чуть позже).

[@Iskin]

Да, действительно, сейчас csso лучше Sass — 182,9 кБ (gz 94.2) против 196,7 кБ (gz 96.0).

Тогда начну переходить на csso-rails :D.

[@eps]

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

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

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

[@Theo_from_Sed]

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

Вчера заходил с мобильного телефона по gprs на один новостной сайт, и очень нехорошо думал о разработчиках, «раздувших» главную страницу до 400кб. И толку от кэширования, если я дальше первой страницы не пойду, получив искомую информацию? Вообщем, это я к тому, что «в век высоких скоростей и толстого оптоволокна» о размере файлов всё-таки думать стоит. Как бы ни хотелось махнуть рукой…

[@MARDEN]

Это решается отдельной мобильной версией сайта. Почти все известные новостные сайты имеют такую.

[@Theo_from_Sed]

Конечно решается, если брать и решать. Но часто и густо заходишь на сайт, загружаешь его полностью, а потом в футере видишь ссылочку «версия для мобильных устройств» — удоооооообно :-)

[@vitalybaev]

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

[@achekalin]

Когда вижу сравнения, где из, скажем, 100 Кб CSS-файлика делают минификацией 80 кб, и сравнивают с минификатором, дающим на том же файле 79.5 Кб, начинаю задумываться — авторы сравнения вообще понимают, что эти два результирующих файла могут передавать настолько похожее время, что игра не стоит свечей? Грубо — пакетов придется отправить столько же. Ну хорошо, на один меньше, но его вес не особо будет заметен.

Если уж об уменьшении сайтов задумываться — страничку можно при помощи js из кусочков (с разным кешированием) собрать на лету, да и тот же less.js никуда не делся, строгай себе less-файлы, они поменьше будут, и на них кеш тоже отдельно настраивается. Но ведь — ТЬФУ! — всякие популярные CMS и блог-платформы такого разбиения не позволяют из коробки (хотя, глядя в код иных шаблонов для WP, об оптимизации этого добра не хочется и думать), так что остается либо делать шаблон самому, притом так, как самому себе и нравится, либо успокаивать себе, что «мой минификатор жмет на 2% круче» :)

[@cheef]

По-моему, из сравнения минимизаторов CSS-кода можно сделать только один вывод — они все примерно равны. Но выделять победителя на основании 0,30% разницы в экономии, и уж тем более говорить

показал очень хороший результат по сравнению

как минимум смешно.

[@Taritsyn]

Из результатов опроса можно сделать вывод, что наибольшую распространенность получили кроссплатформенные минимизаторы, написанные на Java (Closure Compiler и YUI Compressor) и JavaScript под Node.js (UglifyJS и CSSO). Больше всего, меня удивил UglifyJS, который слегка обогнал по популярности Closure Compiler. Крокфорд был прав, когда говорил, что JavaScript постепенно занимает нишу, изначально отведенную для Java.