Comments 28
А ещё можно взять и настроить веб-сервер (через тот же .htaccess) и выдавать по возможности webp-изображение при его существовании и поддержке браузером пользователя. Беглый поиск по интернетам выдал что-то такое
UFO just landed and posted this here
UFO just landed and posted this here
При переводе в WebP через командную строку есть множество настроек. Приемлемость потерь можно посмотреть в архиве. На картинках я не смог заметить разницу, возможно на длинных градиентах будет заметно. Замыливание в WebP в любом случае выглядит куда лучше квадратиков.
На счет серверов, все такие не в 2 раза больше, а не более полутора. На счет кеша я не силен, но по моему мнению, увеличить размер сервера, чтобы увеличить скорость загрузки сайта вполне хорошая идея. Особенно для сервисов в которых доля изображений еще больше.
На счет серверов, все такие не в 2 раза больше, а не более полутора. На счет кеша я не силен, но по моему мнению, увеличить размер сервера, чтобы увеличить скорость загрузки сайта вполне хорошая идея. Особенно для сервисов в которых доля изображений еще больше.
Тест проведён неправильно:
— Вы включили в набор фотографии в формате PNG (5165 килобайт, сжатие без потерь) и сравниваете их с WebP (686 килобайт, но это сжатие с потерями!).
— Вы не оптимизировали исходные изображения в формате JPEG. В интернете большинство изображений никак не оптимизированы, и их часто можно уменьшить даже в разы без ощутимых потерь, с использованием стандартных форматов (JPEG для фотографий, PNG для схем и т.д.).
— Вы банально даже не заметили, что часть изображений, исходники которых были в формате JPEG, стали весить больше после конвертации в WebP (j_cat1 и j_cat3).
Ни о каких 70% выигрыша тут не может быть и речи, это обман. Хорошо, если при честном слепом тестировании WebP покажет хотя бы на 20% меньший объём при равном визуальном качестве.
Для примера, я взял пару ваших оригинальных фотографий, сжал их в JPEG до того же объёма, что у вас получился в WebP.
— Пример номер 1. Оригинал: j_girl3_orig.jpg (380 килобайт); JPEG: j_girl3.jpg (97 килобайт); WebP: j_girl3.webp (94 килобайт).
— Пример номер 2. Оригинал: p_dog1_orig.png (1609 килобайт); JPEG: p_dog1.jpg (91 килобайт); WebP: p_dog1.webp (91 килобайт).
Качество получилось сравнимым. Что в случае с вашими WebP, что в случае с моими оптимизированными JPEG, я вижу небольшие отличия в равном количестве, если буду присматриваться. То есть что JPEG, что WebP дали примерно одинаковый результат.
— Вы включили в набор фотографии в формате PNG (5165 килобайт, сжатие без потерь) и сравниваете их с WebP (686 килобайт, но это сжатие с потерями!).
— Вы не оптимизировали исходные изображения в формате JPEG. В интернете большинство изображений никак не оптимизированы, и их часто можно уменьшить даже в разы без ощутимых потерь, с использованием стандартных форматов (JPEG для фотографий, PNG для схем и т.д.).
— Вы банально даже не заметили, что часть изображений, исходники которых были в формате JPEG, стали весить больше после конвертации в WebP (j_cat1 и j_cat3).
Ни о каких 70% выигрыша тут не может быть и речи, это обман. Хорошо, если при честном слепом тестировании WebP покажет хотя бы на 20% меньший объём при равном визуальном качестве.
Для примера, я взял пару ваших оригинальных фотографий, сжал их в JPEG до того же объёма, что у вас получился в WebP.
— Пример номер 1. Оригинал: j_girl3_orig.jpg (380 килобайт); JPEG: j_girl3.jpg (97 килобайт); WebP: j_girl3.webp (94 килобайт).
— Пример номер 2. Оригинал: p_dog1_orig.png (1609 килобайт); JPEG: p_dog1.jpg (91 килобайт); WebP: p_dog1.webp (91 килобайт).
Качество получилось сравнимым. Что в случае с вашими WebP, что в случае с моими оптимизированными JPEG, я вижу небольшие отличия в равном количестве, если буду присматриваться. То есть что JPEG, что WebP дали примерно одинаковый результат.
Вы сейчас спорите, пытаясь определить уровень потерь «на глаз».
Но сейчас уже есть множество алгоритмов, показывающих меру субъективного сходства между изображениями, отлично коррелирующих с субъективными оценками.
Один из самых простых приёмов — использование SSIM метрики.
Также могу посоветовать использовать такую программу, как MSU Quality Measurement Tool, если нужно больше метрик, хороших и разных (рекомендую 3-Component SSIM).
Но сейчас уже есть множество алгоритмов, показывающих меру субъективного сходства между изображениями, отлично коррелирующих с субъективными оценками.
Один из самых простых приёмов — использование SSIM метрики.
Также могу посоветовать использовать такую программу, как MSU Quality Measurement Tool, если нужно больше метрик, хороших и разных (рекомендую 3-Component SSIM).
Где вы здесь увидели спор? Тест проведён отвратительно, и я указал в каких именно моментах он проведён неправильно, и почему заявление про выигрыш 70% — чистой воды обман и подтасовка фактов. Также я показал, что JPEG при том же объёме выглядит примерно так же, как и WebP. Это сравнение не претендует на роль «ответного тестирования», это просто демонстрация того, что и обычный JPEG есть куда оптимизировать, чего автор даже не попытался сделать.
Если вам интересен более-менее серьёзный тест форматов сжатия с потерями, можете изучить соответствующие тесты, проведённые Mozilla: октябрь 2013 года и июль 2014 года. Как видно, JPEG держится достойно и часто показывает результат даже лучше, чем WebP. А вот HEVC-MSP выглядит действительно перспективным. Жалко, что он запатентован по самое не хочу, и скорее всего мы не увидим его в браузерах.
Если вам интересен более-менее серьёзный тест форматов сжатия с потерями, можете изучить соответствующие тесты, проведённые Mozilla: октябрь 2013 года и июль 2014 года. Как видно, JPEG держится достойно и часто показывает результат даже лучше, чем WebP. А вот HEVC-MSP выглядит действительно перспективным. Жалко, что он запатентован по самое не хочу, и скорее всего мы не увидим его в браузерах.
Спасибо за проведенную проверку, я понадеялся на ImageOptim, чего не надо было делать. Отдельное спасибо за ссылки на тесты. А как вам формат BPG? При сильном сжатии очень хорошие результаты показывает.
Это по сути и есть HEVC-MSP, просто со своим заголовком.
А JPEG я сохранял через Save for Web без различной мета-информации в Photoshop CS2 (эту устаревшую, но рабочую версию программы плюс ключи к ней можно скачать прямо на сайте Adobe после регистрации). Такое сжатие хорошо тем, что можно сразу увидеть результирующее визуальное качество и примерный объём файла после сжатия. После Photoshop файл можно ещё дожать (без дополнительных потерь в качестве) при помощи jpegtran из набора mozjpeg командой:
В принципе, это можно и автоматизировать при желании.
jpegtran -copy none -optimize -outfile output.jpg input.jpgВ принципе, это можно и автоматизировать при желании.
Вы пастеризацию и постеризацию сейчас перепутали.
Ну на счёт качества — это субъективно.
На счёт места — не так и много то выходит. Если у Вас даже 500 гигов графики (ого подумал я) и Вы таки решили оптимизировать и хранить ещё WebP, то вы потратите не ещё 500 гигов, а, скажем, +300/+400.
Да, это затраты, но если это решение поможет вашему ресурсу грузиться на 20-30% быстрее, что скажем принесёт Вам увеличение Вашей аудитории сайта на 8% и эти 8% с головой покрывают Ваши расходы на доп. дисковое пространство. То почему бы и нет? Лично мне приятно делать людям хорошо и уменьшать их время ожидания загрузки сайта.
На счёт места — не так и много то выходит. Если у Вас даже 500 гигов графики (ого подумал я) и Вы таки решили оптимизировать и хранить ещё WebP, то вы потратите не ещё 500 гигов, а, скажем, +300/+400.
Да, это затраты, но если это решение поможет вашему ресурсу грузиться на 20-30% быстрее, что скажем принесёт Вам увеличение Вашей аудитории сайта на 8% и эти 8% с головой покрывают Ваши расходы на доп. дисковое пространство. То почему бы и нет? Лично мне приятно делать людям хорошо и уменьшать их время ожидания загрузки сайта.
Обычно еще и -x2/x3/x4 (retina), если не использовать zoom:
Добавим превью в 2-х вариантах (минимум).
Добавим кэш с водяными знаками.
Добавим разъяренных («продвинутых») пользователей, дядь Валер с Урюпинска, не понимающих, как сохранить картинку себе в каталог на excel.
И получим 100500 охренебайт картинок, БЭКАПОВ картинок, зоопарк mime-type и вот это всё выше.
Нет. Спасибо. Я уж как-нибудь с жипег поживу и content-encoding: gzip на png.
Добавим превью в 2-х вариантах (минимум).
Добавим кэш с водяными знаками.
Добавим разъяренных («продвинутых») пользователей, дядь Валер с Урюпинска, не понимающих, как сохранить картинку себе в каталог на excel.
И получим 100500 охренебайт картинок, БЭКАПОВ картинок, зоопарк mime-type и вот это всё выше.
Нет. Спасибо. Я уж как-нибудь с жипег поживу и content-encoding: gzip на png.
Оригинальные в формате WebP — 1,6 МБ
После сжатия в формате WebP — 1,8 МБ
То есть больше стало? Или ошибка?
Если сопоставить браузеры, поддерживающие WebP и браузеры, подерживающие
WebP и Picture:
Вот вам пара статей про
— Native Responsive Images
— Responsive Images: Use Cases and Documented Code Snippets to Get You Started
<picture>, то получится хорошее пересечение. Почему бы вместо скрипта не воспользоваться возможностями HTML? Фолбечится это на «ура»: не знаешь <picture> — берёшь <img><picture>
<source srcset="opera.webp" type="image/webp">
<img src="opera.jpg" alt="The Oslo Opera House">
</picture>WebP и Picture:
Вот вам пара статей про
<picture> на Dev.Opera для изучения:— Native Responsive Images
— Responsive Images: Use Cases and Documented Code Snippets to Get You Started
Фолбек через srcset не cработает разве?
Зачем тащить лишние скрипты?
Зачем тащить лишние скрипты?
Очень грамотно написано «Поэтому начинать оптимизацию скорости загрузки страницы нужно именно с графики.», почему то многие про это забывают когда делается оптимизацию «для галочки». Я использую ImageOptim на Mac, FileOptimizer для Windows и svgo-gui для векторной графики(можно запускать и как задачу в grunt, но надо следить за каждым файлом). На одном блоге который я администрировал, запустив ImageOptim на ночь, утром получил суммарную оптимизацию на 70 мегабайт.
На хабре была статья «Обзор инструментов для сжатия изображений», в которой FileOptimizer очень хорошо себя показал. Для мака, к сожалению, кроме ImageOptim я вариантов даже не знаю. В продакшене оптимизацию делаю через gulp.
И опять я напомню про довольно странную позицию Mozilla, по сути ограничивающую прогресс — webp это не только сжатие данных, но еще и современный формат анимации, на замену древнему GIF. Однако, ввиду каких-то своих непонятных целей Mozilla встала в позу и излагает позицию «только через мой труп», что выглядит очень плохо с их стороны. Вот два бага по подержке WebP в Firefox. Первому багу уже 5 лет, они его закрыли, чтобы люди не читали неудобные для Mozilla комметарии, и ограничили комментирование во второй. Просьба всем сочувствующим поддержке WebP пинать Mozilla по другим каналам.
[1] bugzilla.mozilla.org/show_bug.cgi?id=600919
[2] bugzilla.mozilla.org/show_bug.cgi?id=856375
P.S. Напомню, что из-за этой глупой позиции Mozilla некоторые крупные сайты были вынуждены добавить поддержку анимации в виде коротких MP4 и WebM роликов.
[1] bugzilla.mozilla.org/show_bug.cgi?id=600919
[2] bugzilla.mozilla.org/show_bug.cgi?id=856375
P.S. Напомню, что из-за этой глупой позиции Mozilla некоторые крупные сайты были вынуждены добавить поддержку анимации в виде коротких MP4 и WebM роликов.
А я напомню про странную позицию Google. Почему они не поддержит APNG? Который, к тому же, имеет отличный fallback в виде статичной картинки в браузерах без поддержки этого формата. Причём, судя по этому тесту, APNG часто справляется с задачей лучше, чем анимированный WebP.
Разработчиков Chromium с 2008 года просят об этом, то есть уже 7 лет как. Но эти 5 лет назад закрыли обсуждение этого бага. Энтузиасты даже предлагали готовые рабочие патчи. Поскольку это лишь небольшое обновление поддержки уже существующего формата, лишнего кода это добавляло немного.
Разработчиков Chromium с 2008 года просят об этом, то есть уже 7 лет как. Но эти 5 лет назад закрыли обсуждение этого бага. Энтузиасты даже предлагали готовые рабочие патчи. Поскольку это лишь небольшое обновление поддержки уже существующего формата, лишнего кода это добавляло немного.
Кстати вот, Max Stepin совсем недавно в очередной раз актуализировал свой патч под текущий код движка. Как видите, изменений в коде не очень много. Разработчики Chromium пока что не реагируют.
Складывается впечатление, что там имеют место быть какие-то детские обиды. Поддержка APNG незначительно увеличивает существующий код, зато элегантно решает существующую проблему. Почему Google с 2008 года игнорирует его — не ясно. Даже Apple сдалась и APNG поддерживается в Safari, ну и в Webkit тоже. Было бы хорошо, чтобы Google поддержала APNG, а Mozilla в ответ — WebP. Тут дополнительного кода, конечно, будет на порядок больше, ибо это совершенно отдельный формат, но часть нужного кода в Firefox уже имеется, ведь WebP имеет много общего с WebM/VP8.
Складывается впечатление, что там имеют место быть какие-то детские обиды. Поддержка APNG незначительно увеличивает существующий код, зато элегантно решает существующую проблему. Почему Google с 2008 года игнорирует его — не ясно. Даже Apple сдалась и APNG поддерживается в Safari, ну и в Webkit тоже. Было бы хорошо, чтобы Google поддержала APNG, а Mozilla в ответ — WebP. Тут дополнительного кода, конечно, будет на порядок больше, ибо это совершенно отдельный формат, но часть нужного кода в Firefox уже имеется, ведь WebP имеет много общего с WebM/VP8.
Думаю, не всё так просто как кажется.
Анимация в виде MP4 ролика — что в это плохого? А кодек так какой?)
Анимация в виде MP4 ролика — что в это плохого? А кодек так какой?)
Таки да, h264 или VP8 справятся с короткими видео лучше, чем WebP или APNG. И здесь тоже победителем вышел h264. Сама Google этому способствовала.
Проследите сами:
— Январь 2011, Google обещает удалить поддержку h264 в Chromium.
— Mozilla последовательно игнорирует существование h264 в пользу свободных форматов и ждёт обещанного от Google. Но Google и не думает совершать обещанное.
— В результате Mozilla вынуждена также поддержать h264, что и сделала спустя 2 года, в 2013 году.
Итого WebM/VP8 проиграл, а MP4/h264 выиграл, поскольку именно последний поддерживается всеми. И мне совершенно не ясно, зачем Google было устраивать всю эту показуху с WebM/VP8, тратить на это столько денег, если они сами не были настроены на его решительное продвижение.
Проследите сами:
— Январь 2011, Google обещает удалить поддержку h264 в Chromium.
— Mozilla последовательно игнорирует существование h264 в пользу свободных форматов и ждёт обещанного от Google. Но Google и не думает совершать обещанное.
— В результате Mozilla вынуждена также поддержать h264, что и сделала спустя 2 года, в 2013 году.
Итого WebM/VP8 проиграл, а MP4/h264 выиграл, поскольку именно последний поддерживается всеми. И мне совершенно не ясно, зачем Google было устраивать всю эту показуху с WebM/VP8, тратить на это столько денег, если они сами не были настроены на его решительное продвижение.
Sign up to leave a comment.
Оптимизируем графику с помощью WebP