Компрессия картинок на вашем сайте. Как реализовать?

Question

[Григорий Васильков]

Вот Гугловский аналитик как-то определяет, что изображение не имеет сжатия. И говорит, что это нужно сделать обязательно.

1) он однозначно выделяет фотки которые больше контейнера
Якобы нужно чтобы контейнер 200-200 и фотка там такая же. Хотя думая о респонсивных страницах - там как раз фотка может изменяться на разных устройствах, вплоть до того, что использовать плавное изменение размера. И если стабильную картинку всунуть - то изменить размер фото при плавном увеличении размера вьюпорта уже не выйдет

2) он похоже показывает фотки, которые я перед публикацией не "сохранил для веб" и не прогнал через fast stone
где оно его как-то хитро сжимает, не изменяя качества. вот эта компрессия больше интересует

Собственно вопрос - а какой bestpractice работы с картинками?
Слышал там еще на айфонах беда есть, что вроде картинки подгружаются как мыло, если их сразу по размеру не разрезать

Answer 1

[Walt Disney]

1) Гугл JS-сом сравнивает реальный размер картинки и тот в котором он отображается.
2) Он обязательно вырезает мета информацию из файла картинки, она в некоторых случаях может быть больше больше самой картинки.
Потом для jpeg, где предусмотрен параметр сжатие/компрессия от 0 до 100, скорее всего ругается если он больше 70-75. Т.к. от 75 до 100 разницы обычно не видно, а размер заметно меньше. (100 это без сжатия)

Для png можно менять битность (8,16,24,32,48,64) изменить, если она используется не эффективно. Битность это количество битов используемое для кодирования одного пикселя от неё зависит количество доступных цветов и глубина альфаканала. Т.е. png8 это 256 цветов без альфы. Параметра компрессии у png нет.

Для GIF это от двух до 256 цветов в заказной палитре, чем меньше цветов палитре тем меньше файл.

Соответственно автоматическая оптимизация для PNG и GIF может быть только путём анализа цвета в каждом пикселе, на лету это муторно и ресурсоёмко. И соответственно этим почти никто не заморачивается.

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

Comments

[Григорий Васильков]

Огромное спасибо.

Так ведь если ПХП это делать то первый раз при кешировании сделал а потом загрузил копию из папки tmp? Вы делали такое?

[Walt Disney]

Григорий Васильков: не понял вопроса, что именно кешируем то?

[Григорий Васильков]

Ну если скрипт компресии jpg или смены качества png который отрабатывает не каждый раз, а только первый раз, без скачать-закачать. Как это делается?

[Walt Disney]

Григорий Васильков: в пхп через php.net/gd
если есть консоль и операция разовая, то через Image Magic.
удаляйте мету у всех, у jpeg проверяйте качество, с палитрами в гифах и битностью в пнг в вашем случае заморачиваться не нужно.

кешировать или нет решайте сами, исходные лучше хранить всегда.

[Григорий Васильков]

разумеется папка original никуда не убежит. просто будет как две капли воды одинаковая папка compressed в которой по размерам лежат кешированные фотки. и скриптом же запрашиваются каждый раз и не преобразовываются если уже есть. gd посмотрю. говорят даже imagick есть для пыхи.

вопрос в удалении мета инфы - а как это делается?
=
в смысле с png не заморачиваться? фастстон таки сжимает пнг процентов на 10-15 (качество может и ухудшается, я не замечал), это через пхп не сделать просто?

Answer 2

[Сергей]

Жмите все картинки сервисом kracken.io и ситуация значительно улучшиться.

Comments

[Григорий Васильков]

У меня проблема следующая: сайт на 4 гига весу. Скачивать все картинки, чтобы сжать - запросто. А назад закачать - та еще задача. Были ли у вас времена когда исходящая 50Кбит и не выше? Вот 4 гигабайта архив с картинками закачивается 23 часа. Причем часах на 20 что-то произойдет и все начинается заново. Всегда)

поэтому и думаю - как бы запустить утилитку на сервере, которая все в папке пережмет, даже если это займет 2 часа, и больше не думать об этом

Answer 3

[Иван]

Вангую, что для ноды есть приблуда, которую надо пинать gulp'ом например (ну или ручками).
А вообще если гугл чет говорит, то это не последняя инстанция.

Comments

[Григорий Васильков]

Спасибо за ответ. А можете пояснить как вы это видите?

Вот нашел я приблуды, чтобы изменить размер картинки по запросу - урл ставишь вида img_200x200.jpg и он работает.

С другой стороны - вот надо чтобы картинка плавно изменяла размер при изменении вьюпорта. тут уже обрезка ее перед выдачей в поток смысла не имеет. или правильным считается - таки обрезать, а потом менять не картинку а просто маргины, а для каждого вьюпорта (дискретно, штуки 3-4 определить) иметь собственную картинку и менять ее сразу например в 2 раза по размеру?

Что до гугла - гугл конечно не панацея.
Тут две ситуации:
1) заказчик очень боготворит гугл и переучивать его это вообще глупая затея
2) гугл все таки посещают половина людей планеты. поэтому если они скажут - ваш сайт должен встать на задние лапки - то он должен встать. благо они воспитали людей с доверием к себе. целое поколение.

[Григорий Васильков]

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

Написать сжатие - запросто. Инструменты для компресии - вот это беда