Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 26

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

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

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

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

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

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

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

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

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

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

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

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

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr