веб-разработчик
Мы потихоньку переходим на Хабр с корпоративным блогом Аймобилко, где я и мои коллеги будем рассказывать о том, как создавались наши сервисы. Первая статья: рассказ про создание движка онлайн-читалки booq (так называется движок, сам сервис называется Айчиталка).
Пока пишу с корпоративного аккаунта, а если суппорт Хабра таки отдуплится и поправит баги, то буду писать со своего.
Хоть и зарекался я не рекомендовать инструменты для пакетной оптимизации графики, но тут все-таки придется.
Встречайте нового игрока — punypng. Новый сервис, очень похожий (но пока не такой удобный) на известный smush.it.
После публикации на SM первой части статьи про оптимизацию PNG со мной связались ребята из проекта Ask.com — довольно известного на Западе поисковика. Они как раз начали разрабатывать очередной оптимизатор картинок для веба. Немного проконсультировавшись, они добавили чистку прозрачных пикселей, что в большинстве случаев дает довольно ощутимое сжатие. Так что я теперь являюсь консультантом проекта punypng, а этот пост — наглый пиар 
А теперь немного конкретики. Я прогнал несколько тестовых изображений через этот сервис и могу сказать, что результат был действительно впечатляющим. Практически на всех изображениях удавалось достичь дополнительного сжатия. Даже на изображениях, которые я оптимизировал вручную и прогнал через OptiPNG.
Чтобы сравнить результаты, я дополнительно прогнал несколько изображений (наиболее показательным оказалось вот это) через smush.it и ImageOptim.
smush.it использует утилиту pngcrush, которая по всем меркам является устаревшей. Она пытается перепаковать изображения, не меняя их тип (например, черно-белая RGB-картинка не будет преобразована в Grayscale). Утилита OptiPNG, которая является ответвлением от pngcrush, делает такие преобразования автоматически, но при этом работает гораздо медленнее (поэтому на smush.it используется pngcrush). Так что от этого сервиса ждать каких-то выдающихся результатов пока не приходится. Однако на выходе мы получаем «безопасное» преобразование, которое гарантирует, например, что полноцветный полупрозрачный PNG не будет преобразован в полупрозрачный PNG с палитрой (разница в отображении в IE6).
ImageOptim, в свою очередь, пытается прогнать изображение через несколько библиотек, выбирая наилучший результат. Среди этих библиотек — PNGOUT Кена Сильвермана, которая априори должа выдавать лучший результат, так как использует собственный алгоритм упаковки данных. Даже она не смогла сжать лучше, чем punypng. Не говоря уже о том, что punypng отработал горазо быстрее, чем ImageOptim.
Так что от всей души советую попробовать этот сервис. Я, в свою очередь, постараюсь описать больше алгоритмов оптимизации изображений, чтобы сделать сервис еще лучше.
UPD: Окей, значит, расклад такой.
PNGOUT сам не умеет перебирать фильтры. Как правильно заметил Павел у себя в блоге, с этим успешно справляется OptiPNG, выдавая в консоль статистику обработки файла. Соответственно, правильный способ максимального сжатия файла такой: сначала пропускаем через OptiPNG, получаем от него номер N примененного фильтра и отдаем его в качестве параметра -fN для PNGOUT.
По поводу ImageOptim. Судя по исходнику, там PNGOUT используется без указания правильного фильтра, и, более того, применяет библиотеки не друг за другом на одном и том же файле, а независимо, выбирая наименьший результат (поправьте меня если не прав, так как Objective-C не знаю). Поэтому и результат сжатия у меня получился не самый лучший.
PNGSquash, напротив, применяет библиотеки в цепочке, поэтому получается так сильно сжать файлы. Так что эта программка работает лучше, чем ImageOptim.
Сейчас узнаю, как работает punypng.
UPD2: punypng не использует PNGOUT из-за лицензионных ограничений. Есть вероятность того, что ребята сделают офлайновую версию punypng: для этого нужно всей толпой проголосовать за это предложение.
Специально для Smashing Magazine написал руководство по оптимизации PNG (вернее, наоборот: руководство по оптимизации изображений для PNG). По сути, это собранные вместе статьи из Техногрета и моего блога, которые были немного переосмыслены, дополнены, упрощены и переведены на английский язык.
Так как статья получилась довольно большой, ее разделили на две части. Вторая часть выйдет через неделю. Комментарии, вопросы и пожелания можно оставлять здесь.
В последнее время все чаще и чаще слышу советы запускать какую-нибудь утилитку оптимизации графики вроде OptiPNG на всей папке с картинками, чтобы не запариваться и одним махом ужать все файлы. Например, вот так:
optipng -o5 *.png
Создают даже целые сервисы вроде smush.it.
Так вот, лично я никогда не пользовался такими советами. И пока не рекомендую делать этого ребятам, которые действительно хотят качественно оптимизировать графику. По одной простой причине: «меньше» не всегда значит «лучше».
Что бы не говорили злые языки, но доля IE6 на рынке все еще слишком велика, чтобы сбрасывать его со счетов. Именно у этого браузера больше всего проблем с отображением разных вариаций PNG. В частности, полноцветный полупрозрачный PNG (PNG24 в терминологии фотошопа) он просто так не покажет, нужно использовать фильтр AlphaImageLoader или VML. А у полупрозрачных индексированных PNG покажет только непрозрачные пиксели. Из этого следует вывод, что нужно контролировать оптимизацию каждого файла.
Рассмотрим несколько примеров. Для начала возьмем полупрозрачную плашку:
…и вызовем на ней OptiPNG:
optipng -o5 mate.png
Он нам скажет, что самым оптимальным способом хранения этого изображения будет 8-битная палитра. Но так как на этой картинке нет ни одного непрозрачного пикселя, то в IE6 не отобразится вообще ничего. Поэтому для данного изображения нужно отключить оптимизацию по цвету:
optipng -o5 -nc mate.png
Рассмотрим второй пример:
При попытке оптимизировать этот файл OptiPNG преобразует изображение в 8-битную палитру, однако это будет не оптимальный способ хранения изображения и вы увидите сообщение, что файл уже оптимизирован. Но я готов пожертвовать «гладкими» краями в IE6, лишь бы не извращаться с фильтрами и VML, потому что этот файл будет использоваться 50 раз на странице. Кто не в курсе: AlphaImageLoader жрет очень много памяти и процессорного времени, VML менее требователен, но все равно больше, чем обычная картинка или фон. Поэтому в данном случае нужно форсировать преобразование палитры:
optipng -o5 -force corner.png
Еще одним плюсом ручной оптимизации для меня является соответствие моих ожиданий действительности. Очень часто при сохранении черно-белых PNG я забывают выставить им режим цветовой Grayscale, а лог OptiPNG постоянно мне об этом напоминает, когда процент сжатия меньше 20. Кстати, smush.it не умеет преобразовывать цветовую палитру в черно-белую.
Один из моих докладов для конференции Clienttech 2008 (второй был про ictinus).
У меня наконец-то дошли руки до описания известных мне проблем с производительностью в браузерах в зависимости от того, как сверстаешь страницу. Результаты тестов говорят сами за себя: Opera ни разу не «самый быстрый браузер на планете» (в моем рейтинге качества браузеров последние версии Оперы находятся примерно между IE7 и IE6), а восторженные вопли о быстрых JavaScript-движках я воспринимаю как говеный пиар. На кой черт мне сдались ваши ускоренные работы со строками и массивами, когда банальное изменение размеров картинки, даже не динамическое, вызывает жуткие тормоза? Почему разработчики браузеров не оптимизируют то, что действительно требует оптимизации? Спросите сами себя, для чего вы чаще используете JavaScript на сайтах: для работы со встроенными JavaScript-объектами или для работы c DOM? Ведь именно работа с DOM — самое узкое место современных браузеров.
В этом свете мне наиболее близка позиция Майкрософта. Где-то, не помню где, они написали что-то вроде: «Оптимизировать работу чистого JavaScript будет только безумец».
