Оптимизация картинок в image/cache

[mouseflo5]

Всем привет!

Подскажите, кто-нибудь решал вопрос с оптимизацией картинок, которые создаются автоматически в /image/cache?

Мои оригинальные картинки оптимизированы, сжаты, но т.к. OpenCart создает свои картинки, то в

https://developers.google.com/speed/pagespeed/insights/

получаю низкие значения именно из-за картинок. 

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

Тем не менее хочется чтобы создавались в /image/cache такие картинки, на которые не будет ругатся Google pagespeed...

 

Подскажите куда копать или может кто решил уже?

Спасибо, 

MouseFlo.

[mouseflo5]

nikifalex, если Вы про параметр $quality то это не помогло.

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

[mouseflo5]

nikifalex, мне важно получить зеленую зону в google pagespeed (желание заказчика), а из-за картинок никак.

Касательно скорости - то я имею в виду скорость первой загрузки определенной страницы, когда будут создаваться оптимизированные thumbnails и кластся в /image/cache, повлияет ли сильно добавление такого кода на скорость первой загрузки. 

[Otvet]

https://github.com/psliwa/image-optimizer

[alexstorm]

Я перед тем, как загонять картинки на проект, все их прогоняю через https://tinypng.com/

Вес большинства картинок уменьшается в 2 раза.

 

Потом уже в самом кеше они весят копейки за счет второго сжатия при $quality = 100%.

 

Пережимать image/cache не вижу в этом логики.

[AlexDW]

1) зависимость картинок от получения зеленого результата в pagespeed - сродни сферическому коню в вакууме

- бесполезно сжимать изображение весом в 1,5 кб чтобы получить выигрыш в 1,6% :ugeek:

 

но, конечно, если у вас в качестве фона грузится изображение в 1,5Мб - это полный абзац

для информации

 

2) картинки - это меньшее из бед, если ваш сайт не в зеленой зоне - ищите причину в другом, а не в них

начните с проверки наличия кеширования на стороне клиента и дальше по нарастающей

 

и самое главное: google pageespeed - сервис рекомендаций, а не последняя инстанция

его советы могут быть полезны, но в силу унификаций - не всегда адекватны (см про коня :-D )

[mouseflo5]

AlexDW, нет, кеширование, сжатие и т.д. - это уже все сделано, эти проблемы ушли. Остались картинки. Я скачала картинки, которые выдает сам google как рекомендуемые, залила в кэш - и получила зеленую зону.  Т.е. если решится вопрос с картинками - будет таки зеленая зона. Советы pagespeed может не адекватны, но заказчику так хочется. 

 

alexstorm, да, оригинальные картинки адекватного размера, прогнаны спец.утилиткой imageoptimizer, проверены, на оригинальные картинки гугл не ругается. ругается именно на /image/cache, будь там 

хоть

public function save($file, $quality = 90)

хоть

public function save($file, $quality = 50)

[20strannik08]

Мне вот действительно интересно почему все так пофигистически к этому моменту относятся и никто не может дать дельный совет. Гугл не рекомендует сжимать картинки с потерей качества. Он рекомендует сохранять картинки без "постороннего мусора" который в этих картинках содержится и ни как на качество не влияет. К такому мусору относится всякая техническая информация, и которая весьма сильно увелечивает размер картинки. И если эта рекомендация уменьшит общий вес на 100-130 кб то почему бы и нет? В скорости может это и не даст видимых ощущений. Однако если пользователь со скоростью интернета в 1 мегабит залезет на сайт, то при первом заходе для него скорость загрузки уменьшится на 1 секунду. Я молчу про мобильных операторов у которых скорость временами бывает и того хуже. Делайте сами выводы, но первые секунды всегда важны.

[Otvet]

@20strannik08, там нет никаких лишних "технических информаций", EXIF там не присутствует

а использование библиотек сжатия при создании эскизов замедлит не на секунду а может и на десятки, а хостер заблокирует за превышение нагрузки

[20strannik08]

Но эскиз же создается один раз! Потом результат лежит в кеше в виде картинки

 

ЗЫ. На счет хостинга - возможно, у меня vps, я бы поэксперементировал

Змінено 3 січня 2017 користувачем 20strannik08

[20strannik08]

По поводу exif - Речь не про него, там есть много разных нюансов, к примеру некоторые приложения редакторы  внутри картинки хранят информацию о том что ими была создана картинка. Разные параметры при сохранении и т.д. Все это вместе в совокупности, порой очень много данных в себе заключает.

[Otvet]

некоторые приложения редакторы  внутри картинки хранят информацию о том что ими была создана картинка

а exif в вашем понимании что?

 

и каким боком "техническая информация" попадает при создании эскиза через imagecopyresampled ?

[chukcha]

@Otvet,

Ну.. даже в сжатом может храниться

CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 90

 

 

[Otvet]

@chukcha, это уже библиотека php приписывает свои 56 байт

однако все метки исходника обрезаются

 

 

которая весьма сильно увелечивает размер картинки

[AlexDW]

CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 90

и как, сильно эти данные увеличивают размер файла? на фоне общего размера 50-100кб исходника, в среднем? :lol:

 

если машина не едет - нужно ее смотреть и чинить, а не фары натирать

[chukcha]

Ну, когда я вижу что размер вашего файла составляет 800 байт и сжать можно до 600 мне смешно, но все же..

[20strannik08]

Речь не только про эти данные. Там много нюансов в совокупности. Вот яркий пример - размер фотографии в карточке товара 860х860 пикселей. Картинка в формате png. После сохранения в гимпе размер 155кб(860х860). Прогнав через онлайн сервис оптимизации картинки, рамер изображения 55кб. Залил фотку. Не знаю что с этим фото делал оксторе но она стала весить 252,88!!! Это вы называете "фары натирать"? Я считаю это проблемой.

 

С jpg не так все печально но при том же уровне сжатия, выходная картинка больше размером в ocstore\opencart. У меня картинки в карточке товара по 860х860 пикселей, и эта разница хоть и не сильно но все же значительна. Попробуйте сами проверить.

[Otvet]

@20strannik08, что в написанном

а использование библиотек сжатия при создании эскизов замедлит не на секунду а может и на десятки, а хостер заблокирует за превышение нагрузки

непонятно?

 

 

http://prntscr.com/dr0rsd

это 1 файл на современном 4 ядерном 3.8ГГц процессоре

а если на странице 30-40 картинок?

[AlexDW]

так настройте сжатие png под себя в system\library\image.php

 

замените строку

imagepng($this->image, $file);

 

например на

imagepng($this->image, $file, 5);

 

экспериментируйте

 

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

[chukcha]

Не знаю что с этим фото делал оксторе

Жалуйтесь на gdi , а не opencart || ocStore

[Yoda]

Жалуйтесь на gdi , а не opencart || ocStore

 

Есть у меня личное наблюдение. 

Что GD, что Imagick намного лучше обрабатывают изображения, которые были подготовлены в фотошопе и сохранены как "сохранить для веб-устройств".

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

 

Т.е. по факту ставишь Imagick - та же фигня что и с GD, пересохраняешь картинки и  о боги, googlepagespeed говорит НРАИЦА.

[chukcha]

ну.. никто не говорит об офлайновом сжатии, можно, конечно, что-то придумать. типа использовать сторонние сервисы, делать предподготовку,

Стоит ли овчинка?

[Otvet]

http://prntscr.com/dr20k5

[chukcha]

Вот задался вопросом а можно удалить комменты?

 

при выборе gd - нельзя

sprintf(comment, "CREATOR: gd-jpeg v%s (using IJG JPEG v%d),", GD_JPEG_VERSION, JPEG_LIB_VERSION);

	if(quality >= 0) {
		sprintf (comment + strlen(comment), " quality = %d\n", quality);
	} else {
		strcat(comment + strlen(comment), " default quality\n");
	}

	jpeg_write_marker(&cinfo, JPEG_COM, (unsigned char *) comment, (unsigned int)strlen(comment));

Т.е. хотим или не хотим, но там это будет всегда

[Otvet]

намного лучше обрабатывают изображения, которые были подготовлены

проверил на демо картинках

исходники сжались на процентов 30, однако итог тот же

может касается png? там играет роль кол-во цветов