Как стать автором
Обновить

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

Я вот жду когда можно будет использовать одно прогрессивное JPEG изображе как превью, полное на странице и высокого разрешения. Чтоб при этом браузер подгружал только необходимое количество данных для отображения в заданном разрешении.

В оптимизации графики для WEB-а самое важное делится на два совершенно разных поведения:

1) проект в топе по выдаче. И факторы внутренних оптимизаций не имеют значимой величины. Поисковые машины его все равно покажут вверху. Тут имеет смысл читать это руководство, если Вам действительно не все равно что видят пользователи.

2) Ваш проект не в топе и вы конкурируете в Выдаче? Тогда эта статья для Вас почти абсолютно бесполезна. Потому что Ваша задача сделать изображение таким, как бы его поисковый алгоритм оценил как приемлемое. И поднял Вас над конкурентами, потому что подумал бы что Ваш сайт работает быстрее. А сделать это можно только следуя жестким правилам подачи изображений или иметь большой бюджет на программистов с редакторами.

В общем случае это всегда JPG с качеством 85 с интрлейс фильтром 2x2 1x1 1x1, и прогрессивным отображением. И если сделаете иначе полетите ниже своих конкурентов. Почему? Потому что Google робот считает что именно так должно выглядеть изображение в WEB. И они отчасти правы.

У Вас есть деньги на программистов или редакторов?
Вы можете морочить себе голову с WEBp который работает только в Google Chrome одновременно делать ролбэк в JPEG2000 работающий только в Safari и так далее.

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

Такие дела.

НЛО прилетело и опубликовало эту надпись здесь
Хорошая статья (местами, особенно про Guetzli+MozJPEG).
Но, как всегда, есть нюансы…

Сжатие GIF-анимаций и почему <video> лучше

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

ffmpeg -i animated.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)2:trunc(ih/2)2" video.mp4
При этом стоит помнить, что будет использоваться цветовая субдискретизация 4:2:0, что иногда неприемлемо для анимации (тонкие [однопиксельные] цветные темные линии на белом фоне...).

Плохое качество GIF вызвано не сжатием, а палитрой в 256 цветов.
Все же создать анимированный GIF, в котором будет больше 256 цветов — вполне возможно ;)    (полная версия — 15.7 MiB)
А если взять SVG, и включить в него PNG и GIF, то… ;)

Не забудьте сжать SVG!
… не забудьте зазиповать файлы SVG или выдавать их по протоколу Brotli
Либо предварительно сжимать их, используя "pigz -11 --keep --suffix z -- file.svg" (zopfli) — на некоторых моих SVG он давал лучшее сжатие, чем Brotli.

Если приходится использовать анимированные GIF
Инструменты вроде Gifsicle удаляют метаданные, неиспользуемые цвета палитры и минимизируют изменения между кадрами...
Не все так просто ← описан процесс экспорта в GIF этой анимации для Хабра.

Note: чтение может вызвать ассоциацию с сегодняшним постом про "Как восстанавливали видео для Full Throttle Remastered".
При этом стоит помнить, что будет использоваться цветовая субдискретизация 4:2:0, что иногда неприемлемо для анимации
Не все браузеры и устройства могут воспроизводить видео не в yuv420p.
Поэтому для этих случаев (анимации/скринкаста, а не «снятого на камеру видео») пока подходит только GIF (к сожалению).
Как вариант, можно увеличивать общее разрешение видео, и размер элементов интерфейса.
Да, как-то пробовал сделать подобное — из каждого пикселя создавались 4 одинаковых пикселя (масштабирование «по ближайшим пикселям» без интерполяции). При этом плееру, при воспроизведении видео, необходимо было уменьшить его в 2 раза (по высоте и ширине).
Сжатие GIF-анимаций и почему <video> лучше

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

ffmpeg -i animated.gif -movflags faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)2:trunc(ih/2)2" video.mp4
Кстати, попробуйте «сжать» упомянутый мной GIF этой простой командой.

У меня получились такие результаты:

  • GIF:         6 586 702 bytes
  • MP4 (H.264): 5 219 707 bytes (−21%)
    — при этом он стал "не очень приятно выглядеть" и "содержать меньше другие цвета".
Проведите аудит сайта с помощью WebPageTest.org.


WPT, конечно, хорош, но он годами продолжает советовать правильнее настроить загрузку счетчиков Яндекса (ок, еще пойму) и Гугла (уж Гугл в WPT могли бы и знать). И, конечно, если верить всем их советам вроде «У вас есть картинка, которую можно ужать на 110 байтов, с 236 Кб до 235.9 Кб», можно свихнуться — при том, что экномия 110 байтов может и не вилиться в экономию передачи пакета, так что может оказаться бессмысленной.

Я не к тому, что WPT ерунда — сервис-то как раз отличный, и реально крутой — а к тому, что голову надо включать, и думать-думать-думать, в т.ч. и после получения отчета.
круто. ещё бы скрипты сайта так же оптимизировали, чтобы страницы как и раньше весили по 10 мегабайт

Монументально, обязательно к прочтению каждому веб-разработчику. Огромное спасибо за ваш труд.

Отличная статья! Но, боюсь, с текущими трендами картина поменяется и будут актуальны статьи «Оптимизация JavaScript для веба».
Графика остаётся главной причиной ожирения веб-страниц
Смешно.
Стоило бы уделить внимание разнице между jpeg и png. На многих сайтах наблюдается нездоровый подход всё конвертить в jpeg.

И TIFF — не «формат без потерь», а контейнер. В нём легко может быть jpeg.

Иллюстрация разницы цветовых пространств мягко говоря неудачная.
нездоровый подход всё конвертить в jpeg

Например в этой статье. Особенно неуместно было использовать JPEG для иллюстраций типа «Source vs JPEG», когда артефакты сжатия видно и там и там. К переводчику никаких претензий, такая фигня и в оригинале.

Для Busla.
Непонятно, кому эти претензии.
Если к переводчику, то он не может править авторский текст.
Если к автору, то явно ошиблись с сайтом.
Переводчик — молодец, осилить такоооой объем…
НЛО прилетело и опубликовало эту надпись здесь
Мне интересно, а зазипованные bmp'шки не меньше ли будут весить, чем они же перекодированные в jpg?
Поздравляю, вы изобрели png :)
На самом деле, конечно же нет, не будут, за исключением, может быть, вырожденных случаев.
ZIP это достаточно тупая штука, использующая LZ77, и накрывающая сверху Хаффманом. LZ77 умеет хорошо сжимать только хорошо повторяющиеся последовательности, т.е. для этого лучше всех подходит заливка одним цветом, а подобное и jpeg идеально делает.
К сожалению, реальные картинки, кроме заливок одним цветом, имеют еще и резкие границы заливок — и вот тут Jpeg уже не идеален.
Да, я забыл про PNG.
Я всегда за оптимизацию графики, зачастую на проектах именно этот шаг оптимизации дает существенный прирост к скорости и при этом сравнительно дёшево. «Cжатие изображений всегда должно быть автоматизировано» так то оно так, но не всегда получается сжать без потерь. Если контроль качества в лице графического дизайнера не обращаете внимание на искажения нет проблем, но есть еще конечный пользователь. Попробуйте спросить фотографов что они думаю про качество фотографий в VK например. Короче сжимайте всегда, но давайте проверять результат графическому дизайнеру.
---Оптимизация JPEG без потерь достигается путём удаления EXIF-заголовков

Тогда надо бы еще удалять IPTC и XMP заголовки.
Фундаментальная статья!
Дайте ее почитать разрабам github'а — смотрю на размер иконок на главной и хочется плакать…
Я использую вот эти два:
Для тех, кому по-маленькому:
заходим в гугл
developers.google.com/speed/pagespeed/insights/?hl=ru
Вбиваем адрес своего сайта… Ждем… Получаем сжатую графику, скрипты и файлы стилей. Профит.
Для тех кому по-большому и лень.
ImageOptim дает вам 80% сжатие jpeg и стоит 9$ в месяц(до 1000 штук) — пшик.
Комментирую поздно, но лучше поздно, чем никогда.

Во-первых, статья просто эпическая, большое спасибо!

Во-вторых, разрешите поинтересоваться с практической стороны:
Не изучали ли вы сами (или может сталкивались с уже сделанными сравнениями) варианты сжатия .PNG и .JPG, которые можно взять и начать пользоваться без длительной настройки и сравнений?

Время обработки интересует мало, интересует сохранение высокого качества при минимизации размера файла. А то сейчас много как онлайн-сервисов, так и программ/плагинов, но кто из них лучше — понять сложно.

И третье: про те самые ползунки/шкалы степени компрессии (от 0 до 100):
Может быть вы что-то знаете и про них? Потому как сейчас в разных инструментах разная интерпретация этих степеней и как ориентироваться — совершенно непонятно.

Мне думается, что возможно имеет смысл как-то соотнести их со шкалой инструмента «Save for web and devices» в Photoshop. Пишу это отнюдь не потому, что я рьяный поклонник Фотошопа, просто на мой взгляд, эта «метрика» выглядит наиболее распространённой/популярной.
Все разговоры о подготовке файлов для веба я встречал только в её контексте, а предложение использовать сжатие 75 для джпега в интернете, я думаю, слышало большинство хабравчан.
Пробуйте. Использую в работе, но с расширенным функционалом (изменение размера и т.п.).
Странно в такой статье видеть примеры картинок пересохранённые в jpeg. Эдакий пример того как не надо делать в статье о том что надо бы делать

Несколько вопросов:


  1. Есть ли эти инструменты сжатия изображений и конвертер в webp для php? К примеру, хотелось бы проводить оптимизацию картинок при загрузке через CMS.
  2. В статье есть пример с гаусовским размытием превью изображений. Но если использовать в css фильтр blur — то границы изображения тоже размываются и смешиваются с фоном. Получаются засветы. Хотя на скриншоте в примере такой проблемы нет.
  3. При использовании атрибута srcset для каждого варианта изображения надо писать полный путь до него. Пример:

    Хотя в большинстве случаев все варианты лежат в 1 папке, а путь к ней может быть слишком длинным. Можно ли 1 раз указать путь к картинкам, а в srcset перечислять просто название файлов?


Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.