Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

Recommended Posts

В 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 есть, кстати, весьма неплохое расширение для опенкарт, которое делает это в автоматическом режиме. От автора из Индии.

 

image_compressor_sitecreator_m.jpg

Надіслати
Поділитися на інших сайтах

  • 3 weeks later...

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

  • +1 1
Надіслати
Поділитися на інших сайтах

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

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

 

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

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

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

 

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

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

 

но...

Цитата

 

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

 

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

 

 

да уж...

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

 

image_compressor_sitecreator_m.jpg

 

  • +1 1
Надіслати
Поділитися на інших сайтах

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

 

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

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

 

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

 

4da848bd09.jpg

Надіслати
Поділитися на інших сайтах

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

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

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

 

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

 

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

 

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

 

 

Надіслати
Поділитися на інших сайтах

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

 

Надіслати
Поділитися на інших сайтах

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

Надіслати
Поділитися на інших сайтах


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

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

 

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

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

 

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

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

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

 

 

 

c28440edcc.jpg

 

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

 

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

 

1324009322.jpg

 

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

да всего 2%

 

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

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

 

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

 

3b64205b44.jpg

Надіслати
Поділитися на інших сайтах

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

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

 

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

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

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

 

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

 

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

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

 

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

 

Змінено користувачем sitecreator
Надіслати
Поділитися на інших сайтах

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

 

78c984028e8c46ffb8e89d3c570f9f4d.jpg03be27704fa14f669c07b48e3f4be09e.jpg

7b0588de69.jpg

eeb4dc2a54.jpg

 

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

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

Надіслати
Поділитися на інших сайтах

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

 

5a1027844ad64b789dbc0a290c46cb7e.jpg

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

 

e3707caf18.jpg

 

 

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

Надіслати
Поділитися на інших сайтах

 

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

 

ce185f91c2.jpg

 

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

Змінено користувачем sitecreator
Надіслати
Поділитися на інших сайтах

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

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

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

 

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

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

 

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

  • +1 2
Надіслати
Поділитися на інших сайтах

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

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

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

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

 

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

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

 

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

 

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

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

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

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

 

Змінено користувачем Blade
Надіслати
Поділитися на інших сайтах


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.  Разные енкодеры и друг другу не мешают.

Змінено користувачем sitecreator
  • +1 2
Надіслати
Поділитися на інших сайтах

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 у вас тоже должен быть в наличии. ну раз вы собирали из кодов разные штуки, то он у вас точно есть.

 

Спасибо

Надіслати
Поділитися на інших сайтах


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

/opt/mozjpeg/bin/

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

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

 

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

 

f28b72d00d.jpg

 

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

 

b9eae0dc6c.jpg

Надіслати
Поділитися на інших сайтах

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

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

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

 

 

d49f62dd15.jpg

 

 

6e2830fae9.jpg

 

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

 

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

 

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

 

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

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

 

8ce51dbb95.jpg

 

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

 

443a649925.jpg

 

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

 

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

 

image_compressor_sitecreator_m.jpg

  • +1 2
Надіслати
Поділитися на інших сайтах

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

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

 

 

 

 

 

 

fdea8756ab.jpg

 

 

 

 

19e0bf13b4.jpg

 

image_compressor_sitecreator_m.jpg

  • +1 2
Надіслати
Поділитися на інших сайтах

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

 

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

Самый простой - это использование в коде 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.

 

image_compressor_sitecreator_m.jpg

Надіслати
Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.