Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

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


 Поделиться

Рекомендованные сообщения

Всем привет!

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

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

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

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

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

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

 

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

Спасибо, 

MouseFlo.

Ссылка на комментарий
Поделиться на других сайтах


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

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

 

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

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

 

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

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

 

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

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

  • +1 2
Ссылка на комментарий
Поделиться на других сайтах

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

 

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

хоть

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

хоть

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

Ссылка на комментарий
Поделиться на других сайтах


  • 1 год спустя...

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

Изменено пользователем 20strannik08
Ссылка на комментарий
Поделиться на других сайтах


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

Ссылка на комментарий
Поделиться на других сайтах



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

 

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

Ссылка на комментарий
Поделиться на других сайтах

@Otvet,

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

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

 

 

Ссылка на комментарий
Поделиться на других сайтах

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

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

 

 

которая весьма сильно увелечивает размер картинки
Ссылка на комментарий
Поделиться на других сайтах

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


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


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

непонятно?

 

 

http://prntscr.com/dr0rsd

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

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

 

например на

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

 

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

 

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

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах


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

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

Ссылка на комментарий
Поделиться на других сайтах

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

 

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

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

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

 

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

  • +1 1
Ссылка на комментарий
Поделиться на других сайтах

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

 

при выборе 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));

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

Ссылка на комментарий
Поделиться на других сайтах


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

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

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

Ссылка на комментарий
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Поделиться

  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.