Модуль Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator [Поддержка]

[sitecreator]

Реальная работа по созданию webp в режиме cron.

Равномерно, без тормозов для страниц сайта, без всплесков нагрузки на процессор и память.

более 15000 изображений обработано с равномерной нагрузкой за 2 дня.

 

Видно, что суммарный вес всех WEBP изображений уменьшился в 2.5 раза по сравнению с первоначальным, и составляет 39%  от первоначальных 100%.

 

[alinalessioYandex]

Скажите пожалуйста, почему появляется эта ошибка?

Notice: getimagesize(): Read error! in /var/www/pfdecor.ru/data/www/pfdecor.ru/catalog/model/tool/image_sitecreator.php on line 527

Раньше всё работало, но после следующих действий, на некоторых страницах появляется эта ошибка.

Вот после чего полезли ошибки:

1. В модуле Batch Editor https://opencartforum.com/files/file/301-batch-editor-paketnoe-redaktirovanie-tovarov/ через сео генератор переименовал картинки.

2. Полезла куча ошибок

3. Удалил папку image

4. Восстановил папку image до состояния перед манипуляций с Batch Editor

5. Восстановил базу данных до состояния перед манипуляций с Batch Editor

 

Теперь после восстановления из резервных копий, вылетает эта ошибка https://pfdecor.ru

 

Что делал, чтобы избавиться от ошибки:

1. Обновлял все кеши

2. Заново давал все права группе админов

3. Заново устанавливал из админки модуль Image COMPRESSOR, заново давал права и заново удалял кеши

4. Папке image и всем подпапкам и файлам дал права 777

 

Кроме этого не работает водяной знак. Тест водяного знака тоже не работает.

 

Змінено 18 квітня 2021 користувачем alinalessioYandex

[sitecreator]

17 минут назад, alinalessioYandex сказал:

эта ошибка.

 

невозможно прочитать файл.

означает именно то, что написано.

 

Цитата

Read error!

 

Как правило, это битый исходный файл или битый закешированный jpeg/png.

 

Самая частая причина - это когда закончилось свободное место на диске сервера, а пользователь этого не заметил.

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

Не стоит забывать, что у некоторых хостеров есть ограничение на количество файлов, ограничение на ресурсы процессора и т.д. Когда хостер резко ограничивает эти ресурсы, то происходит нестабильная работа вашего аккаунта хостера.

Разумеется, что могут быть и иные причины.  Практически всегда эти причины находятся за пределами модуля Компрессор.

Это не ошибка самого модуля, это ошибка ваших файлов.

 

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

 

 

 

 

 

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

 

 

 

Предлагаю вам написать мне  в личку. Т.к. проблема у вас частная.

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

[sitecreator]

Статистика по реальном у сайту.

Выигрыш в применении WEBP 9-ти кратный. Это связано с тем, что на сайте очень много картинок в формате PNG-24 с альфа-каналом (прозрачностью).   В этом случае WEBP дает очень хорошее преимущество без потери качества изображения.

 

Статистика на основе обработки более 19 000 изображений,  переработано более 1Гиг изображений, на выходе они превратились в 120 М.

И это все без тормозов страниц, с совершенно равномерной нагрузкой сервера за 2...3 дня.

 

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

Тут главное - равномерность загрузки.

 

 

[sitecreator]

Черная пятница. 

закончилась

[sitecreator]

Черная пятница. 

закончилась

[DmitriySPb]

opencartforum. com/files/file/4572-image-compressor-watermark-webp-lazy-load-etc-by-sitecreator/

 

 

Змінено 26 квітня 2021 користувачем DmitriySPb

[sitecreator]

@DmitriySPb , будет позже.

 

[sitecreator]

Версия 3.0.2

Обновление кода

 

Принципиальных новшеств в этой версии нет. Но упрощен интерфейс управления, т.е. админка модуля.

Для тех, кто не любит много настроек, их количество уменьшилось.

 

Поскольку в 99% случаев формат webp покрывает потребности в использовании сжатого формата, то оставлен именно этот сжатый формат.

Тем более, что webp формат в модуле Компрессор работает практически у любого хостинг-провайдера,  можно сказать, что в 99.9% случаев.

От mozjpeg, optipng в этой версии отказался.  Благодаря этому настройки стали несколько проще.

 

Если же вам нужны mozjpeg, optipng, то вы можете не обновляться, а использовать предыдущие версии вплоть до 2.3.1

 

Напоминаю, что в версии 2.3.1 и 3.0.2  есть новые возможности для оптимизации изображений.

Максимально корректно, с сохранением вашей верстки и без поломок вроде сплющивания или растяжения изображений.

Речь про это:

 

Цитата

Для изображений не заданы явным образом атрибуты width и height.

 

 

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

 

 

 

 

 

 

 

 

 

 

 

[sitecreator]

 

 

 

 

Хорошей альтернативой настройкам выставления явных размеров и нативному lazy load  может быть использование lazy load JS совместно с изображениями, специально созданными для небольших экранов смартфонов.  Т.е. смартфонам отдаются более легкие по весу изображения чем для ПК.

 

На практике нужно просто смотреть, что работает лучше в конкретной ситуации.  особенно в случае баннеров на 2500 * 1000 (4000 * 2000 и т.п.).

[sitecreator]

Чр. пт.

закончилась

[sitecreator]

Чр. пт.

закончилась

[Kazumi]

On 8/26/2017 at 7:47 AM, sitecreator said:

Внимательно смотрите, что пишет гугл!

Он предлагает сначала изменить геометрические размеры изображения и лишь потом его сжимать.

 

Браузер загружает большую картинку, потом масштабирует ее и показывает вам уже ее как маленькую.

Вот это и не нравится гуглу.

К сжатию это отношения не имеет.

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

[sitecreator]

7 часов назад, Kazumi сказал:

так получается бразуер все равно загружает большую картинку?

 

думаю, что вы не поняли.

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

А если бы еще и геометрию поправили, то была бы еще меньше.

 

Т.е. меньше будет в любом случае.

 

7 часов назад, Kazumi сказал:

В чем тогда смысл всего, если изначальная цель меньше трафика сгружать браузеру?

 

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

 

И то, что вы выше процитировали меня,  это относится к верстке, причем, к не очень удачной верстке.

В чем смысл спрашиваете?  В том чтобы стараться делать верстку более правильной.

Только какое это имеет отношение к модулю Компрессор и сжатым форматам напрямую?

Никакого.

 

Вы вырвали из контекста обсуждение верстки.

Иногда, например, загружают логотип размером 2000 х 1000,   в то время как он никогда не отображается больше чем 200 х 100.

Спрашивается, а почему  так делают?  По незнанию и отсутствию должной квалификации.

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

 

Модуль Компрессор умеет поправлять геометрические размеры изображений насколько это возможно и создавать для смартфонов более оптимальные изображения с меньшим весом. В итоге все грузится быстрее.

 

[sitecreator]

@Kazumi , кстати, в процитированном вами куске есть ключевое пояснение:

 

Цитата

Внимательно смотрите, что пишет гугл!

Он предлагает сначала изменить геометрические размеры изображения и лишь потом его сжимать.

 

Браузер загружает большую картинку, потом масштабирует ее и показывает вам уже ее как маленькую.

Вот это и не нравится гуглу.

К сжатию это отношения не имеет.

 

Это вопросы относятся к верстке и выбору разумных геометрических размеров для изображений.

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

[Kazumi]

А модуль случайно не чистит от неиспользуемых изображений? Не пойму где эту функцию видел

[sitecreator]

@Kazumi , от неиспользуемых не чистит.

[korabel]

@sitecreator посмотрите Личку пожалуйста

[sitecreator]

версия 3.1.0

 

Для разных версий opencart  улучшена обработка файлов изображений, содержащих в названиях кириллицу, пробелы и т.п. нерекомендуемые символы.

 

URL для таких файлов формируются согласно стандарту, т.е. кодируются, и являются валидными.

 

 

-------------------------------------------

RFC3986. Согласно стандарту кроме латинских букв и цифр могут быть еще только следующие знаки в названии файла, передаваемом в URL :

 

Цитата

- _ . ~

 

Все остальные символы URL (вроде той же кириллицы, арабской вязи и т.д. и т.п.) в названии файла (папки) должны быть обязательно закодированы.

--------------------------------------------

 

 

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

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

[sitecreator]

версия 3.1.1

 

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

[sitecreator]

тут были скидки...

акция закончилась.

 

 

[sitecreator]

 

 

 

 

В графической библиотеке php GD (в некоторых версиях и сборках PHP)  есть очень распространенная проблема - это невозможность работы с альфа-каналом. Происходит замена фона на черный при конвертации в WEBP из PNG.

 

Эту проблему умеет решать Компрессор.  Он не может решить ее на 100% с работающим альфа-каналом, но может задавать белый фон, это намного лучше чем получение черного фона.

Для этого используйте настройки:

 

 

 

Остальные проблемы, которые возникают из-за GD, а они есть почти в любой версии этой библиотеки когда речь идет о работе с WEBP,  модуль Компрессор решает довольно эффективно и полностью автоматически.

 

Используйте GD только в том случае когда нет никакой альтернативы для генерации WEBP. 

А они почти всегда есть.

GD - самая глючная библиотека для работы с webp.

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

 

Тест cwebp выглядит так:

 

 

 

Как видите, никакого черного фона не возникает при прохождении теста создания WEBP.

[sitecreator]

новая версия 3.2.0

 

[petr34]

В 13.05.2021 в 00:54, sitecreator сказал:

тут были скидки...

акция закончилась.

 

 

 

Здравствуйте, есть несколько вопросов

 

1. Скидки еще планируются? Приобрел бы модуль. 

2. По вашему мнению какой формат дает лучшее качество при минимальном весе?

Я так понимаю что Оригинальный огромный PNG без сжатия -> переведенный в Webp всегда будет лучше такого же огромного JPG -> переведенного в тотже Webp? Лучше по соотношению качества и веса. Вопрос возник в связи споров с заказчиком что наполнять магазин лучше оригиналами PNG для дальнейшего перевода в webp.

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

[sitecreator]

50 минут назад, petr34 сказал:

1. Скидки еще планируются? Приобрел бы модуль. 

 

Здравствуйте.

Скидки периодически возникают, но без каких-то регулярных правил.

временами просто раздаю по запросу скидочные купоны. Обычно достаточно написать на мою почту или в личку.

 

50 минут назад, petr34 сказал:

Я так понимаю что Оригинальный огромный PNG без сжатия -> переведенный в Webp всегда будет лучше такого же огромного JPG -> переведенного в тотже Webp? Лучше по соотношению качества и веса.

 

 

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

иначе нет смысла, т.к. PNG будет раз в 5 тяжелее JPEG при незаметном на глаз различие в качестве.

 

PNG можно переводить в webp как с потерями, так и без потерь. В любом случае webp будет меньше по весу, даже если преобразовывать как lossless.

 

50 минут назад, petr34 сказал:

наполнять магазин лучше оригиналами PNG для дальнейшего перевода в webp.

 

Зависит от самих изображений.  в 99% случаев оптимальным будет именно JPEG. И только в редких случаях - PNG.

PNG хорош для баннеров где много мелкого текста, так текст остается максимально четким.

 

50 минут назад, petr34 сказал:

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

 

правильно понимаете. Т.к. идет борьба именно за скорость работы страниц сайта. А тут все методы хороши, вплоть до перехода на VDS и сервер.

Но есть еще технология mozjpeg, которая именно сжимает сам JPEG.  Можно воспользоваться ею как альтернативой вместо webp, только работает mozjpeg с бОльшим потреблением ресурсов чем webp. Как говорится, за все нужно платить.