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

[sitecreator]

6 часов назад, pavels1978 сказал:

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

 

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

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

Единственный критерий для него - это геометрический размер изображения.

 

Модуль позволяет вам выборочно накладывать водяной знак.

Вы можете настроить исключения (чтобы не накладывать).

Например, по геометрическому размеру.

 

6 часов назад, pavels1978 сказал:

есть не только изображения товаров, но и изображения категорий, всё в одной папке

 

Добавляйте в таком случае исключения для отдельных файлов.

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

Или просто добавляйте к названию nowatermark

[sitecreator]

6 часов назад, pavels1978 сказал:

Или, например, только к товарам, у которых есть определённый атрибут, метка, тег?

 

Вы умеете помечать как-то сами изображения?

Даже если представить, что будем маркировать каким-то тегом, то как вы его собираетесь увидеть?

Файловые менеджеры (серверные) не способны показать такую информацию, фтп - тоже самое. И установить через них невозможно.

[gorant21]

17 minutes ago, Yoda said:

Faced recently on one store wards with this miracle.

This is a real horror.
Download time for content with enabled module + 3-5 seconds.
When disconnected, everything is within 200-300 ms.
The module has a clear problem with determining the dates of creating images.

The module was removed, the transformation was done natively through imagick + webp from @stickpro the  store came to life and began to breathe.
I do not recommend this supplement to anyone!

Also, instead of the requested thousands of millions of rubles for completions on subdomains, it turned out that the free imagick library with opencart.com superbly superimposes watermarks and converts very high quality images. And jpegoptim and optipng, tuned to the crown - elegantly make compression.

Friends - do not get fooled by marketing. The module is not worth an egg. And only creates tupnyak your shopping!

 

ps if the administration suddenly receives a complaint and decides to somehow react to the author's complaints - I can provide a lot of proofs with a record of the fact that an add-on is being sold on your site, which hurts the stores!

there must always be someone who talks nonsense

[sitecreator]

Сайт 10 000 товаров.  У каждого товара по 20+ изображений.  Плюс еще 10+ изображений в тексте описания.

 

Работа с включенным модулем Компрессор (и вывод WEBP).

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

Кроме того еще и обычные изображения JPEG, PNG сжаты.

И скорость открытия страницы 250 мс.

Разумеется, когда кеш изображений готов.

 

 

 

 

 

Вот с полностью отключенным модулем Компрессор, видно, что изображения отдаются в формате JPEG вместо WEBP.

 

Время открытия страницы 225 мс - 315 мс. Т.е. практически такое же как и с включенным модулем Компрессор. (не берем в расчет первое открытие, тут некешированные данные, похоже)

 

 

 

 

Страница товара.   Не менее 33 изображений к товару, не считая изображений цветов, с ними больше 40 картинок будет для товара.

Сам по-себе шаблон сложный, и страница HTML весит по 350К и более.

Но Компрессор, выводя WEBP не приводит к тормозам.

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

 

Актуальная версия модуля Компрессор создает WEBP очень быстро, практически незаметно даже в режиме форсированного "на лету".  При этом можно даже нагрузку на сервер регулировать. Вплоть до задания работы по расписанию.

 

В любом деле нужен грамотный подход.

Недавно я встретил случай, когда у заказчика стандартный механизм по работе с изображениями (опенкарт) не мог создать из исходника изображение для кеша.  Fatal error происходил.  Видимо, нужно было ругать создателя опенкарт?

 

Но анализ показал, что Fatal error возникал из-за нехватки памяти, т.к. вес исходника (PNG 4000х3000) составил 11.5 Мегабайт.

 

 

Страница Товар:
 

Спойлер

 

 

 

 

[sitecreator]

52 минуты назад, pimur сказал:

Я посмотрю когда стикпро или вас не станет в какой то момент - а у пользователя что то произойдет с библиотекой или еще чем нибудь. Как он будет весело бегать и искать помощи =)

 

Правильно говорите.

Причем, что самое смешное, то "чудесное" решение замечательно умеет оставлять Сафари (и все браузеры на iOS)  и заодно старые браузеры вообще без картинок. 

Видать, они еще не тестировали....

Но какое нам дело до этого? Нравится, да и пусть пользуется.

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

 

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

 

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

 

 

 

 

[sitecreator]

Любой желающий может проверить скорость загрузки моей страницы.  150 мс.

 

http://watermark.sitecreator.pro/index.php?route=product/category&path=20

 

 

 

 

Сравните с аналогичной страницей демо-ocstore:  350-500 мс.

и соответствующая оценка гугла демо-ocstore:

 

 

 

 

"Пагубное" влияние на скорость модуля "Компрессор" заметно во всей красе. 

 

[sitecreator]

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

 

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

А также улучшена работа формирования и отдачи изображений WEBP средствами модуля.

 

Известны на данный момент отдельные сложности с WEBP Lazy Load на некоторых шаблонах.

Вопрос отчасти решается несложным индивидуальным редактированием lazyload_start_alt.js.

Некоторые пояснения для редактирования имеются в самом файле JS.

В следующих версиях обновлю JS для более полной поддержки разнообразных шаблонов.

 

Прошу отнестись с пониманием, что сделать абсолютно универсальный WEBP Lazy Load, который бы подходил сразу для всех шаблонов, да еще в любой комбинации с модулями вроде "баннеры-слайдеры супер-паралакс" (и т.п.) довольно затруднительно. Поэтому нередко просто требуется индивидуальная адаптация. Она не входит в базовую установку/настройку,  но если я не вижу сложностей, то я ее делаю сразу, прошу не воспринимать это как мою обязанность, но всего лишь как знак доброй воли.

 

 

[sitecreator]

Для примера беру любой магазин, работающий с Компрессор 1.12.*.

Товаров 7300+

 

главная страница в пределах 300 мс, что с отдачей webp, что без нее (для прочих и старых браузеров).

 

 

 

 

Страница Категория с фильтром и пр.  218 мс

 

 

 

делаю на странице вывод сразу 180 товаров.  Страница загружается за 490 мс.

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

 

 

 

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

И заказчики не дадут соврать.

[flaero]

подтверждаю слова выше - приведены скрины моего рабочего магазина.

При этом обращаю внимание, что магазин работает на обычном хостинге ukraine.com.ua

При переходе на WebP вес страницы нормально так поуменьшался.

[RaVIOLy]

Если спорить о разнице в скорости работы - то только при создании кеша изображений. С готовым кешем даже говорить не о чём. Справедливости ради, со старой версией (номер не помню) разница была, но это было давно...

О создании кеша:

1. Медленнее и с компрессором и без него. Кто-то скажет: "Дак с компрессором ещё медленнее!" - Да, но меня не устраивает ни медленнее ни медленнее медленного. Так что для себя решил - кеш изображений обязательно должен быть создан. Не юзерами с ботами за неделю, а моими силами. Сам удалил - сам создал) Запустил Ксену на ночь и вопрос решен. К стати, последний раз это было 7 месяцев тому).

2. Уже анонсировано сжатие по крону, так что даже о формировании кеша нечего будет сказать.

 

Об альтернативах модулю:

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

1. Сжатие: jpegoptim и optipng через Jet Cache или на сервере по крону. Хоть говорят что ImageMagick лучше сжимает, не разбираюсь не мерил. Итого, либо другим модулем либо заказывать услугу. Но всё равно тонко настроить не получится. Качество для разных разрешений изобр. и тп. 

2. Ватермарк. Вроде есть даже бесплатное решение. Не тестил, но допустим работает всё ок. Обратно же, исключения не добавишь... 

3. Обрезка фона - не вижу альтернатив вообще. Только руками.

4. WebP Насколько я понимаю, можно настроить сервер на отдачу WebP - т .е. плати деньги.

 

Итого, заплатив те же +/- деньги (Мне кажется +) я получу всё тоже, но в разных флаконах и без:

Тонкой настройки сжатия для разных разрешений.

Возможности исключить изображения и\или папки от накладывания ВатерМарка.

Обрезки фона изображений - для меня архиважно.

Возможности отключить белые поля.

Возможность не увеличивать сверх размеров (геометр.) .

 

 

Говорю лишь о том, чем сам пользуюсь, так что возможно что-то пропустил.

Никакого маркетинга, сугубо мои скромные соображения.

 

 

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

[andrejbr]

Установил версию 1.12.5, opencart 2.3, 2000 товаров. На страницах с текстом около 1000 знбп pagespeed выдает 88 в мобильной и 100 в десктопной.

Спасибо за вашу работу.

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

[sitecreator]

Еще раз простая информация про jpegoptim. (хоть это к модулю Компрессор и не относится)

 

данный софт НЕ сжимает изображения. В том смысле в каком мы этого ожидаем, например как mozjpeg, google/guetzli, WEBP.

Compressing, конечно jpegoptim умеет делать как и абсолютно любой алгоритм создания JPEG, ибо JPEG - это и есть по определению сжатый формат, в нем всегда используется Compressing. Сохранение файла в формате JPEG всегда сопровождается сжатием, и сохранение файла всегда будет называться "compressing" по-английски. Другое дело, что не каждый алгоритм способен сжать JPEG серьезно сильнее стандартного сжатия.  Выше перечислены "реально сжимающие" алгоритмы.

 

Все, что jpegoptim умеет делать - это выкинуть метаданные из файла, плюс сделать прогрессивный JPEG из НЕпрогрессивного.

Только за счет этого возможно некоторое уменьшение веса.

Таблицу Хаффмана jpegoptim оптимизирует плохо, в некоторых случаях вы получите за счет этого выигрыш в 1%-5%, но чаще будет близко к 0%, это на практике, поэтому это больше для галочки и не стоит от этого ждать чуда.

 

Довольно странно слышать предложение "запустить jpegoptim" после обработки imagick.

А зачем?

Вопрос, конечно, риторический.

Просто сам imagick (imagemagick) способен создавать прогрессивный JPEG  (что он и делает по-умолчанию), а также выкидывать метаданные.

Есть в imagemagick и режим оптимизации таблиц Хаффмана, эффективность сродни jpegoptim, т.е. близка к нулю на реальных изображениях.

 

Спрашивается, а какой уровень знаний в области графики тех людей, которые советуют "оптимизировать" за счет jpegoptim после того как imagick уже выдал оптимизированную картинку?

 

С эффективностью mozjpeg или WEBP алгоритм jpegoptim не идет ни в какое сравнение. Если mozjpeg или WEBP - это конкурирующие технологии, и по эффективности снижения веса JPEG они близки, то jpegoptim крайне сильно от них отстает, хоть тоже умеет оптимизировать JPEG.

Все познается в сравнении.  И, да, после того как imagick уже оптимизировал изображения за счет:

 

1) прогрессивный формат,

2) удаление метаданных,

3) оптимизация таблиц Хаффмана

 

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

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

 

И другое дело если некоторые господа просто не знают как работать с imagemagick.

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

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

[sitecreator]

Пояснение к тому как работают разные режимы сжатия.

Как избежать тормозов при создании сжатых изображений?

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

Если есть сомнения, то не надо спешить ставить все подряд галочки в надежде, что чем больше галочек, то тем лучше!

Спросите автора какой лучше выбрать режим.

Если у вас VDS на 8 ядер и 32М оперативки, то создать тормоза вам практически не удастся.  Проверено на опыте когда на сервере было изображений 150 ГИГабайт!!!

Если общий хостинг или слабый VDS, то давайте соразмерное задание мощности вашей площадке!

 

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

 

 

ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ!

Рекомендуется использовать WEBP в качестве сжатого формата (для JPEG, PNG). WEBP создается быстро, не требует очистки кеша изображений, т.е. не создает лишней нагрузки во время создания. MOZJPEG требует для создания сжатого JPEG очистки кеша изображений, работает примерно в 3 раза медленнее при создании чем WEBP, что вызывает временно (только в момент создания) повышенную нагрузку на сервер. Если вы не обладаете достаточной мощностью сервера, то используйте только создание WEBP, это обеспечит минимальную нагрузку на сервер во время создания сжатых изображений.
OPTIPNG работает на порядок дольше при создании сжатого PNG чем WEBP, а по эффективности в плане веса сильно уступает WEBP. Включайте осознанно этот режим.
Если у вас есть сомнения и вы не хотите создавать (хоть и временные) тормоза сайта, то используйте только WEBP.

ВНИМАНИЕ! Повышенное потребление ресурсов сервера происходит только в момент создания изображения, как только изображения созданы, то потребление ресурсов приходит в обычную норму. Если работает режим "на лету", то это значит, что изображения создаются при перовм или втором открытии страницы, именно в этот момент страница открывается дольше привычного. Далее страница открывается как обычно с привычной скоростью.

С целью экономии ресурсов сервера не рекомендуется включать одновременно создание MOZJPEG, OPTIPNG и WEBP. Всегда включайте создание WEBP позже, этот формат может быть создан в любой момент. Если решили использовать MOZJPEG, OPTIPNG, то пусть сперва отработают эти алгоритмы и будет создан кеш сжатых JPEG, PNG. Как только нагрузка по созданию нового сжатого кеша упадет, то тогда можно включать режим создания WEBP.
Если у вас мощности сервера достаточно, то тогда допускается одновременное включение MOZJPEG и создание WEBP. Если видите, что сервер тяжело справляется, то отключите тяжелые режимы.
Выбор правильной стратегии сжатия и верных настроек обеспечит комфортный режим работы вашего сайта. Наоборот, бездумное выставление всех галочек может привести к временным "тормозам" вашего сайта.
Включение режима "Сравнение размеров" на постоянной основе недопустимо! Это приводит к повышенной нагрузке и бесполезной трате дискового пространства!

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

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

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

[sitecreator]

При обновлении до версии 1.12.6+ нужно проявить внимание!

Внедрена защита "от дурака".

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

 

Цитата

<<Я прочитал "предупреждение"
("ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ!") о работе mozjpeg, optipng
и осознаю свои действия.>>

 

Если вы не подтвердите, что прочитали "предупреждение", то у вас останутся заблокированы для выбора три опции:

 

- mozjpeg для JPEG "на лету" (!)
- OptiPNG для PNG "на лету" (!)
- Сравнение размеров файлов ДО и ПОСЛЕ Суперсжатия

 

И даже если в этих заблокированных опциях стояли ранее галочки, то при нажатии "сохранить" данные опции скинутся в настройки по-умолчанию, т.е. в состояние "отключено".
Поэтому обязательно прочитайте текст с заголовком "ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ", осмыслите его, установите нужную галочку и нажмите "сохранить".   Все прежние настройки не пропадут.

Сделано это специально чтобы вы полностью осознавали свои действия и отвечали за них. Чтобы не было бездумной установки галочек и всех параметров "на максимум".

[sitecreator]

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

 

Не надо врубать режим OptiPNG с уровнем 5  (6-й я вообще убрал от дураков подальше, ибо он работает раз в 20 медленнее среднего) если у вас сплошь в магазине изображения PNG по 12 Мбайт в исходниках.  Если хотите, то выбирайте, но это будет ваш осознанный, хоть и неадекватный поставленной цели выбор.  Ибо таким режимом вы просто положите на лопатки ваш сайт, израсходовав сразу 100% мощности и процессора, и памяти.

 

 

 

[sitecreator]

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

 

 

Из полезного:

 

 

 

Вы можете выбирать кроме параметра Качество еще и уровень оптимизации если используете для создания WEBP движок cwebp (http_cwebp).

Данный движок (для создания WEBP ) вы легко установите нажатием одной кнопки в модуле Компрессор,  работает под любой версией Linux.  И это возможно примерно на 97% хост-площадок (везде, где есть функция proc_open php).   оставшиеся 3% пользователей могут использовать для WEBP библиотеку GD или imagick, или движок http_cwebp (работает везде, где разрешены cgi-скрипты).  движок http_cwebp будет добавлен немного позже.

 

 

Разница в весе файлов между самым быстрым (0) и самым медленным (6) способом создания WEBP составляет в среднем 30% для JPEG.

 

Модуль Компрессор дает вам возможность гибко учитывать ваши потребности и возможности (мощность сервера). 

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

А если мощности достаточно, то можете выжать из формата WEBP все по-максимуму!

 

Ни одно решение не обладает такой гибкостью, какую предлагает модуль Компрессор.

Главное - это разумный, а не бездумный подход.

 

[sitecreator]

Новая версия 1.12.7.

 

 

основные изменения связаны с улучшением поддержки WEBP и Lazy Load.

 

WebP Lazy Load  без проблем работает если у вас используется, например, бесконечная прокрутка.

А также если ваш фильтр использует js ajax для подгрузки результатов выдачи, т.е. без перезагрузки страницы.

 

Это довольно непростая задача как в плане формирования WEBP, так и его правильной выдачи в правильный браузер (в "неправильные", т.е. без поддержки webp мы отдаем jpeg/png).   Особенно если учитывать, что могут использоваться ускорители (кешеры).

 

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

 

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

 

 

Тут как-то интересовались чем же мое решение по WEBP лучше существующих? Ответ простой - модуль Компрессор просто работает, а сторонние решения - нет.

По возможностям, а главное - по работоспособности WEBP почти на любом хостинге, с почти любым шаблоном и в любом браузере альтернативы просто нет.

 

 

Задача полностью решена если подгрузка идет в формате HTML. Тут и совместимость с ускорителями.

Если подгрузка товаров на страницу идет в формате JSON, то тут есть пока сложности с универсальным решением. Оно возможно если не используется ускоритель (кешеровщик).  В противном случае (если работает кешеровщик) надо делать конкретную адаптацию под определенный шаблон.

Никаких фатальных проблем нет, просто при подгрузке товаров в формате JSON средствами шаблона (а это уже совершенно нестандартно по отношению к движку)  изображения подгружаются не в WEBP (как хотелось бы), а в JPEG/PNG.   

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

 

 

 

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

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

 

тут мультик в 10М показывающий работу WEBP Lazy Load  в случае бесконечной подгрузки.

Спойлер

 

 

 

 

 

Заказчики, хоть немного разбирающиеся в этих технологиях меня поймут.

Ну а юношам, мнящим себя программистами, думаю, что это будет очень сложно для понимания.

[rassigor]

Обновил модуль на 1.12.7.

Очистил Кеш, включил WEBPP, но он не появляется

https://greenagri.ru/professionalnye-semena-1/professionalnye-semena-cvetov/alissum/

Очистил кеш вообщем, все равно не появляется

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

[sitecreator]

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

Очистил Кеш, включил WEBP

 

А кеш то зачем чистили? Чем вас он не устраивал? Вы же про кеш изображений говорите?

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

Потом кто-то жалуется, что сайт начал тормозить....

 

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

 

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

включил WEBPP, но он не появляется

 

значит, были в чем-то невнимательны, скорее всего.

 

 

От вас очень мало информации пока

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

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

Вероятно, что не включили создание webp.   Его же надо создать прежде того чтобы он "появился" в браузере.  Вывод у вас включен.

 

Проверяется, например, так:

https://greenagri.ru/image/cache/catalog/import_files/cf/b18d5a74a6bac15e54d4bf40cc12007c-250x250.webp

 

Отсутствует!

Или посмотрите в папке с файлами изображений. А есть ли там WEBP?  Если не появились, то и выводить нечего.

 

Вот это у вас включено?   И тесты движка webp пройдены успешно?

 

 

 

 

 

 

Я не знаю как еще обратить внимание заказчиков на необходимость внимательно читать текст.

 

[rassigor]

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

 

А кеш то зачем чистили? Чем вас он не устраивал? Вы же про кеш изображений говорите?

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

Потом кто-то жалуется, что сайт начал тормозить....

 

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

 

 

значит, были в чем-то невнимательны, скорее всего.

 

 

От вас очень мало информации пока

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

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

Вероятно, что не включили создание webp.   Его же надо создать прежде того чтобы он "появился" в браузере.  Вывод у вас включен.

 

Проверяется, например, так:

https://greenagri.ru/image/cache/catalog/import_files/cf/b18d5a74a6bac15e54d4bf40cc12007c-250x250.webp

 

Отсутствует!

Или посмотрите в папке с файлами изображений. А есть ли там WEBP?  Если не появились, то и выводить нечего.

 

Вот это у вас включено?   И тесты движка webp пройдены успешно?

 

 

 

 

 

 

Я не знаю как еще обратить внимание заказчиков на необходимость внимательно читать текст.

 

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

[sitecreator]

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

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

 

Это другое дело.

Но с webp он не связан.

И если товаров много (а у вас их более 50 000+), то лучше дать сперва сформироваться кешу изображений, а потом уже включать создание webp.

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

 

А ответ вполне очевиден почему не создается webp.

Ни одного движка не было.  Создавать то нечем было. Красным отмечено.

 

 

 

Надо было всего навсего нажать одну кнопочку.

 

 

И радоваться появившимся бабочкам:

 

 

 

WEBP будет постепенно создан.

На странице не сразу все изображения будут заменены на webp.

[Sergeyy84]

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

Проверяется, например, так:

https://greenagri.ru/image/cache/catalog/import_files/cf/b18d5a74a6bac15e54d4bf40cc12007c-250x250.webp

 

Отсутствует!

Что-то не пойму. Вы мне в личке писали, что при отсутствии webp сервер должен отдавать ngnix, а не 404 ошибку. Здесь тоже страница отдает 404 ошибку.

[sitecreator]

15 минут назад, Sergeyy84 сказал:

что при отсутствии webp сервер должен отдавать ngnix, а не 404 ошибку. Здесь тоже страница отдает 404 ошибку.

 

в данном случае не это главное, а то, что файл отсутствует.

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

Но, по хорошему, nginx под webp в данном случае не настроен, что, конечно же, не есть хорошо. Т.е. работать то будет, но до определенной степени. Случай из разряда "и так сойдет, ведь работает же".

 

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

 

 

[Atlet]

Все классно. Обновление встало. Почему в браузере пишет: Соединение с сайтом защищено, но некоторые данные переданы не безопасным способом. Грузит фотки по http, когда сайт https

vopodarok.ru

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

[sitecreator]

22 минуты назад, Atlet сказал:

Грузит фотки по http, когда сайт https

 

а это уже ваши настройки хромают. Некоторые у вас отдаются по http.  Но тут webp никак не виноват, у вас с jpeg такая же ситуация. Вы это можете легко увидеть в старом браузере, например, в FF < 65, который не понимает webp .

 

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