Google ругается на картинки в /image/cache

[sitecreator]

В 15.03.2017 в 18:43, florapraktik сказал:

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

 

О, да!  Это отдельная песня.

И что самое интересное, то Гугл не предлагает картинку весом в 1Мегабайт (png) переделать в jpeg весом 20К!

Хотя эта картинка (png) не имеет прозрачности, то смысла в png вообще нет никакого.

 

Вот, казалось бы, мог Гугл проанализировать эту картинку и дать, действительно, полезную рекомендацию как сделать меньше картинку на сотни килобайт за счет смены формата. Но нет, молчит, зато найдет jpeg, в котором можно сделать экономию в 909 байт!

 

В 15.03.2017 в 18:43, florapraktik сказал:

Ну, правда бывают сайты с огромными картинками в png.

 

Был у меня такой сайт. каждая картинка по 200К минимум на странице категория.  Перевел все их в jpeg.  каждая картинка уменьшилась раз в 10.

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

 

Т. е. на реальную оптимизацию Гуглу, порой, нет дела.  Если ваш HTML страницы уменьшится с 20 Мбайт до 10К, то он этого не заметит.  Зато заметит, что можно убрать пробелы в HTML и получить выигрыш в 49 байт.

 

Для перевода png в jpeg есть, кстати, весьма неплохое расширение для опенкарт, которое делает это в автоматическом режиме. От автора из Индии.

 

[halfhope]

Недавно Google открыла исходные коды части своих проектов. Среди них и JPEG-энкодер Guetzli, который используется при генерации рекомендаций в PageSpeed. 

• Репозиторий https://github.com/google/guetzli
• Для windows есть скомпилированный файл guetzli.zip. Помощь cmd /k guetzli /?

[sitecreator]

В 05.04.2017 в 07:19, halfhope сказал:

Недавно Google открыла исходные коды части своих проектов. Среди них и JPEG-энкодер Guetzli,

 

А вот это уже весьма интересно.

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

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

 

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

Теперь есть решение вроде бы.

 

но...

Цитата

 

Примечание: Гетцли использует большой объем памяти. Вы должны предоставить 300 МБ памяти на 1 Мбайт входного изображения.

 

Примечание: Guetzli использует значительное количество процессорного времени. Вы должны рассчитывать на использование около 1 минуты CPU на 1 MPix входного изображения.

 

 

да уж...

С гигабайтами исходных картинок это сколько ж работать то будет?

 

 

[sitecreator]

https://davidwalsh.name/jpeg-compression-guetzli

 

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

500 картинок общим весом 37 М - это исходные данные

 

150 минут для обработки...  2,5 часа непрерывной загрузки процессора...

 

[halfhope]

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

150 минут для обработки...  2,5 часа непрерывной загрузки процессора...

 

Поддерживаю, проверил, все еще работает, уже час. Все еще на первом изображении( Так что лучше использовать другой софт, либо прикупить небольшой мэйнфрейм)

[Kindzaza]

Вот этим пользуюсь https://css-ig.net/pingo.php

Гугл не ругается.

Спасибо, Otvet, как то поделился ссылкой.

[sitecreator]

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

Вот этим пользуюсь

 

можно, конечно, и так.

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

 

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

 

Раньше это работало на 100%, теперь же только примерно 50% картинок Пейдж Спид считает оптимизированными.

 

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

 

 

[markimax]

Пока не будет поддержки хостерами расширений или функционала оптимизаций - толку ноль
Я понимаю что своими дата центрами гугль может сжимать на лету картинки с супер сжатием, которое обычные хостеры будут сжимать часами
Перед тем как учить нас "копать" - надо дать хотя бы лопату, а не рассказывать что можно "эффективно" копать траншею экскаваторами Mitsui и вы обязаны все его купить. Если ты гугль такой умный - обяжи всех хостеров прикупить "Mitsui" а потом нас конечных пользователей "учи" своим parrot speed "уму разуму". И после этого прятаться за демагогией "green planet". Только вот пусть мне расскажут как это сжатие (в приросте всего ~10-15%) действует на CPU серверов и сколько при этом они потребляют и выделяют тепла. Если каждый клиент сервера будет делать "сжатый" ресайз, то я думаю не один хостер ляжет

 

[cyberkekc]

С оригинальными фотками проблема уже не стоит. Сжимаю еще лучше чем рекомендует гугль и очень быстро. Но вот что делать с ресайзами (категория например)?! Выше писали про библиотеку imagick. Может кто-то разьяснить что это? Она ставится на стороне хоста? Или в движок как-то внедряется?

[sitecreator]

7 минут назад, cyberkekc сказал:

Выше писали про библиотеку imagick. Может кто-то разьяснить что это? Она ставится на стороне хоста? Или в движок как-то внедряется?

 

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

И в библиотеке движка для изображений нужно тоже делать изменения.

 

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

Примерно в 50% случаев сейчас Гугл Пейдж Спид перестает ругаться на картинки.  Буквально полгода назад результат оптимизации был 100%.

[markimax]

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

С оригинальными фотками проблема уже не стоит. Сжимаю еще лучше чем рекомендует гугль и очень быстро. Но вот что делать с ресайзами (категория например)?! Выше писали про библиотеку imagick. Может кто-то разьяснить что это? Она ставится на стороне хоста? Или в движок как-то внедряется?

Можете забыть про неё - гугл будет и на неё уже "ругаться"

[sitecreator]

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

Можете забыть про неё - гугл будет и на неё уже "ругаться"

 

да, уже не прокатит на 100%. Попугаев могут и не добавить. 

Простой анализ конкретной  страницы.

Вместо 100% оптимизированных картинок в прошлом году теперь гугл считает оптимизированными лишь 30% на конкретной странице.  На разных страницах по-разному.  Эффективность в пределах 30%...70% на разных страницах.

 

 

 

 

Объем всех загруженных данных 2552 Кб.

 

Что же нам советует PS?

 

 

Каков же выигрыш в % от общего объема всего загруженного контента?

да всего 2%

 

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

Не исключено, что через полгода или год Гугл опять будет недоволен даже если вы сейчас сделаете оптимизацию на 100% супер-пупер новым алгоритмом (потратив тонну солярки/газа/угля на выработку электроэнергии). А недоволен может быть тем, что JPEG вообще устарел и вы не используете новый супер-сжимаемый формат от Гугла, называемый WebP.

 

Сейчас супер-оптимизация JPEG позволяет достичь выигрыша в 17%,  а в новом формате 40%!  так что ничто не заставит Гугл отказаться от возможности вас поругать за картинки!

 

[sitecreator]

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

Можете забыть про неё - гугл будет и на неё уже "ругаться"

 

Как раз только он и способен дать реальный результат, который не снился JPEG и Guetzli .

ImageMagick умеет работать с WebP.  А это несоизмеримо лучший формат чем JPEG в плане сжатия без потерь.  Он обгонит Guetzli  как сверхзвуковой самолет черепаху.

И никаких тонн сожженного мазута/газа/угля для получения супер-результата по сравнению с алгоритмом от Гугла для JPEG (Guetzli ).

 

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

 

Зачем нам эти ненужные компромиссы и полумеры? давайте использовать действительно передовые технологии!

И гугл не посмеет ругаться на свой передовой формат.

 

Можно и в Опенкарт ввести этот передовой формат.  И даже поддержку для непонимающих браузеров можно предусмотреть. Для них можно оставить дубли в JPEG.

 

Змінено 7 квітня 2017 користувачем sitecreator

[sitecreator]

Исследование вариантов.

 

 

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

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

[sitecreator]

Получил хороший результат

 

https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fimage.prntscr.com%2Fimage%2F5a1027844ad64b789dbc0a290c46cb7e.jpg

 

 

 

Сжато с качеством 80 на сервере (Centos 7) c помощью mozjpeg (cjpeg)

[sitecreator]

 

данную библиотеку ( mozjpeg ) можно использовать совместно с gd вместо libjpeg. Переделка опенкарт даже не потребуется. Но этот вариант доступен тем у кого есть VDS.

 

 

Данная библиотека совместима на бинарном уровне со стандартной libjpeg. И содержит файлы с такими же названиями.

Змінено 8 квітня 2017 користувачем sitecreator

[sitecreator]

Заменил стандартную библиотеку libjpeg на mozjpeg.

код опенкарт не менял.

в image.php пробовал качество от 80 до 85

 

Гугл не ругается!  Все картинки принял!

И никакой ручной работы. Опенкарт делает все автоматически.

 

Попугайчики пляшут от радости.

[Blade]

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

Заменил стандартную библиотеку libjpeg на mozjpeg.

код опенкарт не менял.

в image.php пробовал качество от 80 до 85

 

Гугл не ругается!  Все картинки принял!

И никакой ручной работы. Опенкарт делает все автоматически.

 

Попугайчики пляшут от радости.

 

можно пару вопросов,  процедура установки какая ?

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

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

в случае наличия на сервере imagick и обработкой картинок им в опенкарте, будет смысл ставить mozjpeg ? не будет ошибок (не знаю каких, просто из за двух библиотек по сжатию ) ?

 

Змінено 8 квітня 2017 користувачем Blade

[sitecreator]

28 минут назад, Blade сказал:

просто на сервере меняем одну библиотеку на другую

 

именно так.

Имена исполняемых файлов у них одинаковые.

28 минут назад, Blade сказал:

оптимизация происходит автоматом в момент создания кеша

 

да

28 минут назад, Blade сказал:

в случае наличия на сервере imagick и обработкой картинок им в опенкарте, будет смысл ставить mozjpeg ?

 

тут нужно подумать. imagemagick использует иной енкодер для jpeg.  Поэтому когда используете gd (она использует libjpeg) и imagick с одинаковым показателем качества (например, 80), то на выходе получаются разные jpeg.

 

Сборка mozjpeg сложностей не вызывает (Centos)

 

yum install autoconf automake libtool nasm make pkg-config git
git clone https://github.com/mozilla/mozjpeg.git
cd mozjpeg
autoreconf -fiv
./configure
make

make install

после завершения основные файлы здесь:

 

/opt/mozjpeg/bin/

 

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

 

Цитата

не будет ошибок (не знаю каких, просто из за двух библиотек по сжатию ) ?

 

у меня на сервере один сайт на опенкарт с imagick работает и картинки сжаты одним енкодером JPEG, а другой сайт с GD и mozjpeg.  Разные енкодеры и друг другу не мешают.

Змінено 8 квітня 2017 користувачем sitecreator

[Blade]

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

 

именно так.

Имена исполняемых файлов у них одинаковые.

 

да

 

тут нужно подумать. imagemagick использует иной енкодер для jpeg.  Поэтому когда используете gd (она использует libjpeg) и imagick с одинаковым показателем качества (например, 80), то на выходе получаются разные jpeg.

 

Сборка mozjpeg сложностей не вызывает (Centos)

 

yum install autoconf automake libtool nasm make pkg-config git
git clone https://github.com/mozilla/mozjpeg.git
cd mozjpeg
autoreconf -fiv
./configure
make

make install

после завершения основные файлы здесь:

 

/opt/mozjpeg/bin/

 

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

 

Спасибо

[sitecreator]

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

/opt/mozjpeg/bin/

скопировать (с заменой) в

usr/local/bin/    (по умолчанию здесь исполняемые файлы libjpeg)

 

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

 

 

По идее в usr/local/bin/ можно было бы ограничиться созданием ссылок на одноименные файлы в /opt/mozjpeg/bin/

[sitecreator]

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

Мне подошел 80...85

 

На картинках довольно много мелких элементов (трава, листья...)

 

[sitecreator]

Сегодня еще поэкспериментировал с mozjpeg .  Результаты просто отличные.

Если исходник четкий и не замылен , то у гугла никаких претензий к степени сжатия.

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

 

 

 

 

 

Никаких претензий у гугла к этим фотографиям теперь нет.

 

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

 

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

 

Но если у вас исходники с более-менее равномерным качеством, то достаточно подобрать один раз задаваемый в image.php уровень качества.

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

 

 

Вот из такого изначально замыленного источника при качестве сжатия =80 не получается получить картинку, удовлетворяющую Гугл.  По вышеназваным причинам.

 

 

А вот с таким четким исходником никаких проблем нет!

 

Это я написал к тому, что наверняка найдутся люди, которые напишут, что метод не работает.  И проверять они, вероятно, будут на тестовых товарах из дефолтного движка.  А там часть исходников просто замылена из-за очень высокого уровня сжатия.  Ну что можно ожидать от картинки 440*300 и весом всего 8 Кб?

 

[sitecreator]

Немного статистики с реального сайта.

На одну страницу вывел 1000 товаров. Соответственно столько же картинок общим весом более 6 Мбайт.  Из всех картинок гуглу не понравились лишь 14 картинок, которые он предложил сжать еще на 8 Кбайт.  Т. е. выигрыш мог бы составить 0.1% от общего веса картинок.  Это уже за гранью статистических погрешностей.

 

 

 

 

 

 

 

 

 

 

 

[sitecreator]

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

 

Я сам пробовал (и успешно) реализовать на сервере три разных способа.

Самый простой - это использование в коде php (движка) exec для запуска cjpeg (енкодер).

 

Второе - это сборка своего php с включенным (на этапе сборки "--with-gd") gd.  соответственно mozjpeg будет уже интегрирован.

 

И третье - это сборка отдельно расширения gd.so с mozjpeg  вместо стандартной libjpeg. это я проделал для php 7.

 

Все три способа работоспособны. два последних не требуют изменения в опенкарте.  Но требуют сборки php или его модуля из исходных кодов.  Исходники таких библиотек как libpng (truetype и т.д.) также необходимы иначе GD будет собран с поддержкой только jpeg.

 

Собрать из исходников php 5.4 на сегодня весьма затруднительно, т. к. исходников уже нет на официальном сайте, ибо версия считается устаревшей.

Поэтому я экспериментировал с 5.6 и 7.0 версиями.  Тем, кто использует только 5.4 остается универсальный способ через exec (с изменением кода движка).

Сборка из исходников требует полного понимания процесса.  Постараюсь сделать инструкцию по сборке кастомных php и gd.so.