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

[Elenaruzana]

Я так понимаю Гугл и сам страдает от своих нововведений...

[sitecreator]

На всякий случай для тех, кто пропустил информацию от Гугла.

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

Как и было обещано Гуглом с июля 2018-го поисковая выдача ранжируется с учетом очень приоритетного требования к скорости страницы.

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

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

 

Да, становится намного сложнее теперь работать с мобильными (адаптивными) версиями сайтов. Ну очень сложно угодить гуглу!

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

 

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

 

Но тот, кто не выполняет рекомендации гугла по изображениям,  не увидит себя в зеленой зоне ни для мобильной версии, ни для PC версии.  Тут Гугл тоже только ужесточил требования.  Заметил, что у кого все в порядке с изображениями, тот поднялся в зеленой зоне еще выше (мой пример для сайта выше:  96 --> 99  для PC версии), а у кого проблемы, то тот несколько упал из-за неоптимизированных изображений.  

 

В общем, борьба по новой пойдет. Более серьезная.

 

Это текст еще от июля 2018-го.   На практике до сегодняшнего дня гугл вел себя еще довольно мягко.  Собственно, в тексте гугла от июля тоже все довольно пока мягко, и эта мягкость не очень то настораживала веб-мастеров до сегодняшнего дня. Но все изменилось вчера.  Реальные действия гугла оказались более жесткие чем его июльские заявления и призывы к ускорению и перестройке.

 

Цитата

У верблюда два горба потому, что жизн - борба

 

 

[Vorodisa]

У меня мобила 37(((

Отправлено с моего SM-A520F через Tapatalk

[sitecreator]

Работал сегодня с одним сайтом в новых условиях.

За счет уменьшения объема изображений индекс скорости загрузки изменился с 7.7 сек до 4.1 сек.

И общие баллы поднялись с 76 до 96.

Т. е. гугл учитывает не просто скорость генерации страницы на сервере, а время для ее отображения в браузере.  Скорость генерации на сервере, безусловно, что важна. Но не менее важно как быстро загрузится вся информация, а основной ее объем (по весу) составляют изображения.

 

 

 

 

 

Сегодняшняя оценка ДО моей установки Компрессора и ПОСЛЕ:

 

 

 

[sitecreator]

19 минут назад, Vorodisa сказал:

У меня мобила 37(((

 

у всех примерно упала оценка до этого уровня.

 

на motaki.ru  с 92-х позавчера до 38 вчера.

Сегодня немного выросла, аж до до 41

[Vorodisa]

Главная мобил 47 пк 97
Карточка мобил 38 пк 98

Сейчас проверил. Формат web или как он там - выключен в модуле. Надо настооить.

Отправлено с моего SM-A520F через Tapatalk

[sitecreator]

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

Формат web или как он там - выключен в модуле. Надо настооить.

 

в принципе достаточно сжатого за счет mozjpeg JPEG.

Просто сам webP создать не очень сложно.  Сложнее его отобразить. На VDS это делается без проблем.

У многих хостеров на общих хостингах это тоже делается без проблем если есть возможность настройки кеширования статики (изображения и т.п.)

Но не все хостеры дают это настроить, т. к. это относится к конфигам nginx. 

Например, http://ukraine.com.ua/,  в этом плане очень гибок и позволяет настроить как угодно почти все.

 

Для вывода webP (если хостер не позволяет настраивать кеширование статики) у меня есть ocmod как обходной вариант, но популярности и развития он не получил.

Поэтому проще пользоваться сжатыми JPEG, PNG.

 

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

[PoliteX]

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

 

у всех примерно упала оценка до этого уровня.

 

на motaki.ru  с 92-х позавчера до 38 вчера.

Сегодня немного выросла, аж до до 41

на мобилке "Backend Error"

десктоп - 98

[rassigor]

Вопрос такой,  реализовано ли проверка на уровне кода,  поддерживает ли браузер новый формат? Если не поддерживает ему отдавать джпег,  посмотрел по метрике у меня 25%заходов с браузеров,  которые не поддерживают новый формат

[sitecreator]

Пока WEbP не поддерживается всеми браузерами, то  нужно держать пару WebP+JPEG/PNG.

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

 

WEbP заменяет собой сразу все форматы: и JPEG, и PNG.

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

Также он быстрее создается чем работает сжатие mozjpeg.

Создание пары WEbP + JPEG  будет быстрее в 2 раза чем сжатие JPEG  за счет mozjpeg.

 Шаблон не нужно переделывать.

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

 

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

 

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

Также у меня есть мысли как можно значительно улучшить качество картинок на экранах с высокой плотностью пикселей (Ретина и т.п.)

Сейчас ситуация такова, что движок вообще не предлагает никаких решений для отдачи качественного контента для качественных экранов.

Конечно, если это будет интересно.

 

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

Гугл за это ругает ваши сайты.

Есть у меня мысли и на этот счет.

 

[pmshirshov]

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

Пока WEbP не поддерживается всеми браузерами, то  нужно держать пару WebP+JPEG/PNG.

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

 

WEbP заменяет собой сразу все форматы: и JPEG, и PNG.

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

Также он быстрее создается чем работает сжатие mozjpeg.

Создание пары WEbP + JPEG  будет быстрее в 2 раза чем сжатие JPEG  за счет mozjpeg.

 Шаблон не нужно переделывать.

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

 

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

 

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

Также у меня есть мысли как можно значительно улучшить качество картинок на экранах с высокой плотностью пикселей (Ретина и т.п.)

Сейчас ситуация такова, что движок вообще не предлагает никаких решений для отдачи качественного контента для качественных экранов.

Конечно, если это будет интересно.

 

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

Гугл за это ругает ваши сайты.

Есть у меня мысли и на этот счет.

 

В итоге....
Что делать владельцам интернет магазина?
Какие действия применять?
Ждать готового решения в виде доработки или готового под это дело модуля или надо на хостинге что-то делать?

[stxgrupp]

Марк добрый день.

Вот мне прислали с Хостинга.

А вот скан с вашего модуля

Будет работать или нет.

У меня PHP 5.6,   HIGHT чистый

[Yoda]

Не надо натягивать шар на глобус и делать пиар на недостоверных фактах.

1 Гугл как любил так и любит нормальный jpeg.

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

3. Компрессор не мастхев от слова совсем. Так как оптимизация изображений по крону настраивается за десять минут и появляется более правильным решением чем тратить драгоценное ресурсы для сжатия "на лету. Я бы сказал что это не мастхев, а костыль для кривых хостингов, ещё и очень тррмознутый костыль.

 

Дальше могу продолжать очень долго. Но работу над ошибками делайте сами.

[rassigor]

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

Не надо натягивать шар на глобус и делать пиар на недостоверных фактах.

1 Гугл как любил так и любит нормальный jpeg.

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

3. Компрессор не мастхев от слова совсем. Так как оптимизация изображений по крону настраивается за десять минут и появляется более правильным решением чем тратить драгоценное ресурсы для сжатия "на лету. Я бы сказал что это не мастхев, а костыль для кривых хостингов, ещё и очень тррмознутый костыль.

 

Дальше могу продолжать очень долго. Но работу над ошибками делайте сами.

Вчера анализировал свой траф, примерно 30 % трафик старые браузеры, которые не держат новый формат. 

Насчет того, что сжатие должно быть налету, тоже согласен, по идее крон нужен и жать в фоне, так как разные бывают ситуации и из за тупки сайта, можно вылететь из индекса (у меня было такой(( очистил случайно кеш, 2 кнопки рядом, и потом настал АД)

Змінено 14 листопада 2018 користувачем rassigor

[markimax]

На "лету" оптимизация изображений обязана быть
Зачем ДдоСить свой магазин постоянно по крону

К примеру 100k товаров, а "выгрузкой" добавилось всего 10 товаров
Кеш оптимизированных изображений для 100k есть
Заново ДдоСить магазин и все изображения (а как разобрать это оптимизированные или нет)?
Нет.
На "лету" сгенерятся для тех 10 товаров при заходе юзеров (или ботов ПС) в те товары.

[pmshirshov]

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

На "лету" оптимизация изображений обязана быть
Зачем ДдоСить свой магазин постоянно по крону

К примеру 100k товаров, а "выгрузкой" добавилось всего 10 товаров
Кеш оптимизированных изображений для 100k есть
Заново ДдоСить магазин и все изображения (а как разобрать это оптимизированные или нет)?
Нет.
На "лету" сгенерятся для тех 10 товаров при заходе юзеров (или ботов ПС) в те товары.

Я на хостинг написал письмо по этому вопросу. Жду ответа. Если они реализуют то что было написано выше то получается всё равно нужно устанавливать будет модуль?

[rassigor]

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

На "лету" оптимизация изображений обязана быть
Зачем ДдоСить свой магазин постоянно по крону

К примеру 100k товаров, а "выгрузкой" добавилось всего 10 товаров
Кеш оптимизированных изображений для 100k есть
Заново ДдоСить магазин и все изображения (а как разобрать это оптимизированные или нет)?
Нет.
На "лету" сгенерятся для тех 10 товаров при заходе юзеров (или ботов ПС) в те товары.

тоже верно)))

короче у всех своя правда

[sitecreator]

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

В итоге....
Что делать владельцам интернет магазина?
Какие действия применять?

 

Оптимизировать изображения.

Можно использовать WebP (меньше нагрузка на процессор при создании, но нужно больше места на диске, т. к. нужна дублирующая пара WebP + JPEG). А можно использовать как универсальное решение сжатие от mozilla (mozjpeg), ресурсы (процессор, память) в момент создания жрет больше чем WebP, но не требует лишннно дискового пространства.  Ну и сжимаем PNG или используем (заменяем) к нему тоже WebP.  Но файлов PNG обычно мало бывает в общем случае, поэтому они особой погоды не делают.

 

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

WebP поддерживается на уровне 60%-75% по разным оценкам. 

 

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

 

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

 

Под алгоритм mozjpeg приспособлены как минимум 95% хост-площадок на общем хостинге и 100% любые VDS/VPS.

Т. е. на них он будет работать. Другое дело, что для mozjpeg нужно побольше ресурсов чем просто для подготовки JPEG движком опенкарт. Т. е. еще 5% хост-площадок на дешевых тарифах стоит исключить или пользователю нужно сменить тариф.  Т. е. нужно понимать, что чудес ждать не нужно - железо должно соответствовать. Но если товаров не очень много (например, < 3000),  то относительно слабые площадки справляются неплохо с нагрузкой от mozjpeg.

 

Просто заметил, что многие заказчики нагружают свой сервер зря из-за огромных исходников (прямиком из фотокамеры) 6000*4000 и т.п.

Но для решения этой проблемы я подготовил решение уже.

 

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

Поэтому даже от кратковременных тормозов (обычно наблюдаются в первые два дня), связанных с необходимостью очистки кеша для генерации нового сжатого, в Компрессоре 2+   уходим.

Все принципиальные моменты мною решены и протестированы.

 

И в Компрессоре 2+  не будет ограничений по использованию хост-площадки.   Сжатие будет работать на любой (сейчас на 95%...98%).

Будет снято требование на наличие exec, он не нужен.   Также создание WebP будет возможно даже в случае если не поддерживается графической библиотекой (GD, imagick).

[sitecreator]

55 минут назад, pmshirshov сказал:

Я на хостинг написал письмо по этому вопросу. Жду ответа. Если они реализуют то что было написано выше

 

на хостинге для сжатия mozjpeg нужен включенный exec.

это есть на 95%-98% на обычных хост-площадках.  и на 100% есть на VDS.

 

Для WebP не нужен exec.  Компрессор и так нормально работает если есть этот формат либо в GD, либо в imagick.

Но даже с одним imagick  можно весьма недурно уменьшить размеры изображений за счет Компрессора.

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

 

Кто ваш хостер?

В Компрессор 2+ будет снято ограничение на хост-площадки.  Работать будет на любой.

[sitecreator]

На сегодняшний момент поддержка WebP отсутствует в FireFox-е.

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

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

 

Т. е WebP быть!   Не зря же после официального заявления Mozilla о поддержке WebP и Гугл начинает уже настойчиво рекомендовать данный формат к всеобщему применению.

 

Нас это ждет уже в 2019-м,  Произойдет в 1-м или 2-м квартале 2019-го.

То, к чему так долго призывали большевики разработчики WebP, наконец то входит в нашу жизнь.

 

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

 

https://www.cnet.com/news/firefox-to-support-googles-webp-image-format-for-a-faster-web/

 

 

 

[sitecreator]

Как насчет поддержки WebP в IE от майкрософт?

Она таки есть в новом браузере от мелкомягких.

 

Итак, кто пока упирается? Есть такие? Есть Сафари....

 

В FF заявлена поддержка в 65-й версии.  Сейчас доступна для скачивания уже 64-я (бета) и 65-я (альфа). Судя по всему в начале 2019-го уже будет релиз.

 

https://caniuse.com/#feat=webp

 

 

[sitecreator]

На данный момент по общей статистике около 73% пользователей уже могут без проблем просматривать этот формат в своих браузерах:

 

 

А если говорить отдельно по мобильным устройствам (там где политика Гугла особенно жесткая в оценке сайта методами pagespeed), то уже сейчас поддержка выше 78%.

 

 

https://caniuse.com/#feat=webp

[rassigor]

Я вот чего не понел, ставлю я новый формат, если с фаерфокса заходят, ему пнг автоматом отдаст? или там дыра будет? 

Те сейчас это можно использовать, зная что не готово 30% интернета или нельзя?

[sitecreator]

Что же делать с Сафари?

Вот ему то можно скармливать JPEG 2000, ну раз не хочет Сафари WebP поддерживать.

Кроме Сафари никто из конкурентов не спешит его поддерживать.

 

Но не все просто и прямолинейно в этом мире. Не случайно же гугл советует JPEG 2000?

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

Так ли это станет известно после проведения мною тестов.

После выводов, сделанных на основе тестов, будет решен вопрос целесообразности внедрения в Компрессор возможности создания JPEG 2000.

 

Есть у меня большое подозрение, что гугл будет особенно благосклонен к сайту если тот будет отдавать пару WebP+JPEG 2000, т. е. всем 100% браузерам будут отдаваться только сжатые форматы изображений (в тех формата, которые они умеют читать).  Разумеется, что мы говорим о современных браузерах.

 

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

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

 

Пока, как видите, активно исследую данный вопрос.

 

 

[sitecreator]

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

Я вот чего не понел, ставлю я новый формат, если с фаерфокса заходят, ему пнг автоматом отдаст? или там дыра будет? 

 

Никаких дыр нет абсолютно.

заходите хоть с древнего IE6 19-ти летней давности.

 

Каждому браузеру будет отдана картинка, соответствующая сообразительности (IQ) этого браузера.

 

Без картинки не останется ни один браузер!

 

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

Те сейчас это можно использовать, зная что не готово 30% интернета или нельзя?

 

Можно!

И нужно!  Гугл не даст соврать.

 

Все современные браузеры получат тот формат, который они в состоянии показать. Ну а старички и хромые (не путать с Chrome! )  получат древний JPEG, например.

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

 

Зато получите благосклонность гугла. Тут  вроде бы не нужно ничего объяснять?

И что по сравнению с любовью гугла (и сокращением ненужного траффика) некоторое потенциальное увеличение необходимого дискового пространства?

Тем более, что большинство вообще на этот счет не заморачиваются, ведь закачивают исходники 6000*4000!

 

 

Но если у вас уже сжатые изображения (JPEG, PNG) за счет Компрессора, то, думаю, вам можно особо не волноваться.  У вас уже конкурентное преимущество есть перед другими сайтами.