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

[sitecreator]

20 минут назад, 100napb сказал:

файлов в покупной теме несколько сотен.

 

а вот это уже необычно.

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

У нормального хостера с 100 шт. за 30 сек не было бы проблем.

 

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

во-первых , OpenVZ использовать для реальных задач нельзя НИКОГДА.   Эта технология уронит ваш VDS если у соседей будет повышенная нагрузка. И нет никакой гарантии, что вам будут обеспечены заявленные ресурсы. Это для "поиграться" лишь.

 

во-вторых, 512М - это актуально было бы для 10-ти летней давности. Это совсем мало.  И то, вам не гарантировано даже это (см. 1-й пункт).

В зоне RU хостеров, предлагающих такой минимум, днем с огнем не найти, ибо это неприлично.  Стартуют от 1Гиг.

 

[100napb]

20 minutes ago, sitecreator said:

 

а вот это уже необычно.

 

 

спасибо за ответ

ну так ведь и играюсь пока... тестирую. до сих пор хватало всего и без нареканий: банальные nginx + mysql + apache + postfix + opendkim + php c кучкой модулей тянет такой хостинг на ура и без проблем выдерживает апачевский тест типа "ab -c 500 -n 1000" без падений, хоть и не на большом количестве request\sec.

 

дополнительный вопрос: в настройках модуля отключена работа с png. а нагрузку создает именно она, да еще и с параметром оптимизации\сжатия o3. у меня в настройках не так. это норм?

[sitecreator]

@100napb , не надо включать Webp. Вы этим создаете лишнюю нагрузку.

нужно выбирать что-то одно: mozjpeg или Webp.

 

mozjpeg нужно выбирать, и при невозможности выбирать Webp.

 

[100napb]

спасибо еще раз. во всем разобрался, все работает как надо

модуль отличный!

[12strun]

9 минут назад, ibond сказал:

del

Срочно меняйте пароли и доступы. Они есть в почте у всех кто подписан на эту тему.
Тут-то вы уничтожили сообщение, но на почте у нас оно висит.

[ibond]

6 минут назад, 12strun сказал:

Срочно меняйте пароли и доступы. Они есть в почте у всех кто подписан на эту тему.
Тут-то вы уничтожили сообщение, но на почте у нас оно висит.

Та уже. Окошки одинаковые, не туда копипастнул.

[sitecreator]

Цена снижена до 990 руб.  Но совсем совсем ненадолго.

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

День скидок.

 

[sitecreator]

Наличие функции EXEC php НЕ является обязательным условием для обеспечения максимального сжатия.

Достаточно наличия proc_open

Как видите, тесты сжатия проходят успешно при отсутствии у хостера EXEC.

 

Вскоре и proc_open не будет нужна.  Т. е. работать будет на любой хост-площадке.

 

ниже результат с реальной хост-площадки. У хостера нет EXEC, да и не нужно...

 

 

Версия модуля 1.6.* не требует exec.

[sitecreator]

нужные функции у многих хостеров вы можете сами включать или отключать.

Пример того как это делается у хостера http://ukraine.com.ua

 

[sitecreator]

Немного полезного про WebP.

 

WebP - это компромиссный (запасной) вариант.  Если у вас работает mozjpeg, то WebP вам может быть и не нужен.

 

Если у вас работает mozjpeg, то нет особого смысла генерировать еще и WebP.  Есть резон выбирать что-то одно, а mozjpeg будет предпочтительнее WebP, т. к. работает в любом браузере и не требует модификации движка или конфига апачи (nginx).

 

Но WEbp может быть полезен если у вас много PNG изображений.  Преобразование их в WEBP может в разы снизить общий вес изображений.

 

Обычный хостинг должен соответствовать определенным условиям чтобы работал WebP. Проще всего режим WebP организовать на виртуальном хостинге если на нем только apache и есть хотя бы GD с поддержкой WebP, в этом случае не нужно менять код движка совсем.  Если же на обычном хостинге nginx+apache, то тут несколько сложнее,  т. к. нужно на некоторых хост-площадках вносить изменения в код движка.

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Часть хост-площадок  с nginx+apache позволяет легко выводить WebP в бразуер.  Покажу на примере http://ukraine.com.ua

Идете в "настройки сайта" и удаляете webp, png, jpg, jpeg jpg  из списка статики.

 

 

 

нужно добавить в файл .htaccess (который в корне сайта) сразу после строки

-----------------------
RewriteEngine On
-----------------------

следующие строки:

-----------------------
# Check if browser support WebP images
RewriteCond %{HTTP_ACCEPT} image/webp

# Check if WebP replacement image exists
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f

# Serve WebP image instead
RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]

<IfModule mod_headers.c>
Header append Vary Accept env=REDIRECT_accept
</IfModule>

AddType image/webp .webp

 

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

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

 

Если ваш хостер не предусмотрел настройку списка  статических файлов для NGINX, то есть еще решение.

Сделал сейчас универсальное решение (модификатор webp_by_sitecreator.ocmod.xml) для сайтов на виртуальном хостинге.  Для отдачи WebP в браузер, поскольку важно не только сгенерировать WebP , но и  показать его в браузере, при этом несовместимым и старым браузерам отдавать JPEG. Вот эту задачу и решает модификатор.

Пока сделал решение для самых нагруженных картинками страниц: КАТЕГОРИИ и ТОВАР.

Проверено на дефолтном шаблоне, а также проверено на (и массе других):

[sitecreator]

для тех, кто плохо читает инструкцию сделал намекающую подсказку.  Чтобы не было вопросов "а почему не работает?".

 

 

На этом месте должна быть картинка

 

 

если ее нет,   то выполните пункты этой подсказки.

[rassigor]

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

[sitecreator]

36 минут назад, rassigor сказал:

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

 

не может.

код модуля в этом случае не работает, т. к. нет необходимости.

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

[sitecreator]

Друзья,  сделаю одно пояснение по поводу эффективности сжатия методом mozjpeg.

А заодно отвечу на вопрос "почему после сжатия гугл продолжает ругаться?"

Итак, срвзу пример.  Было ДО.  Гугл жалуется на излишний объем в 376 КБ .

 

 

Стало ПОСЛЕ:

 

 

Гугл "жалуется" на излишний объем в 3.7 КБ.

 

С арифметикой, ведь, у всех порядок?

Было лишнего 376 К,  а стало 3.3 К.

 

Т. е. лишнего убрано на 99%.  Остался 1% недожатого.

Можно говорить о том, что эффективность сжатия составляет 99%.

И лишь исключительно на крошечных изображения размером вроде 50х50 или 70х70 эффективность ниже чем на средних и больших размерах.

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

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

 

уже ПОСЛЕ СЖАТИЯ общий объем передаваемых изображений для страницы, которую рассматриваю в качестве примера:

 

 

Передается 1,19 Мегабайт.  До сжатия было 1,56 Мега байт

И тут гугл предлагает дожать еще на 3.7 КБ.

Это от 1.56 МБ составит

 

Цитата

0.2%

 

Мы уже сжали изображения этой страницы, как минимум, на 24%  (от общей массы изображений).

Оставшиеся 0.2%  никакой погоды не сделают.

 

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

Когда сжато с эффективностью 99% - это разве "не сжимает"?

1% недожатого (исключительно в крошечных картинках вроде 50Х50) - это не повод для волнения по поводу "гугл ругается".

 

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

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

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

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

 

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

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

 

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

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

 

 

[sitecreator]

В продолжение.

 

 

 

 

 

Если смотреть на весь объем, переданной информации (2.94 Мега Байт)  для страницы, взятой в качестве примера.   А это главная страница реального магазина.

То потенциальный выигрыш от недожатого в 3.7 К составит

 

Цитата

0.1%

 

Результат, по сути, нестоящий усилий, потраченных на написание данного текста.

Но, повторюсь,

что и это уже учтено в новых версиях.  Новый Компрессор дожимает эти 0.1%.

Раз уж гугл предлагает такую моду,  а пользователи спрашивают,  то это уже сделано.

[RaVIOLy]

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

начиная с версии 1.6.5.

Обнова уже доступна или это анонс?)

[sitecreator]

А теперь про полезное.

анонсирую новые возможности.

 

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

И можно будет для таких файлов выбрать алгоритм Guetzli для JPEG от Гугла.

 

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

Но годится это только в случае применения к отдельным файлам, т. к. на сжатие одного баннера методом Guetzli тратится времени примерно МИНУТА. mozjpeg, для сравнения, сделает это за секунду.

 

На слабом хостинге этот метод может вообще работать минуты или ему может не хватить ресурсов. Это не для всех, но как альтернатива для получения максимального качества с максимальным сжатием, известным на планете Земля.

 

Более простой на сегодня способ есть.  Чтобы получить максимальное  качество для баннеров. Особенно текстовых.

Это использование формата PNG, и лучше всего (для малого веса) - это PNG-8.

 

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

[sitecreator]

30 минут назад, RaVIOLy сказал:

Обнова уже доступна или это анонс?)

 

Почти готова.

Вам в первую очередь будет предоставлена.

Там много полезного для работы с фоном исходных изображений.

Обрезка сделана более интеллектуально и есть больше настроек и гибкости.

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

 

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

 

новые моменты:

 

 

 

Если кто-то не знает,  то всякие адаптивные обрезки можно заставлять движок делать только на определенного типа страницах. Например, только на страницах "Категория".

Изначально это даже было заложено в глубине движка.   Но поскольку в model tool image (движка ) была заложена ошибка, то этим практически никто не пользовался.

Но некоторые шаблоны все же пользовались, предварительно исправив model tool image.

А некоторые шаблоны пытались пользоваться, но забывали исправить model tool image.

 

Т. е. по факту такие шаблоны посылали команду, например, "обрезать адаптивно по ширине", но поскольку model tool image оставалась с ошибкой, то ничиго визуально не происходило.

До того момента пока вы не поставили Компрессор, в котором ошибки дефолтного движка исправлены.

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

 

Вот для этого и появились новые элементы управления в модуле.

 

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

[sitecreator]

Как сделать адаптивную обрезку только на нужных страницах?

Например, на странице "Категория"?

Делаем правку в соответствующем контроллере.

 

 

$image = $this->model_tool_image->resize($result['image'], $this->config->get('config_image_product_width'), $this->config->get('config_image_product_height'), 'w');

 

 

Если нужно "по ширине" сделать адаптивную обрезку, то в конце добавляете параметр 'w'.

в вызове функции resize.

[rassigor]

Вопрос по нагрузке на процессор? думаю надо идти по этому пути,  создавать кеш по крону,  ибо на новых картинках сайт подтупливает

[flaero]

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

 

Почти готова.

Вам в первую очередь будет предоставлена.

Там много полезного для работы с фоном исходных изображений.

Обрезка сделана более интеллектуально и есть больше настроек и гибкости.

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

 

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

Очень ждем новую версию

[sitecreator]

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

создавать кеш по крону,

 

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

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

номер версии будет 1.7.*

 

слабых хост-площадок не так уж и много по моей статистике. но они есть. В районе 5%...10% таких.

Я удивлялся когда на недорогом общем хостинге очистка кеша картинок для 55 000 товаров не приводила к повышенной нагрузке, тормозам или подвисаниям.

И в тоже самое время на другом общем хостинге при кол-ве товаров всего 800 наблюдалось подтупливание.

 

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

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

[sitecreator]

Если у вас не работает установщик дополнений. Вы можете видеть это:

 

 

то самое время отремонтировать его:

 

 

 

 

Проблема не в модуле.  А в установщике.

Либо настраивайте правильно фтп в движке, либо (что лучше)   отключайте совсем фтп в движке и применяйте фикс

quick fix for OpenCart new extension installer

 

 

[nik123]

@sitecreator  Добрый день!

Планируете ли вы развивать функции водяного знака? 

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

[sitecreator]

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

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

 

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

более чем в 90% случаев можно сделать это сейчас без всяких сложностей.

делаете картинку для водяного знака в таких же пропорциях, как и пропорции картинок товаров.

в фотошоп мостите текст на этой картинке. назначаете размер водяного знака 100% и 100% (по ширине и высоте) в модуле.  и все.

и ваш водяной знак перекрывает всё изображение товара.

 

если что-то нужно сделать индивидуально, то я готов, но с вашей поддержкой.