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

[sitecreator]

1 час назад, yastman сказал:

импортирую фото с помощью определенного модуля с помощью yml ссылки.

 

я так и предполагал.

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

Наблюдаю уже больше года.

 

Проблему надо решать по-хорошему на стороне этого стороннего модуля импорта.

Я в своем модуле не могу менять расширение файла, но могу сделать для него правильный тип (mime-type),  что, собственно и делает модуль.

Т.е. он делает из неправильного PNG правильный PNG в кеше.

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

 

Сменить то расширение на jpeg, например, нельзя, т.к. название файла (хоть и с неправильным расширением) прописано в БД во множестве мест.

Поэтому я могу лишь привести в соответствие расширение и внутренний тип.

 

Это вынужденное увеличение веса потом компенсируется форматом WEBP.

Но все же получается пустая трата ресурсов на голом месте.

Сначала мы вынужденно превращаем JPEG в PNG огромного размера (а он всегда в несколько раз больше JPEG ).

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

 

И далее идет уже превращение PNG в WEBP,  что тоже работает существенно медленнее чем JPEG -> WEBP.

Т.е. видите, как на пустом месте вы нагружаете сервер дурной работой?

А потом говорят, что модуль тормозит сайт?

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

 

 

 

Просто иллюстрация как зависит время создания WEBP от формата и уровня оптимизации:

 

 

Для PNG стоит защита "от дурака", 6-й уровень я не разрешаю включать для него.  Всегда 4-й стоит, не более.

 

[sitecreator]

@yastman , пожалуйста, не цитируйте пост целиком. Читать проблематично когда идет повтор большого поста. Цитируйте нужное предложение.

[sitecreator]

 

Модуль Компрессор в. 1.12.10 переварил нормально битый PNG и превратил его в такой же "недоделанный" WEBP.   У меня ошибки при этом не возникло.

Но тут уже возникают нюансы на стороне конечного движка, который создает WEBP.

движок cwebp (под Windows) нормально переварил этот глюкнутый исходный (для создания WEBP) файл.

А вот движок imagick (для WEBP) не смог это сделать и вывалился с ошибкой.

Аналогично и GD не справился с битым входным файлом.

 

[sitecreator]

Подумал, а не сделать ли учет битых и "кривых" изображений?

Т.е. записывать информацию о них в БД чтобы потом заказчик мог просмотреть ее в админке и принять меры к исправлению.

 

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

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

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

 

Поэтому в случае битых файлов чтобы не генерировать постоянных ошибок и не пытаться многократно из битого сделать нормальный, файл (webp ) будет помечен как битый и дальнейшие попытки сделать из него нормальный webp будут прекращены.

 

Остановился на таком (проверенном в более ранних версиях модуля в похожих ситуациях) варианте для битых файлов.

 

 

 

[yastman]

2 часа назад, sitecreator сказал:

Подумал, а не сделать ли учет битых и "кривых" изображений?

Вообще идея крутая,когда тысячу товаров это очень полезно.

 

2 часа назад, sitecreator сказал:

Остановился на таком (проверенном в более ранних версиях модуля в похожих ситуациях) варианте для битых файлов.

Как включить данный функционал в вашем модуле?

[splka]

3 часа назад, sitecreator сказал:

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

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

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

 

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

[sitecreator]

5 часов назад, sitecreator сказал:

 

 

Я понял почему в моем случае webp получился "удачно" из битого PNG.

Я использовал cwebp для Linux 3.10.

В нем свежие библиотеки png, jpeg, которые умеют даже битые файлы перерабатывать.

 

А у вас сервер старенький Linux 2.6,  поэтому установленный cwebp (под старый Linux) не может переварить битый файл. И вообще не в состоянии записать файл.

 

Кстати, GD и imagick тоже не могут записать WEBP. Но для них я уже сделал решение, которое позволяет избежать проблем с производительностью из-за этого.

 

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

Это вам не на php писать, где все предсказуемо.

А тут даже cwebp одной версии, но под разные Linux, работает в случае исключительных ситуаций по-разному.

 

Просто для cwebp 1.0.2 под Linux 2.6 используется библиотека libpng 6-й версии.  Она и не умеет с битыми обходиться.

А той же версии cwebp 1.0.2 под Linux 3.1 использует библиотеку libpng 8-й или 9-й версии.  Вот тут и получается обходить проблему с битыми картинками более успешно.

 

Сейчас придумаю решение.

Хорошо когда все идеально. Написал короткий код строчек на 200, и все работает.  Но как только встречаются реальные проблемные изображения, то код уже разрастается на 1000 -2000 строк.

 

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

[sitecreator]

 

 

 

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

Модуль восстановит JPEG, PNG, а после сделает WEBP.

 

Было вот так:

 

 

А стало так:

 

 

 

 

 

Модуль информирует о своей попытке:

 

 

 

 

Данная возможность восстановления битых изображений доступна в версии модуля 1.12.11.

Для ее корректной работы нужно на время отключить кешер (ускоритель).

[sitecreator]

 

 

Добавил возможность сканирования всех изображений JPEG, PNG в кеше.

Если будут найдены битые, то они будут созданы заново. Соответственно WEBP также будет создан заново.

 

Называется режим:

Цитата

Форсированный режим восстановления битых изображений в кеше.
Нагружает сервер! Может замедлиться отдача страницы.

 

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

Тест показывает, что сканирование 300 - 500 изображений размером 450х650 (на одной странице HTML) привело к увеличению времени отдачи страницы примерно на 1 сек. Но изображений очень много для одной страницы!

Такая страница сформировалась в пределах 1.2- 1.8мс,  это вместе со временем сканирования на битость.

Вывод всех изображений в формате WEBP.

 

Это 100 товаров на страницу. У каждого товара от 3 до 6 изображений сразу на одной странице HTML.

 

Время сканирования изображений может занимать от десятков миллисекунд до сотен, т.е. грубо говоря 0.05 - 2 сек.  На слабом сервере, возможно, что больше.

данный сканер (форсированный режим восстановления) следует рассматривать как профилактическое средство и средство для лечения.

На постоянной основе нет смысла его держать включенным.

 

 

Для постоянной основы годится это:

 

Цитата

Пытаться восстановить битые изображения JPEG, PNG в кеше изображений.

 

Это никак не приводит к лишней нагрузке.

 

 

Данная возможность восстановления битых изображений доступна в версии модуля 1.12.12.

Для ее корректной работы нужно на время отключить кешер (ускоритель) или несколько раз очистить кеш ускорителя или дождаться когда он сам автоматически очистится (если такая возможность есть).

Если битые изображения исправлены, т.е. визуально вы это видите, то можете снова включит ускоритель (если отключали).

 

 

 

[sitecreator]

На странице 100 товаров. у каждого товара 3-6 изображений.

Скорость отдачи страницы в пределах 200-250 мс.

 

WEBP Lazy Load существенно снизил вес изображений.

Заодно просканировали автоматически и исправили битые изображения.

 

 

[sitecreator]

 

Новая версия 1.12.12

Доступна для скачивания на сайте разработчика.

[sitecreator]

Новая версия 1.14.0

Доступна для скачивания на сайте разработчика.

 

В этой версии много важных изменений.

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

Существенно увеличена производительность работы модуля.

 

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

Кроме того устранены ошибки, которые есть в штатных средствах (в движке "из коробки") по работе с изображениями.

 

Появилось средство для отладки изображений.

 

Вы можете измерять общее время, которое потрачено на вывод / генерацию (работает model tool resize).

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

 

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

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

И узнать общее время, потраченное на изображения.

 

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

далее изображения уже быстро отдаются из кеша.

 

 

Отладочную информацию можно выводить прямо на страницу (и она будет видна всем), либо ее можно увидеть только в исходном тексте HTML.

 

 

 

 

 

 

 

 

 

 

 

 

[sitecreator]

Новая версия 1.14.0

Доступна для скачивания на сайте разработчика.

 

На предыдущие версии устанавливается поверх через установщик ocmod.

после установки обновите кеш модификаторов (ocmod) и системный кеш.

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

[sitecreator]

Для тех, кто не знает или еще не оценил.

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

Одновременно выполняем рекомендацию Гугла:

 

Цитата

Настройте подходящий размер изображений

 

 

 

 

 

 

 

[sitecreator]

Просьба обновиться до 1.14.* версии всем, кто этого не сделал.

 

 

В первых (бета) версиях модуля, которые поддерживают webp lazy load, данный механизм не учитывал возможные последующие изменения DOM (подгрузка контента и т.п.).

Этот момент уже давно решен, как минимум, несколько недель прошло (или пара месяцев уже?).

 

Все ваши пожелания и замечания учитываются, в новых версиях оперативно фиксятся баги и применяются более совершенные алгоритмы, в том числе и новый алгоритм webp lazy load.

 

Мною с нуля написан весь функционал (включая JS) webp lazy load, и направлен он на максимальное быстродействие.

Никакие сторонние библиотеки не используются, весть код JS является результатом разработки автора @sitecreator (sitecreator.ru)

 

[sitecreator]

Может быть у меня глаз замылился?

Я не вижу разницы в качестве изображений при смене формата с JPEG на WEBP.

Заказчик уверяет, что качество ухудшилось и он это видит.

 

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

 

[Atlet]

Сама придумала... Сама обиделась))

[Vorodisa]

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

[sitecreator]

Новая версия доступна для скачивания.

1.14.1

 

Учтены особенности быстрых страниц от Гугла

( https://support.google.com/webmasters/answer/6340290?hl=ru )

и, соответственно, специфические требования к ним.

 

В этой версии на всякий случай отключен lazy load для страниц

index.php?route=checkout/...

и подобных (simplecheckout и т.д)

 

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

 

Также улучшена работа с изображениями при наличии только php GD (в отсутствии imagick).

Улучшения касаются обработки неправильных изображений когда внутри JPEG находится PNG.

Это позволяет избежать ситуации появления черного фона если в таком неправильном JPEG был альфа-канал (прозрачный фон).

[SunnRi]

18 часов назад, sitecreator сказал:

Может быть у меня глаз замылился?

Я не вижу разницы в качестве изображений при смене формата с JPEG на WEBP.

Заказчик уверяет, что качество ухудшилось и он это видит.

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


У меня например ювелирная тематика, и к примеру, если выставить сжатие на 80%, то к сожалению, всякие мелкие детальки выглядят хуже, к сожалению

Змінено 22 червня 2019 користувачем SunnRi

[sitecreator]

1 час назад, SunnRi сказал:

У меня например ювелирная тематика, и к примеру, если выставить сжатие на 80%, то к сожалению, всякие мелкие детальки выглядят хуже, к сожалению

 

Работал совместно с фотографами, которые делают фотесессии для магазинов. Уж они то знают толк в мелких деталях.

Пришли к общему мнению, что если важны мелкие детали и максимальная четкость, то оптимальный уровень качества лежит в пределах 85-87 (imagick и webp).

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

Но а выше 90 ставить практически нет смысла. речь про JPEG (imagick) + webp.

GD при том же уровне качества делает свою работу несколько хуже чем imagick.

Вообще imagick делает любую работу лучше чем GD, поэтому всегда стоит включать imagick.

 

Имеет смысл выставлять уровень качества в пределах 80-90.

И если нет мелких деталей, то ближе к 80, и наоборот.

[RaVIOLy]

7 минут назад, sitecreator сказал:

Имеет смысл выставлять уровень качества в пределах 80-90.

Напоминалка)

 

[sitecreator]

Уточнение по поводу админ-бара для модуля Компрессор.

Включайте (на вкладке "Сервис") только на время тестов и полностью отключайте после чтобы исключить возможную ненужную нагрузку.

 

 

 

Пользуйтесь в режиме отключенного WEBP. Админ-бар делался давно, а потому с webp не умеет работать.

Но это нисколько не мешает работе, поскольку webp - это всего лишь копия в другом формате ваших JPEG, PNG изображений.

Можете не отключать режим webp для работы админ-бара, но тогда работайте в каком-либо браузере, который не понимает webp, например, Microsoft Edge или в старом FireFox (до 64 включительно).

 

Сегодня/завтра будет версия модуля 1.14.2.

Сделаны мелкие фиксы и кое-что добавлено.

 

[sitecreator]

Новая версия доступна для скачивания.

1.14.2

[neopl]

16 часов назад, sitecreator сказал:

Новая версия доступна для скачивания.

1.14.2

после установки HTTP ERROR 500 на двух сайтах из трех