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

[markimax]

А не спешат потому что, все объединились  и работают над новым форматом - контейнером, который будет общим и для изображений и для видео (и 4k тоже)
Причем по изображениям полностью формат готов. Он на много качественнее и сжимает лучше. Была летом статья о нем на 3dnews.
Так что webp и jpeg2000 "прошлый век"

[sitecreator]

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

 

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

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

 

Ну а мой универсальный плагин (в виде ocmod) подойдет вообще для любого случая.

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

С генерацией самого WebP и сейчас нет проблем, она заложена в Компрессоре.

 

 

[sitecreator]

17 минут назад, markimax сказал:

и работают над новым форматом - контейнером, который будет общим и для изображений и для видео (и 4k тоже)

 

да, я это знаю.

 

17 минут назад, markimax сказал:

Так что webp и jpeg2000 "прошлый век"

 

они и разработаны много много лет назад.

Но из-за всей этой бюрократии никак не могут быть внедрены.

 

WebP появился 9 лет назад.

А JPEG 2000 вообще в начале 2000-х. или конце 90-х. Тут даже название намекает. 

 

 

 

Бюрократы и прочие формалисты тормозят прогресс!

 

[sitecreator]

Для Гугла теперь не интересна абстрактная оптимизация картинок ради самой оптимизации (для галочки). И если у вас на странице несколько небольших картинок, то теперь гугл не обращает на них внимания.  Вспомните для сравнения его недавние  рекомендации сжать файл размером 1к и получить "выигрыш" в 150 байт.  Таких смешных рекомендаций больше нет.

 

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

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

 

Много картинок обычно бывает на странице "Категория", особенно если вы выводите сразу по 100 товаров, например. А у каждого товара к тому же бывает не только одно изображение, а еще дополнительное (меняется при наведении) или даже несколько таких.

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

 

 

 

 

 

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

 

Т. е. гугл сейчас оценивает полезный выигрыш, а не любой. 

 

 

 

 

 

 

В мобильной немного похуже. По вчерашним меркам (80+) я был в зеленой зоне.  Но поскольку сейчас зеленая - это 90+, то я пока не зеленый.

 

 

 

 

[sitecreator]

 

 

 

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

Точнее, с учетом нового требования для "зеленых" 90+ я в нее зашел.

 

Подходе делал комплексный.

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

Как раз за сжатие изображений гугл накинул несколько баллов, которые позволили получить зеленую оценку 90+.

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

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

Просто для этих конкретно изображений webp оказывается несколько эффективнее чем mozjpeg.

 

Но я если бы не использовал совсем никакого сжатия, то был бы в желтой зоне.

 

 

 

 

На странице продукта тоже оценка сейчас 90+.

тут потяжелее изображения чем на главной.

 

Для страницы "категория":

 

[sitecreator]

По изображениям на данный момент сделал важный вывод. В свете последних событий.

 

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

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

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

 

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

 

 

 

Вот фрагмент главной страницы реального сайта.

На ней объем  изображений равен 2 Мегабайта, а самих изображений более 100.

 

 

 

А теперь посмотрите как оценивает потенциальную оптимизацию гугл.

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

Обратите внимание на время (секунды),  которое пожирается изображениями.

 

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

 

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

 

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

[pmshirshov]

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

 

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

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

 

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

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

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

 

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

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

AdminVPS - https://my.adminvps.ru

[sitecreator]

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

AdminVPS

 

проблем не было.

[pmshirshov]

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

 

проблем не было.

Всё ещё раз перечитал и так как у меня нет администратора сайта, хочу спросить про покупку модуля, установку и настройку на хостинге?
Или в личку написать?

Ответ от хостинга сегодня получен:

Здравствуйте.
Спасибо за ожидание.
На Вашем сервере установлены нужные модули для работы с изображениями под webp:
cwebp: /usr/bin/cwebp
webp: /usr/include/webp

Можете воспользоватся инструкцией преобразования или сжатия по ссылке:
https://goo.gl/R7RX95
По этому вопросу рекомендуем обратится к разработчику сайта.
Проверьте, пожалуйста.

[sitecreator]

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

Всё ещё раз перечитал и так как у меня нет администратора сайта, хочу спросить про покупку модуля, установку и настройку на хостинге?

 

Нет никаких проблем с настройкой и установкой.

Выбираете нужную опцию при покупке.

+ 390 р.

 

если у вас VDS или обычный хостинг - это не принципиально, устанавливаю везде.

Пишите в личку, читайте личку.

 

 

[sitecreator]

 

 

 

В JPEG 2 Мегабайта

В WebP 828 Кбайт

 

Картинка большая и с огромным кол-вом мелких деталей.

 

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

WebP нужно открывать в браузере Chrome или в ACDSee (но не очень древнем).

kr2000x3000.webp

[dexion]

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

В JPEG 2 Мегабайта

В WebP 828 Кбайт

А jpeg 2мб это уже сжатый? Если да, сколько весил исходник? Если нет, сколько весит после сжатия?

На скрине uncompressed size 18мб - это исходник?

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

[sitecreator]

17 минут назад, dexion сказал:

А jpeg 2мб это уже сжатый?

 

нет, это несжатый. это исходник.

 

17 минут назад, dexion сказал:

18мб - это исходник?

 

это "чистый объем" после распаковки JPEG.  Не забывайте, что сам JPEG - это уже сжатый формат.  Просто ему далеко до современных форматов по уровню сжатия.

 

Для сравнения прикладываю этот же файл, сжатый за счет технологии mozjpeg.

Качество 90 (как и у webp).

 

Размер 799 К.

mozjpeg работает существенно дольше по сравнению с webP.  Это может иметь большое значение на общем хостинге.  Разница по времени примерно в 2.5-3 раза.

Поэтому на слабых хост-площадках я бы рекомендовал использовать в таком случае WebP.

Поддержка у хостеров на уровне 97%-98% будет с Компрессором 1.10 ()который сейчас готовится.

 

А пока можно пользоваться mozjpeg. тут такая же поддержка у хостеров на уровне 97%-98% при использовании сейчас актуальной версии Компрессора (1.9.1).

Собираюсь сделать в версии 2.0 поддержку у любого хостера. т. е. 100%.  Но эти оставшиеся 2%-3% требуют довольно серьезной работы.

[markimax]

mozjpeg отлично сжимает и преимуществ у webp нет, даже mozjpeg получше иногда сжимает
А вот optipng... сильно уступает webp
В основном "ошибки" PS про "современный формат" как раз по png (даже сжатому по optipng)
Так что меньше пользуйтесь png где не надо

[sitecreator]

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

mozjpeg отлично сжимает и преимуществ у webp нет

 

в плане степени сжатия, согласен, что нет.

webp потребляет меньше ресурсов при сжатии по сравнению с mozjpeg. Параметр времени здесь важен при создании.

 

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

А вот optipng... сильно уступает webp

 

и это верно.

К тому же optipng очень и очень медленно оптимизирует даже по сравнению с mozjpeg.  Т. е. тут webp работает как ракета.

 

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

 

Интересовался у заказчиков для чего так раздувают объем изображений за счет png.

Оказывается, что поставщики выдают картинки в PNG.

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

 

[markimax]

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

 

в плане степени сжатия, согласен, что нет.

webp потребляет меньше ресурсов при сжатии по сравнению с mozjpeg. Параметр времени здесь важен при создании.

 

Не критично совершенно, кеш изображений создается не так часто к примеру как файловый кеш opencart
И да optipng тормоз еще тот
Поэтому я бы рекомендовал вообще не пользоваться png. Ну разве что в лого (которое один раз можно и в ручную ужать, больше я не вижу где ему место. Пока FF и iOS не будут поддерживать webp - грош цена такому формату

 

[sitecreator]

Почему я поддерживаю WebP в том числе?

Вот потому:

 

 

Если у хостера отключен exec, то mozjpeg, optipng будут недоступны для оптимизации JPEG и PNG.

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

 

Т. е. на данный момент я могу предложить тот или иной способ сжатия на 99% хост-площадок.  В то время как mozjpeg будет доступен лишь на 95%.

Остаются хостинги (< 1%), на которых вообще ничего нет в плане работы с современными сжатыми форматами (вроде WebP ) и нет возможности использовать mozjpeg.

Да , и такие есть.  Самое простое - это сменить хостинг, тем более, что нормальных полно вокруг.  Тот же хостер Бегет предлагает за 90 руб хостинг, на котором есть все, что нужно.

Также планирую в версии Компрессор 2+ учесть и этот  1% несчастных хостеров.  Т. е. WebP будет работать и у них.

И тогда можно смело утверждать, что Компрессор 2+ будет поддерживать любую хост-площадку на 100%.

 

Нужно сказать, что и сейчас Компрессор даже на этих неудачных хост-площадках, на которых все отключено и которых менее 1%,  позволяет добиваться неплохих результатов.  Файлы будут меньше в любом случае по сравнению с их размерами, которые делает движок по умолчанию.  Как минимум, Компрессор умеет выкидывать мусор из изображений в таких случаях, уменьшать размер за счет грамотного включения/отключения прогрессивного JPEG и задания оптимального уровня качества. Если есть Imagick, то он и визуальное качество получше дефолтного способен сделать, и размер файла будет несколько меньше по сравнению с дефолтным.  Imagick создает JPEG своими встроенными продвинутыми алгоритмами, которые значительно лучше чем дефолтные JPEG. 

 

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

 

 

 

 

 

 

[dexion]

@sitecreator можно к вам за советом, как к эксперту по картинкам? Не в лс, т.к. думаю, что и другим эта информация будет полезна.

1) В каком же формате сейчас правильнее хранить картинки, если выбирать между png и jpg? В последнее время все больше вижу сообщений о том, что в png нет никакого смысла, кроме прозрачного фона. Понятно, что картинки товаров должны быть в jpg, вопрос про остальные картинки. Действительно ли это означает, что абсолютно все картинки, даже самые мелкие иконки "добавить в сравнение" и тд следует перевести в jpg?

2) Какие картинки следует объединять в спрайты в условиях http2? И нужны ли спрайты или лучше использовать lazyload? Например, у меня на странице доставки 10 иконок подгружаются lazyload'ом по 50мс на каждую при скролле страницы, а на другой аналогичные 10 иконок объединены в спрайт, который грузится 0.5с и весит соответственно в ~10 раз больше, чем 1 отдельно взятая. Вроде 50мс звучит гораздо лучше, чем 0.5с, но как же нагрузка на сервер?

[flaero]

@sitecreator заинтриговал выкаткой нового функционала и скидками на черную пятницу и мучает теперь всех тишиной

[sitecreator]

Сейчас готовится к выходу версия Компрессора 1.10.

Она в большей степени адаптирована под новые требования Гугла.

 

В ней есть режим, который не сильно нагружает процессор и память, т. е. экономятся ресурсы.

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

 

 

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

И все это при минимальной нагрузке.

 

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

Как многие заметили, то сжатие - это не единственное требование.

 

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

Вот пример:

 

 

 

 

На странице для мобильных загружаются такие же огромные изображения как на странице для PC.

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

 

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

 

 

 

Т. е. Компрессор будет делать гораздо больше чем сжатие.  А будет делать массу другой работы по оптимизации изображений.

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

 

 

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

 

Если в плане сжатия JPEG алгоритм mozjpeg дает отличный результат, хоть и при медленной обработке, то в плане оптимизации PNG у WebP все лавры победителя - он создает файл значительно меньшего размера по сравнению с сжатым за счет алгоритма OptiPNG файлом PNG, и не жрет ресурсы (OptiPNG крайне медленно работает).

Поэтому как бы вы не сжимали PNG, но гугл теперь (в новых реалиях) будет всегда им недоволен, т. к. размер он сравниваем с таким же по содержанию WebP.

Так что, я делаю в этом плане упор на WebP.

 

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

Поэтому Компрессор сделает все за вас.

 

К тому же только Компрессор умеет подбирать оптимальные параметры для PNG с целью минимизации размеров. Например, может грамотно использовать заказную палитру.  Это существенно снижает размер.  И этого невозможно добиться только использованием сжатия за счет OptiPNG. Это одно из конкурентных преимуществ Компрессора. Ваши баннеры, сделанные в PNG с использованием Компрессора будут максимально оптимизированы, простым сжатием вы этого не добьетесь.

 

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

 

Самое сложное в плане внедрения WebP - это не создание самих изображений, ту особых проблем нет, и компрессор это сделает на 99% хост-площадок, а в будущих версиях на 100% хост-площадок (не нужен exec, не обязательна поддержка WebP в библиотеках у хостера).  Сложное - это доставить в каждый браузер нужный формат.

Вот это также Компрессор берет на себя.   При использовании любого шаблона и на любой хост-площадке.

 

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

Прошу немного терпения.

 

 

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

Будет доступен немного позже, сразу после выхода Компрессора 1.10.

Гугл скорректировал мои планы.

 

[sitecreator]

В 21.11.2018 в 21:04, dexion сказал:

@sitecreator можно к вам за советом, как к эксперту по картинкам? Не в лс, т.к. думаю, что и другим эта информация будет полезна.

1) В каком же формате сейчас правильнее хранить картинки, если выбирать между png и jpg? В последнее время все больше вижу сообщений о том, что в png нет никакого смысла, кроме прозрачного фона. Понятно, что картинки товаров должны быть в jpg, вопрос про остальные картинки. Действительно ли это означает, что абсолютно все картинки, даже самые мелкие иконки "добавить в сравнение" и тд следует перевести в jpg?

 

мелкие иконки, как раз, будут лучше смотреться в png.  Хотя бы по той простой причине, что png - это формат без потерь и в нем мелкий текст не расползается как в jpeg.

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

 

Сами изображения товаров, разумеется, в подавляющем большинстве случаев нужно делать в jpeg.

 

PNG стоит использовать разумно. Про первую его особенност я сказал - это абсолютное  отсутствие потерь, вторая - это возможность использования прозрачности.

Но это все также есть в формате WebP, который при этом значительно меньше по весу.

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

 

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

 

В 21.11.2018 в 21:04, dexion сказал:

Какие картинки следует объединять в спрайты в условиях http2?

 

никакие.

можете забыть про эту методику 90-х.

 

[dexion]

@sitecreator спасибо за подробный ответ

[sitecreator]

Цитата

"гугл продолжает ругаться!"

 

Ну что тут сказать?

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

 

Лишь один  баннер (прямой ссылкой на исходник) на главной весом в 4.5 Мегабайт. И размером 3600 * 5400.

И он не один на главной.

 

вот оценка гугла для десктопной версии и для мобильной (тут полная печаль):

 

 

 

 

 

 

15 Мегабайт огромных картинок!!! Прямо из фотоаппарата  - и на главную!

Конечно можно сжать картинку 6000*4000.  Но толку? И зачем такой размер на сайте?

 

И потом удивляются почему Компрессор "потерял эффективность"?

Компрессор, конечно, многое умеет, но...   снизить вес картинки на главной размером 6000 * 4000 (весом 4.5 Мега) до приемлемого веса в килобайтах (десятках или сотнях на худой конец) не может.  Чудес не бывает.

 

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

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

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

Так почему же к собственным сайтам такое отношение?

Должен же быть разумный предел для изображений? Если завтра появится фотокамера не на 24 Мегапикс, а на 128 Мпикс, то будут запихивать на сайт фотки 20 000 * 15 000?

[yura1yura]

Будет ли дружить Ваш модуль с этим:

 

[sitecreator]

11 часов назад, yura1yura сказал:

Будет ли дружить Ваш модуль с этим:

 

Дружит с любыми модулями судя по статистике.

С менеджерами изображений проблемы не возникали.