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

[sergroko]

Я понял, спасибо. 

 

Выклянчил у админа включить proc_open хотя бы на время, так как не получилось запустить Imagemagick\ cwebp \ http_cweb

 

Совет - вобще уберите GD webp. Побило фотки и после отключения пришлось их в ручную удалять.

 

Вроде все работает  К сожалению на ВДС ставится не без танцев с бубном.

 

Совет2 - добавьте в самый верх описания о проц_опен и про бинарный режим ФТП. 

 

Краткость - сестра таланта 

 

Роман, спасибо за модуль и поддержку

 

О, еще маленьки вопрос, тут в теме проскакивало что-то о совместимости с кешером-ускорителем Лайтенингом. Какие-то манипуляции надо проводить?

(я пока временно его выключил)

 

 

 

 

 

Змінено 11 липня 2019 користувачем sergroko

[sitecreator]

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

Совет - вобще уберите GD webp. Побило фотки и после отключения пришлось их в ручную удалять.

 

Уже думал об этом тоже.

У меня по поводу GD многократные красные предупреждения стоят.

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

 

Из кеша WEBP-невидимки можно удалить через сам модуль Компрессор. Там кнопочка есть. А вот в других папках (не кеш) уже надо руками удалять.

 

Т.е. формально в GD  может быть поддержка WEBP, но на деле получается на выходе либо черный фон (после прозрачных PNG), либо (что вообще никак не лечится) часть картинок в "невидимом" формате WEBP, т.е. для Хрома часть таких картинок будет словно пустое прозрачное место, хоть они прекрасно видны в том же новом FireFox (65+ версия).

 

В общем, только в новых сборках GD  есть исправление всех этих недугов. Но кто-то из хостеров следит за этими моментами? Практически никто не следит, а многие просто от греха подальше даже не включают для GD  поддержку WEBP,  и это даже лучше чем поддержка WEBP с багами.

 

27 минут назад, sergroko сказал:

о совместимости с кешером-ускорителем Лайтенингом. Какие-то манипуляции надо проводить?

 

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

И оптимизацию изображений средствами того модуля также стоит отключить. Что и как там оптимизируется не знаю, софт для сжатия изображений там не используется на вашем сервере. Если только там гоняются изображения туда-сюда.... Но я бы такой способ положил бы на лопатки лишь одним своим заказчиком, т.к. у него сервер (не VDS!) 8 ядер 32 Гиг памяти, и 150 Гиг (!!!!)  кеша изображений.

 

34 минуты назад, sergroko сказал:

Вроде все работает  К сожалению на ВДС ставится не без танцев с бубном.

 

Ставится везде одинаково. Просто обычно на общем хостинге сам хостер следит за верными настройками сервера, а на VDS каждый настраивает "как умеет".

[sergroko]

На заметку тем, кто использует Lightening

 

Ставьте настройки 

Оптимизация кода:  Безопасная

 

Иначе не будут работать картинки на айфонах (тестил на 5с, 10, не Хроме и Сафари)

[sergroko]

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

На заметку тем, кто использует Lightening

 

Ставьте настройки 

Оптимизация кода:  Безопасная

 

Иначе не будут работать картинки на айфонах (тестил на 5с, 10, не Хроме и Сафари)

обманул, Базовое сжатие кода 

иначе битые картинки с webp не заменяются на Айглюках

 

Змінено 12 липня 2019 користувачем sergroko

[sitecreator]

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

Базовое сжатие кода 

 

что за сжатие кода и зачем оно?

HTML сжимать? Так это бессмысленное дело. Он и так сжимается сервером. А всякие минификации по удалению пробелов и тп. только отжирают ресурсы и тратят напрасно время, т.к. выигрыш в итоге будет нулевой если сравнивать итог после сжатия gzip файла.

[sitecreator]

12 часов назад, sergroko сказал:

На заметку тем, кто использует Lightening

 

забавно, что автор того модуля пишет:

 

Цитата

использование WebP не дает никакого прироста скорости

 

Ошибочное утверждение. Если раза в 2-3 снижается вес изображений (а по статистике именно так после перехода на WEBP), то это никак не влияет на скорость?

гугл считает иначе.  И своими баллами также это подтверждает.

 

Просто нужно не забывать, что просто создать webp будет недостаточно, за это вам, действительно, никто баллов не накинет. WEBP еще нужно правильно вывести в браузер, а старым браузерам отдать jpeg/png.

Вот это все умеет модуль Компрессор на любом хостинге. И вам нет особой нужды думать о том поддерживает ли ваш сервер WEBP.

Модуль Компрессор максимально автоматизировал и упростил для вас этот процесс, включая возможность использования WEBP Lazy Load.

 

[dexion]

@sitecreator а для браузеров без webp lazyload'а в модуле нет?

[sitecreator]

12 часов назад, dexion сказал:

а для браузеров без webp lazyload'а в модуле нет?

 

пока не делал, т.к. особого смысла в этом не видел.

1) гугл этого не оценит

2) раз не оценит гугл, то подавляющее большинство пользователей тоже не оценят

3) по статистике 80% трафика будет приходиться на webp.

 

 

Возможно, что позже добавлю.

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

Точно также как не окупится разработка (которая сделана уже и внедрена) для поддержки тех 2% пользователей, у которых хостер заблокировал любую возможность создания WEBP. 

Т.е. чисто технически проблем нет, но пока непонятно зачем тратить на это время.

[dexion]

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

2) раз не оценит гугл, то подавляющее большинство пользователей тоже не оценят

 

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

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

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

1) гугл этого не оценит

 

У гугла в доке есть рекомендации об использовании lazyload для всех картинок, а не только вебп

 

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

Точно также как не окупится разработка (которая сделана уже и внедрена) для поддержки тех 2% пользователей, у которых хостер заблокировал любую возможность создания WEBP. 

 

 

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

 3) по статистике 80% трафика будет приходиться на webp.

 

Т.е. для 2% пользователей вы заморочились и собрали функционал, а для 20% нет смысла?)

[sitecreator]

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

Очевидно же, что страница прогрузится быстрее

 

Так никто и не спорит с этим.

 

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

У гугла в доке есть рекомендации об использовании lazyload для всех картинок

 

Безусловно.

Но думаете большинству это интересно?

Они не читают рекомендации.

Большинству интересны лишь баллы гугла. Тупо баллы, общие баллы.

И такие заказчики будут недовольны даже в случае ускорения, которое видно на глаз, но которое "гугл не оценил". К примеру, на странице вес снижается с 8 М до 1М (довольно часто бывает если много баннеров PNG), но заказчик остается все равно в претензии, что "он ожидал большего", его абсолютно не интересует, что гугл не сильно поднял баллы, например, из-за тормозного JS.

 

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

Т.е. для 2% пользователей вы заморочились и собрали функционал, а для 20% нет смысла?)

 

Все не так однозначно.

Есть заказчики, которые до покупки будут мучиться вопросом "а будет ли работать webp или не будет на моем хостинге?".  Это при том, что у 95%-98% заказчиков с этим никаких потенциальных проблем нет. Но из-за этих сомнений будут опасаться покупать даже те, у кого с хостингом в плане webp нет сложностей совсем. 

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

 

Это мы с вами понимаем, что lazy load будет полезен в любом случае (и для тех самых 20% пользователей сафари).  Но понимающих это заказчиков вряд ли наберется 20%. Скорее всего, понимающих важность этого момента будет тоже примерно 2%-5%.

 

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

 

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

[stickpro]

В 11.07.2019 в 12:59, sitecreator сказал:

Альтернатив модулю в плане WEBP (особенно это касается вывода) не существует.

да что вы говорите

[sitecreator]

Для тех, кто заблудился в темах есть как раз раздел:

 

[dexion]

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

Это мы с вами понимаем, что lazy load будет полезен в любом случае (и для тех самых 20% пользователей сафари).  Но понимающих это заказчиков вряд ли наберется 20%. Скорее всего, понимающих важность этого момента будет тоже примерно 2%-5%.

 

Даже если не все понимают, это же must have для картинок грузить их lazyload'ом, не важно webp это или jpg. Не настаиваю, но разве реализация lazyload для jpg как то существенно отличается от webp и требует много времени на доработку? Как минимум, ускорение мобильного сафари может дать прирост конверсии и ранжирования в поиске всем покупателям модуля, так зачем такое упускать из виду?

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

[sitecreator]

@dexion , с вашей подачи, думаю, что это (lazy load для всех форматов и всех браузеров) появится теперь быстрее чем я планировал ранее.

[sitecreator]

Новая версия модуля Компрессор 1.16.5

 

Столкнулся на днях с "чудесами" у одного из хостеров. В php заявлена поддержка WEBP, но сам php не в состоянии записывать формат webp. Причем, что самое неприятное - это то, что php не выводит ошибку, но зато вылетает 502-я,  т.е. средствами php невозможно отследить и не допустить ошибку, разумеется, что никакие try-catch не работают.

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

 

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

 

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

Пойдет в копилку разных багов и глюков хостера.  Наряду с картинками-невидимками WEBP, которые любит создавать GD.

 

В новой версии присутствует защита от такого "обмана" со стороны imagick.

В дополнение к другим защитам от некорректного софта.

 

Рекомендуется всегда использовать софт для создания WEBP, идущий вместе с модулем, т.е. CWEBP (скомпилирован из исходников от Гугла для любой Linux и Windows), который устанавливается одной кнопкой и работает у любого хостера, никакие ограничения не действуют, достаточно наличия хотя бы CRON у хостера, а в 95% вы всегда можете использовать режим "создание на лету webp".

 

 

 

[sergroko]

В 13.07.2019 в 00:03, sitecreator сказал:

 

что за сжатие кода и зачем оно?

HTML сжимать? Так это бессмысленное дело. Он и так сжимается сервером. А всякие минификации по удалению пробелов и тп. только отжирают ресурсы и тратят напрасно время, т.к. выигрыш в итоге будет нулевой если сравнивать итог после сжатия gzip файла.

Погоня за папугаями Пейджспид.

До оптимизации было что-то в районе 12\50, сейчас под в районе 85-95, сейчас качели с Лайтенингом, не работает маусховер-зум, только если кликнуть на фотку. Гзип на яваскрипт отключилал. 

[sitecreator]

WEBP работает везде просто и надежно !

Никакой зависимости от хостера в плане создания и вывода WEBP! Работает WEBP везде без всяких условий!   Не надо спрашивать будет ли работать на вашем хостинге WEBP. Ответ простой - у вас будет WEBP! В данном решении предусмотрено практически все, включая полную совместимость с ускорителями Jet Cache, Turbo.

WEBP (сжатый формат графики) можно теперь получить практически у любого хостера.

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

Такая поддержка WEBP встроена в модуль Компрессор и работает на любой Linux и Windows.

 

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

 

Благодаря современному формату изображений WEBP удается снизить общий вес изображений в среднем в 2-3 раза на странице, и тем самым выполнить рекомендации Гугла.

[sergroko]

Добрый день. 

Сеодня увидел проблему с АМП-страницами.

Что-то можно сделать?

 

Пример

https://arcos.com.ua/index.php?route=product/amp_product&product_id=4790

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

http://prntscr.com/og6n37

 

1
<script>
// WEBP detect by sitecreator (c) 2019 https://sitecreator.ru webp_detect.js
...
</script>
2
<script>
// WEBP Lazy Load by sitecreator (c) 2019 https://sitecreator.ru lazyload_sitecreator.js
...
</script>
3
<script>
// WEBP Lazy Load by sitecreator (c) 2019 https://sitecreator.ru lazyload_start.js
...
</script>

 

Змінено 17 липня 2019 користувачем sergroko

[sitecreator]

41 минуту назад, sergroko сказал:

Сеодня увидел проблему с АМП-страницами.

 

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

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

 

Цитата

Так, если URL канонической страницы – example.com/kotiki, то адрес AMP-страницы стоит сделать таким: amp.example.com/kotiki или example.com/amp/kotiki

 

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

 

Именно для такой рекомендации гугла (отдельная папка amp) сделано в модуле определенное решение для совместимости.

И именно такой способ организации amp страниц я встречал ранее на сайтах.

 

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

Или можно доработать сам модуль под ваши условия. С этим прошу в личку.

Либо просто отключите Lazy Load.

[LionHunter]

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

Именно для такой рекомендации гугла (отдельная папка amp) сделано в модуле определенное решение для совместимости.

И именно такой способ организации amp страниц я встречал ранее на сайтах.

Скажите, пожалуйста, не знаете ли Вы готовых решений для AMP на опенкарт? 

[sitecreator]

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

Скажите, пожалуйста, не знаете ли Вы готовых решений для AMP на опенкарт? 

 

Нормальные, чтобы можно было рекомендовать, не встречал.

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

 

Вообще, это довольно сложная задача - создать универсальное решение для всех шаблонов.

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

Но как объяснить таким, что он и не должен работать на amp страницах?  Фильтр использует динамическую подгрузку и JS, которого в принципе не должно быть.

Возможно использовать только JS, которые есть на cdn.ampproject.org

 

Т.е. amp - это упрощенные страницы. Они именно для быстрого просмотра, но никак не для подбора по параметрам (фильтрации).  Не бывает amp страниц, на которых можно осуществить весь функционал покупки и т.д. и т.п.

amp - это по сути статичная страница, именно поэтому она супер-быстрая.

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

 

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

 

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

Но нужно понимать, что это по-сути отдельный шаблон.

[LionHunter]

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

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

Ну, да, тех кто понимает - мало... Пока Гугл не пнет со своей стороны сильнее, всем будет и так "нормально" )
В общем, если будете делать, я готов купить такой модуль. Правда не знаю, сколько еще будет таких желающих

[squid]

Здравствуйте. Есть изменённый Оpencart от одного разработчика. При оформление заказа, после ввода всех данных клиента переход на оплату. Если юзер залогинен, то без проблем, а гость, после клика продолжить, остаётся на этой же страницы. Эффект проявляется сразу как только установлен модуль, но ещё даже не включен.

[sitecreator]

10 минут назад, squid сказал:

Эффект проявляется сразу как только установлен модуль, но ещё даже не включен.

 

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

Вы уверены, что дело в модуле?

Почему на 550+ сайтах, где работает модуль таких проблем нет?

Причем часто даже на измененных вдоль и поперек движках Опенкарт.

 

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

после клика продолжить, остаётся на этой же страницы

 

Смотрите на проблемы вашего JS.

 

Думаю, что никому не интересны тут частные ситуации.
 

Спойлер

 

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

И , пожалуйста, уточните где покупался модуль. Я пока не вижу вашего ника в БД покупок и лицензионных ключей.

Все в личке.

 

 

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

 

Цитирую описание модуля:

 

Цитата

 

system/image.php, catalog/tool/image.php, admin/tool/image.php.

 

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

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

 

 

[sergroko]

В 17.07.2019 в 13:05, sitecreator сказал:

Либо просто отключите Lazy Load.

Все равно остается 1 скрипт, как я понял  - проверки браузера. Убрать не могу....товары выше среднего, большая доля траффа с айглюков)

Если есть какой-то совместимый плагин (модуль) АМП - подскажите.

 

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