How to become an author
Search
Write a publication
Pull to refresh

Comments 26

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

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

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

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

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

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

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

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

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

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

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

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

Articles

Your account

Sections

Information

Services

Support
© 2006–2024, Habr