Comments 31
Я вот жду когда можно будет использовать одно прогрессивное JPEG изображе как превью, полное на странице и высокого разрешения. Чтоб при этом браузер подгружал только необходимое количество данных для отображения в заданном разрешении.
В оптимизации графики для WEB-а самое важное делится на два совершенно разных поведения:
1) проект в топе по выдаче. И факторы внутренних оптимизаций не имеют значимой величины. Поисковые машины его все равно покажут вверху. Тут имеет смысл читать это руководство, если Вам действительно не все равно что видят пользователи.
2) Ваш проект не в топе и вы конкурируете в Выдаче? Тогда эта статья для Вас почти абсолютно бесполезна. Потому что Ваша задача сделать изображение таким, как бы его поисковый алгоритм оценил как приемлемое. И поднял Вас над конкурентами, потому что подумал бы что Ваш сайт работает быстрее. А сделать это можно только следуя жестким правилам подачи изображений или иметь большой бюджет на программистов с редакторами.
В общем случае это всегда JPG с качеством 85 с интрлейс фильтром 2x2 1x1 1x1, и прогрессивным отображением. И если сделаете иначе полетите ниже своих конкурентов. Почему? Потому что Google робот считает что именно так должно выглядеть изображение в WEB. И они отчасти правы.
У Вас есть деньги на программистов или редакторов?
Вы можете морочить себе голову с WEBp который работает только в Google Chrome одновременно делать ролбэк в JPEG2000 работающий только в Safari и так далее.
Либо ходить в серой зоне с подстановкой того что робот принимает как адекватное, а пользователю показывать иное. И молиться что Вам не прилетят ручные санкции.
Такие дела.
1) проект в топе по выдаче. И факторы внутренних оптимизаций не имеют значимой величины. Поисковые машины его все равно покажут вверху. Тут имеет смысл читать это руководство, если Вам действительно не все равно что видят пользователи.
2) Ваш проект не в топе и вы конкурируете в Выдаче? Тогда эта статья для Вас почти абсолютно бесполезна. Потому что Ваша задача сделать изображение таким, как бы его поисковый алгоритм оценил как приемлемое. И поднял Вас над конкурентами, потому что подумал бы что Ваш сайт работает быстрее. А сделать это можно только следуя жестким правилам подачи изображений или иметь большой бюджет на программистов с редакторами.
В общем случае это всегда JPG с качеством 85 с интрлейс фильтром 2x2 1x1 1x1, и прогрессивным отображением. И если сделаете иначе полетите ниже своих конкурентов. Почему? Потому что Google робот считает что именно так должно выглядеть изображение в WEB. И они отчасти правы.
У Вас есть деньги на программистов или редакторов?
Вы можете морочить себе голову с WEBp который работает только в Google Chrome одновременно делать ролбэк в JPEG2000 работающий только в Safari и так далее.
Либо ходить в серой зоне с подстановкой того что робот принимает как адекватное, а пользователю показывать иное. И молиться что Вам не прилетят ручные санкции.
Такие дела.
Хорошая статья (местами, особенно про Guetzli+MozJPEG).
Но, как всегда, есть нюансы…
А если взять SVG, и включить в него PNG и GIF, то… ;)
Note: чтение может вызвать ассоциацию с сегодняшним постом про "Как восстанавливали видео для Full Throttle Remastered".
Но, как всегда, есть нюансы…
Сжатие GIF-анимаций и почему <video> лучшеПри этом стоит помнить, что будет использоваться цветовая субдискретизация 4:2:0, что иногда неприемлемо для анимации (тонкие [однопиксельные] цветные темные линии на белом фоне...).
…
Выдача того же видео в формате 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 вызвано не сжатием, а палитрой в 256 цветов.Все же создать анимированный GIF, в котором будет больше 256 цветов — вполне возможно ;) (полная версия — 15.7 MiB)
А если взять SVG, и включить в него PNG и GIF, то… ;)
Не забудьте сжать SVG!Либо предварительно сжимать их, используя "
… не забудьте зазиповать файлы SVG или выдавать их по протоколу Brotli
pigz -11 --keep --suffix z -- file.svg" (zopfli) — на некоторых моих SVG он давал лучшее сжатие, чем Brotli.Если приходится использовать анимированные GIFНе все так просто ← описан процесс экспорта в GIF этой анимации для Хабра.
Инструменты вроде Gifsicle удаляют метаданные, неиспользуемые цвета палитры и минимизируют изменения между кадрами...
Note: чтение может вызвать ассоциацию с сегодняшним постом про "Как восстанавливали видео для Full Throttle Remastered".
При этом стоит помнить, что будет использоваться цветовая субдискретизация 4:2:0, что иногда неприемлемо для анимацииНе все браузеры и устройства могут воспроизводить видео не в yuv420p.
Сжатие GIF-анимаций и почему <video> лучшеКстати, попробуйте «сжать» упомянутый мной GIF этой простой командой.
…
Выдача того же видео в формате 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: 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.
Иллюстрация разницы цветовых пространств мягко говоря неудачная.
И TIFF — не «формат без потерь», а контейнер. В нём легко может быть jpeg.
Иллюстрация разницы цветовых пространств мягко говоря неудачная.
нездоровый подход всё конвертить в jpeg
Например в этой статье. Особенно неуместно было использовать JPEG для иллюстраций типа «Source vs JPEG», когда артефакты сжатия видно и там и там. К переводчику никаких претензий, такая фигня и в оригинале.
Для Busla.
Непонятно, кому эти претензии.
Если к переводчику, то он не может править авторский текст.
Если к автору, то явно ошиблись с сайтом.
Переводчик — молодец, осилить такоооой объем…
Непонятно, кому эти претензии.
Если к переводчику, то он не может править авторский текст.
Если к автору, то явно ошиблись с сайтом.
Переводчик — молодец, осилить такоооой объем…
UFO just landed and posted this here
Мне интересно, а зазипованные bmp'шки не меньше ли будут весить, чем они же перекодированные в jpg?
Поздравляю, вы изобрели png :)
На самом деле, конечно же нет, не будут, за исключением, может быть, вырожденных случаев.
ZIP это достаточно тупая штука, использующая LZ77, и накрывающая сверху Хаффманом. LZ77 умеет хорошо сжимать только хорошо повторяющиеся последовательности, т.е. для этого лучше всех подходит заливка одним цветом, а подобное и jpeg идеально делает.
На самом деле, конечно же нет, не будут, за исключением, может быть, вырожденных случаев.
ZIP это достаточно тупая штука, использующая LZ77, и накрывающая сверху Хаффманом. LZ77 умеет хорошо сжимать только хорошо повторяющиеся последовательности, т.е. для этого лучше всех подходит заливка одним цветом, а подобное и jpeg идеально делает.
Я всегда за оптимизацию графики, зачастую на проектах именно этот шаг оптимизации дает существенный прирост к скорости и при этом сравнительно дёшево. «Cжатие изображений всегда должно быть автоматизировано» так то оно так, но не всегда получается сжать без потерь. Если контроль качества в лице графического дизайнера не обращаете внимание на искажения нет проблем, но есть еще конечный пользователь. Попробуйте спросить фотографов что они думаю про качество фотографий в VK например. Короче сжимайте всегда, но давайте проверять результат графическому дизайнеру.
---Оптимизация JPEG без потерь достигается путём удаления EXIF-заголовков
Тогда надо бы еще удалять IPTC и XMP заголовки.
Тогда надо бы еще удалять IPTC и XMP заголовки.
Фундаментальная статья!
Дайте ее почитать разрабам github'а — смотрю на размер иконок на главной и хочется плакать…
Дайте ее почитать разрабам github'а — смотрю на размер иконок на главной и хочется плакать…
Я использую вот эти два:
Для тех, кому по-маленькому:
заходим в гугл
developers.google.com/speed/pagespeed/insights/?hl=ru
Вбиваем адрес своего сайта… Ждем… Получаем сжатую графику, скрипты и файлы стилей. Профит.
Для тех кому по-большому и лень.
ImageOptim дает вам 80% сжатие jpeg и стоит 9$ в месяц(до 1000 штук) — пшик.
Для тех, кому по-маленькому:
заходим в гугл
developers.google.com/speed/pagespeed/insights/?hl=ru
Вбиваем адрес своего сайта… Ждем… Получаем сжатую графику, скрипты и файлы стилей. Профит.
Для тех кому по-большому и лень.
ImageOptim дает вам 80% сжатие jpeg и стоит 9$ в месяц(до 1000 штук) — пшик.
Оставлю этот скриптик здесь. Может кому пригодится :)
спойлер
Bash скрипт для оптимизации JPEG, PNG и GIF на Linux, MacOS и FreeBSD.
Комментирую поздно, но лучше поздно, чем никогда.
Во-первых, статья просто эпическая, большое спасибо!
Во-вторых, разрешите поинтересоваться с практической стороны:
Не изучали ли вы сами (или может сталкивались с уже сделанными сравнениями) варианты сжатия .PNG и .JPG, которые можно взять и начать пользоваться без длительной настройки и сравнений?
Время обработки интересует мало, интересует сохранение высокого качества при минимизации размера файла. А то сейчас много как онлайн-сервисов, так и программ/плагинов, но кто из них лучше — понять сложно.
И третье: про те самые ползунки/шкалы степени компрессии (от 0 до 100):
Может быть вы что-то знаете и про них? Потому как сейчас в разных инструментах разная интерпретация этих степеней и как ориентироваться — совершенно непонятно.
Мне думается, что возможно имеет смысл как-то соотнести их со шкалой инструмента «Save for web and devices» в Photoshop. Пишу это отнюдь не потому, что я рьяный поклонник Фотошопа, просто на мой взгляд, эта «метрика» выглядит наиболее распространённой/популярной.
Все разговоры о подготовке файлов для веба я встречал только в её контексте, а предложение использовать сжатие 75 для джпега в интернете, я думаю, слышало большинство хабравчан.
Во-первых, статья просто эпическая, большое спасибо!
Во-вторых, разрешите поинтересоваться с практической стороны:
Не изучали ли вы сами (или может сталкивались с уже сделанными сравнениями) варианты сжатия .PNG и .JPG, которые можно взять и начать пользоваться без длительной настройки и сравнений?
Время обработки интересует мало, интересует сохранение высокого качества при минимизации размера файла. А то сейчас много как онлайн-сервисов, так и программ/плагинов, но кто из них лучше — понять сложно.
И третье: про те самые ползунки/шкалы степени компрессии (от 0 до 100):
Может быть вы что-то знаете и про них? Потому как сейчас в разных инструментах разная интерпретация этих степеней и как ориентироваться — совершенно непонятно.
Мне думается, что возможно имеет смысл как-то соотнести их со шкалой инструмента «Save for web and devices» в Photoshop. Пишу это отнюдь не потому, что я рьяный поклонник Фотошопа, просто на мой взгляд, эта «метрика» выглядит наиболее распространённой/популярной.
Все разговоры о подготовке файлов для веба я встречал только в её контексте, а предложение использовать сжатие 75 для джпега в интернете, я думаю, слышало большинство хабравчан.
Пробуйте. Использую в работе, но с расширенным функционалом (изменение размера и т.п.).
Странно в такой статье видеть примеры картинок пересохранённые в jpeg. Эдакий пример того как не надо делать в статье о том что надо бы делать
Несколько вопросов:
- Есть ли эти инструменты сжатия изображений и конвертер в webp для php? К примеру, хотелось бы проводить оптимизацию картинок при загрузке через CMS.
- В статье есть пример с гаусовским размытием превью изображений. Но если использовать в css фильтр blur — то границы изображения тоже размываются и смешиваются с фоном. Получаются засветы. Хотя на скриншоте в примере такой проблемы нет.
- При использовании атрибута srcset для каждого варианта изображения надо писать полный путь до него. Пример:
Хотя в большинстве случаев все варианты лежат в 1 папке, а путь к ней может быть слишком длинным. Можно ли 1 раз указать путь к картинкам, а в srcset перечислять просто название файлов?
Sign up to leave a comment.
Оптимизация графики для веба: самое важное