sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
"от дурака" некоторые опции закрыты до прочтения информации о том как необходимо правильно выбирать режим работы сжатия чтобы не было потом "мучительно больно". Не надо врубать режим OptiPNG с уровнем 5 (6-й я вообще убрал от дураков подальше, ибо он работает раз в 20 медленнее среднего) если у вас сплошь в магазине изображения PNG по 12 Мбайт в исходниках. Если хотите, то выбирайте, но это будет ваш осознанный, хоть и неадекватный поставленной цели выбор. Ибо таким режимом вы просто положите на лопатки ваш сайт, израсходовав сразу 100% мощности и процессора, и памяти. -
При обновлении до версии 1.12.6+ нужно проявить внимание! Внедрена защита "от дурака". Начиная с этой версии вы должны подтвердить, что прочитали "предупреждение" в настройках модуля установкой галочки Если вы не подтвердите, что прочитали "предупреждение", то у вас останутся заблокированы для выбора три опции: - mozjpeg для JPEG "на лету" (!) - OptiPNG для PNG "на лету" (!) - Сравнение размеров файлов ДО и ПОСЛЕ Суперсжатия И даже если в этих заблокированных опциях стояли ранее галочки, то при нажатии "сохранить" данные опции скинутся в настройки по-умолчанию, т.е. в состояние "отключено". Поэтому обязательно прочитайте текст с заголовком "ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ", осмыслите его, установите нужную галочку и нажмите "сохранить". Все прежние настройки не пропадут. Сделано это специально чтобы вы полностью осознавали свои действия и отвечали за них. Чтобы не было бездумной установки галочек и всех параметров "на максимум".
-
Как избежать тормозов во время создания сжатых изображений?
sitecreator posted A Tutorial in Tutorials
Пояснение к тому как работают разные режимы сжатия. Как избежать тормозов при создании сжатых изображений? Довольно просто, нужно прочитать приведенный ниже текст и воспользоваться логическим мышлением. Если есть сомнения, то не надо спешить ставить все подряд галочки в надежде, что чем больше галочек, то тем лучше! Спросите автора какой лучше выбрать режим. Если у вас VDS на 8 ядер и 32М оперативки, то создать тормоза вам практически не удастся. Проверено на опыте когда на сервере было изображений 150 ГИГабайт!!! Если общий хостинг или слабый VDS, то давайте задание, соразмерное мощности вашей площадке! Создание WEBP даже "на лету", даже в форсированном режиме не может привести к излишнему повышению нагрузки на сервер. Рекомендуется как универсальный вариант. При обновлении до версии 1.12.6+ нужно проявить внимание! Внедрена защита "от дурака". Начиная с этой версии вы должны подтвердить, что прочитали "предупреждение" в настройках модуля установкой галочки Если вы не подтвердите, что прочитали "предупреждение", то у вас останутся заблокированы для выбора три опции: - mozjpeg для JPEG "на лету" (!) - OptiPNG для PNG "на лету" (!) - Сравнение размеров файлов ДО и ПОСЛЕ Суперсжатия И даже если в этих заблокированных опциях стояли ранее галочки, то при нажатии "сохранить" данные опции скинутся в настройки по-умолчанию, т.е. в состояние "отключено". Поэтому обязательно прочитайте текст с заголовком "ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ", осмыслите его, установите нужную галочку и нажмите "сохранить". Все прежние настройки не пропадут. Сделано это специально чтобы вы полностью осознавали свои действия и отвечали за них. Чтобы не было бездумной установки галочек и всех параметров "на максимум". "от дурака" некоторые опции закрыты до прочтения информации о том как необходимо правильно выбирать режим работы сжатия чтобы не было потом "мучительно больно". ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ! Рекомендуется использовать WEBP в качестве сжатого формата (для JPEG, PNG). WEBP создается быстро, не требует очистки кеша изображений, т.е. не создает лишней нагрузки во время создания. MOZJPEG требует для создания сжатого JPEG очистки кеша изображений, работает примерно в 3 раза медленнее при создании чем WEBP, что вызывает временно (только в момент создания) повышенную нагрузку на сервер. Если вы не обладаете достаточной мощностью сервера, то используйте только создание WEBP, это обеспечит минимальную нагрузку на сервер во время создания сжатых изображений. OPTIPNG работает на порядок дольше при создании сжатого PNG чем WEBP, а по эффективности в плане веса сильно уступает WEBP. Включайте осознанно этот режим. Если у вас есть сомнения и вы не хотите создавать (хоть и временные) тормоза сайта, то используйте только WEBP. ВНИМАНИЕ! Повышенное потребление ресурсов сервера происходит только в момент создания изображения, как только изображения созданы, то потребление ресурсов приходит в обычную норму. Если работает режим "на лету", то это значит, что изображения создаются при перовм или втором открытии страницы, именно в этот момент страница открывается дольше привычного. Далее страница открывается как обычно с привычной скоростью. С целью экономии ресурсов сервера не рекомендуется включать одновременно создание MOZJPEG, OPTIPNG и WEBP. Всегда включайте создание WEBP позже, этот формат может быть создан в любой момент. Если решили использовать MOZJPEG, OPTIPNG, то пусть сперва отработают эти алгоритмы и будет создан кеш сжатых JPEG, PNG. Как только нагрузка по созданию нового сжатого кеша упадет, то тогда можно включать режим создания WEBP. Если у вас мощности сервера достаточно, то тогда допускается одновременное включение MOZJPEG и создание WEBP. Если видите, что сервер тяжело справляется, то отключите тяжелые режимы. Выбор правильной стратегии сжатия и верных настроек обеспечит комфортный режим работы вашего сайта. Наоборот, бездумное выставление всех галочек может привести к временным "тормозам" вашего сайта. Включение режима "Сравнение размеров" на постоянной основе недопустимо! Это приводит к повышенной нагрузке и бесполезной трате дискового пространства! Если изображения созданы (находятся в кеше), то далее модуль Компрессор практически никак уже не влияет на скорость открытия страницы. Кеш изображений создается только один раз. На это требуется некоторое время. Замедление открытия страницы во время создания изображений "на лету" - это нормально. Чудес не бывает, работа с графикой - не мгновенная операция, а потому процессору требуется время чтобы создать и сжать новые изображения. Это (замедление) происходит лишь единожды во время первого (второго) открытия страницы. Режим создания изображений "по расписанию" вообще не приводит к тормозам страницы, т.к. вся нагрузка по такому созданию распределяется равномерно. -
Пояснение к тому как работают разные режимы сжатия. Как избежать тормозов при создании сжатых изображений? Довольно просто, нужно прочитать приведенный ниже текст и воспользоваться логическим мышлением. Если есть сомнения, то не надо спешить ставить все подряд галочки в надежде, что чем больше галочек, то тем лучше! Спросите автора какой лучше выбрать режим. Если у вас VDS на 8 ядер и 32М оперативки, то создать тормоза вам практически не удастся. Проверено на опыте когда на сервере было изображений 150 ГИГабайт!!! Если общий хостинг или слабый VDS, то давайте соразмерное задание мощности вашей площадке! Создание WEBP даже "на лету", даже в форсированном режиме не может привести к излишнему повышению нагрузки на сервер. Рекомендуется как универсальный вариант. ОБЯЗАТЕЛЬНО К ПРОЧТЕНИЮ! Рекомендуется использовать WEBP в качестве сжатого формата (для JPEG, PNG). WEBP создается быстро, не требует очистки кеша изображений, т.е. не создает лишней нагрузки во время создания. MOZJPEG требует для создания сжатого JPEG очистки кеша изображений, работает примерно в 3 раза медленнее при создании чем WEBP, что вызывает временно (только в момент создания) повышенную нагрузку на сервер. Если вы не обладаете достаточной мощностью сервера, то используйте только создание WEBP, это обеспечит минимальную нагрузку на сервер во время создания сжатых изображений. OPTIPNG работает на порядок дольше при создании сжатого PNG чем WEBP, а по эффективности в плане веса сильно уступает WEBP. Включайте осознанно этот режим. Если у вас есть сомнения и вы не хотите создавать (хоть и временные) тормоза сайта, то используйте только WEBP. ВНИМАНИЕ! Повышенное потребление ресурсов сервера происходит только в момент создания изображения, как только изображения созданы, то потребление ресурсов приходит в обычную норму. Если работает режим "на лету", то это значит, что изображения создаются при перовм или втором открытии страницы, именно в этот момент страница открывается дольше привычного. Далее страница открывается как обычно с привычной скоростью. С целью экономии ресурсов сервера не рекомендуется включать одновременно создание MOZJPEG, OPTIPNG и WEBP. Всегда включайте создание WEBP позже, этот формат может быть создан в любой момент. Если решили использовать MOZJPEG, OPTIPNG, то пусть сперва отработают эти алгоритмы и будет создан кеш сжатых JPEG, PNG. Как только нагрузка по созданию нового сжатого кеша упадет, то тогда можно включать режим создания WEBP. Если у вас мощности сервера достаточно, то тогда допускается одновременное включение MOZJPEG и создание WEBP. Если видите, что сервер тяжело справляется, то отключите тяжелые режимы. Выбор правильной стратегии сжатия и верных настроек обеспечит комфортный режим работы вашего сайта. Наоборот, бездумное выставление всех галочек может привести к временным "тормозам" вашего сайта. Включение режима "Сравнение размеров" на постоянной основе недопустимо! Это приводит к повышенной нагрузке и бесполезной трате дискового пространства! Если изображения созданы (находятся в кеше), то далее модуль Компрессор практически никак уже не влияет на скорость открытия страницы. Кеш изображений создается только один раз. На это требуется некоторое время. Замедление открытия страницы во время создания изображений "на лету" - это нормально. Чудес не бывает, работа с графикой - не мгновенная операция, а потому процессору требуется время чтобы создать и сжать новые изображения. Это (замедление) происходит лишь единожды во время первого (второго) открытия страницы. Режим создания изображений "по расписанию" вообще не приводит к тормозам страницы, т.к. вся нагрузка по такому созданию распределяется равномерно.
-
Еще раз простая информация про jpegoptim. (хоть это к модулю Компрессор и не относится) данный софт НЕ сжимает изображения. В том смысле в каком мы этого ожидаем, например как mozjpeg, google/guetzli, WEBP. Compressing, конечно jpegoptim умеет делать как и абсолютно любой алгоритм создания JPEG, ибо JPEG - это и есть по определению сжатый формат, в нем всегда используется Compressing. Сохранение файла в формате JPEG всегда сопровождается сжатием, и сохранение файла всегда будет называться "compressing" по-английски. Другое дело, что не каждый алгоритм способен сжать JPEG серьезно сильнее стандартного сжатия. Выше перечислены "реально сжимающие" алгоритмы. Все, что jpegoptim умеет делать - это выкинуть метаданные из файла, плюс сделать прогрессивный JPEG из НЕпрогрессивного. Только за счет этого возможно некоторое уменьшение веса. Таблицу Хаффмана jpegoptim оптимизирует плохо, в некоторых случаях вы получите за счет этого выигрыш в 1%-5%, но чаще будет близко к 0%, это на практике, поэтому это больше для галочки и не стоит от этого ждать чуда. Довольно странно слышать предложение "запустить jpegoptim" после обработки imagick. А зачем? Вопрос, конечно, риторический. Просто сам imagick (imagemagick) способен создавать прогрессивный JPEG (что он и делает по-умолчанию), а также выкидывать метаданные. Есть в imagemagick и режим оптимизации таблиц Хаффмана, эффективность сродни jpegoptim, т.е. близка к нулю на реальных изображениях. Спрашивается, а какой уровень знаний в области графики тех людей, которые советуют "оптимизировать" за счет jpegoptim после того как imagick уже выдал оптимизированную картинку? С эффективностью mozjpeg или WEBP алгоритм jpegoptim не идет ни в какое сравнение. Если mozjpeg или WEBP - это конкурирующие технологии, и по эффективности снижения веса JPEG они близки, то jpegoptim крайне сильно от них отстает, хоть тоже умеет оптимизировать JPEG. Все познается в сравнении. И, да, после того как imagick уже оптимизировал изображения за счет: 1) прогрессивный формат, 2) удаление метаданных, 3) оптимизация таблиц Хаффмана программе jpegoptim уже просто нечего делать, все уже сделал imagemagick. С одной оговоркой - если сделаны правильные настройки imagemagick. и не в любом бесплатном модуле с поддержкой Imagick вы встретите правильные настройки. И другое дело если некоторые господа просто не знают как работать с imagemagick. Впрочем, как работать и какими средствами - это дела каждого. Каждый волен творить как ему нравится. Вот только навязывать свои навыки и теоретические представления как единственно правильные всем и каждому - это дело сомнительное.
-
Для примера беру любой магазин, работающий с Компрессор 1.12.*. Товаров 7300+ главная страница в пределах 300 мс, что с отдачей webp, что без нее (для прочих и старых браузеров). Страница Категория с фильтром и пр. 218 мс делаю на странице вывод сразу 180 товаров. Страница загружается за 490 мс. На скриншоте видно, что работает модуль Компрессор и отдается в браузер WEBP. Это данные реального магазина. Никаких проблем со скоростью формирования страницы нет. И заказчики не дадут соврать.
-
Новая версия 1.12.5 доступна для скачивания. Улучшения коснулись обработки исключений для водяного знака. А также улучшена работа формирования и отдачи изображений WEBP средствами модуля. Известны на данный момент отдельные сложности с WEBP Lazy Load на некоторых шаблонах. Вопрос отчасти решается несложным индивидуальным редактированием lazyload_start_alt.js. Некоторые пояснения для редактирования имеются в самом файле JS. В следующих версиях обновлю JS для более полной поддержки разнообразных шаблонов. Прошу отнестись с пониманием, что сделать абсолютно универсальный WEBP Lazy Load, который бы подходил сразу для всех шаблонов, да еще в любой комбинации с модулями вроде "баннеры-слайдеры супер-паралакс" (и т.п.) довольно затруднительно. Поэтому нередко просто требуется индивидуальная адаптация. Она не входит в базовую установку/настройку, но если я не вижу сложностей, то я ее делаю сразу, прошу не воспринимать это как мою обязанность, но всего лишь как знак доброй воли.
-
Любой желающий может проверить скорость загрузки моей страницы. 150 мс. http://watermark.sitecreator.pro/index.php?route=product/category&path=20 Сравните с аналогичной страницей демо-ocstore: 350-500 мс. и соответствующая оценка гугла демо-ocstore: "Пагубное" влияние на скорость модуля "Компрессор" заметно во всей красе.
-
Правильно говорите. Причем, что самое смешное, то "чудесное" решение замечательно умеет оставлять Сафари (и все браузеры на iOS) и заодно старые браузеры вообще без картинок. Видать, они еще не тестировали.... Но какое нам дело до этого? Нравится, да и пусть пользуется. Странно, что человек со своим бревнышком в глазу таскается повсюду в поисках песчинок у других. Заказчики не дадут соврать, что ни одно обращение в поддержку модуля не остается без внимания. Каждый случай конкретно рассматривается и всегда предлагается помощь. Тема поддержки модуля - не место для срача и рекламы непонятного стороннего изделия с кучей багов.
-
Сайт 10 000 товаров. У каждого товара по 20+ изображений. Плюс еще 10+ изображений в тексте описания. Работа с включенным модулем Компрессор (и вывод WEBP). Используется одновременно с обрезкой фона у исходных изображений, с наложением водяного знака и т.д. Кроме того еще и обычные изображения JPEG, PNG сжаты. И скорость открытия страницы 250 мс. Разумеется, когда кеш изображений готов. Вот с полностью отключенным модулем Компрессор, видно, что изображения отдаются в формате JPEG вместо WEBP. Время открытия страницы 225 мс - 315 мс. Т.е. практически такое же как и с включенным модулем Компрессор. (не берем в расчет первое открытие, тут некешированные данные, похоже) Страница товара. Не менее 33 изображений к товару, не считая изображений цветов, с ними больше 40 картинок будет для товара. Сам по-себе шаблон сложный, и страница HTML весит по 350К и более. Но Компрессор, выводя WEBP не приводит к тормозам. Возможно, что все дело в том, что заказчик просто умеет работать? В том, что заказчик умеет общаться и умеет спрашивать разработчика как лучше организовать создание и отдачу сжатого формата в браузер? Актуальная версия модуля Компрессор создает WEBP очень быстро, практически незаметно даже в режиме форсированного "на лету". При этом можно даже нагрузку на сервер регулировать. Вплоть до задания работы по расписанию. В любом деле нужен грамотный подход. Недавно я встретил случай, когда у заказчика стандартный механизм по работе с изображениями (опенкарт) не мог создать из исходника изображение для кеша. Fatal error происходил. Видимо, нужно было ругать создателя опенкарт? Но анализ показал, что Fatal error возникал из-за нехватки памяти, т.к. вес исходника (PNG 4000х3000) составил 11.5 Мегабайт. Страница Товар:
-
Вы умеете помечать как-то сами изображения? Даже если представить, что будем маркировать каким-то тегом, то как вы его собираетесь увидеть? Файловые менеджеры (серверные) не способны показать такую информацию, фтп - тоже самое. И установить через них невозможно.
-
Здравствуйте. Движок опенкарт не различает для какой цели вы используете изображения. Единственный критерий для него - это геометрический размер изображения. Модуль позволяет вам выборочно накладывать водяной знак. Вы можете настроить исключения (чтобы не накладывать). Например, по геометрическому размеру. Добавляйте в таком случае исключения для отдельных файлов. Или исключения по размерам. Обычно для категорий изображения не бывают большими. Или просто добавляйте к названию nowatermark
-
версия модуля 1.12.4 доступна
-
верно сам движок опенкарт ничего не умеет сжимать. Он создает обычный формат JPEG. И при дефолтном качестве 90 движок за счет библиотеки GD создает изображения с хорошим качеством. исключение - это когда из меньшей картинки делается бОльшая. Тогда появляется пикселезация. Модуль Компрессор за счет использования графической библиотеки imagick позволяет получить качество несколько выше. К тому же Компрессор позволяет убрать проблему преобразования маленького исходника в большое (по геометрии) изображение в кеше. Сжимать их вовсе необязательно. Как минимум сейчас 80% браузеров понимают WEBP. Если говорить про мобильные, то это любые современные браузеры для Андроид. Остается в стороне только Сафари. Но если хочется, то сжимайте JPEG.
-
mozjpeg и WEBP - это конкурирующие технологии. Только WEBP создается очень быстро, а mozjpeg раза в три дольше. Поэтому если мощность сервера позволяет, то включайте mozjpeg. На слабом сервере при включении mozjpeg будут обеспечены тормоза, хоть и временные, и даже возможно, что для генерации изображений может не хватить отведенных 30 сек (по умолчанию). А вот WEBP будет создан практически незаметно с точки зрения повышения нагрузки на сервер. Т.е. всегда подходите разумно к выбору стратегии сжатия изображений. Если мощности много, то и позволить вы можете себе многое.
-
ради webp это делать не нужно. конечно, можно не включать ни mozjpeg, ни optipng. И если нет желания создавать лишнюю нагрузку на сервер, то и не рекомендуется включать. У вас же JPEG и PNG создаются в любом случае, хоть и не сжатые. Вот из них и в дополнение к ним будет создан webp. Но когда непременно хочется создать еще и сжатый jpeg, то сперва рекомендуется создавать именно сжатый jpeg за счет mozjpeg. А уже потом включать webp. Так вы разнесете нагрузку по времени. optipng вообще не рекомендую включать. Технология optipng крайне медленная, а вес снижается всего на 20%. лучше не гоняйте впустую процессор когда есть более прогрессивная технология WEBP.
-
а какая разница сколько фото у товара? И, тем более, что они у вас уже есть. Один раз очистили кеш турбы, далее создались WEBP для ваших jpeg и png. ВЫ же очищаете кеш турбы целиком, а не для одной страницы. Но можете для каждой страницы нажимать если вам так нужно. В новой версии 1.12.4 есть режим "Форсированный на лету" для тех, кто не хочет думать когда и чего нужно очищать в ускорителях. Если вы не будете очищать уже созданный кеш изображений, то этот режим не создаст большую нагрузку на сервер. Для формирования WEBP не нужно очищать кеш изображений! очищайте кеш только для WEBP если вам надо создать заново по какой-либо причине WEBP.
-
Итак, есть новая версия 1.12.4 Позволяет корректно формировать WEBP и выводить его также корректно на страницу, подготовленную для работы с экранами Retina. Т.е. когда используется не просто тег <img> с одним изображением, а используется набор изображений imageset (для обычного экрана, для экрана с повышенной плотностью пикселей). Пока такое встречал только в шаблоне Journal 3. И модуль Компрессор работает с этим шаблоном в плане WEBP. Про Lazy Load для этого шаблона пока не могу сказать наверняка. Там есть встроенный Lazy Load (и для Retina тоже) , предполагаю, что он будет работать совместно с моим WEBP. Проверю позже. Проверил. Работает нормально Lazy Load от Journal 3 совместно с моим WEBP, нормально включая экраны Retina тоже. Вывод WEBP обеспечивается за счет функционала модуля. Даже с таким сложным и очень нестандартным шаблоном.
-
Какой выбрать режим (стратегию) для создания сжатых изображений?
sitecreator posted A Tutorial in Tutorials
Какой выбрать режим (стратегию) для создания сжатых изображений? Если ничего не понимаете и не хотите вникать в тонкости процесса, то выбирайте только WEBP. Если хостинг слабоват, а товаров много (более 2000), то рекомендуется в качестве сжатого формата изображений использовать только WEBP, при этом не надо очищать уже существующий кеш изображений. Так вы не будете создавать лишней нагрузки на сервер. И создание WEBP произойдет практически без заметных на глаз тормозов страниц даже в режиме создания "на лету". Этот режим нормально работает даже в случае большого кол-ва товаров (> 10 000). Обычно для 10 000 товаров формируются не менее 30 000 картинок в кеше даже если у товара всего по одному изображению, т.к. формируются разные картинки по геометрическим размерам. Соответственно, если у товара в среднем 3 картинки, то для 10 000 товаров картинок в кеше уже будет примерно 90 000. Режим mozjpeg (а особенно optipng) рекомендуется включать только при достаточном запасе мощности вашего сервера, например, если у вас VDS или не слишком дешевый тариф на общем хостинге. Это особенно важно если товаров много (> 5000). optipng включайте крайне осторожно если у вас много PNG. Он работает в десятки раз медленнее чем WEBP, а эффективность его невысокая по сравнению с WEBP. Поэтому если у вас очень много товаров с картинками в PNG, то лучше откажитесь от optipng, иначе это на время создания изображений приведет к ощутимым тормозам вашего сайта, хоть и временным. Разумнее будет использовать для PNG только режим создания WEBP. -
Какой выбрать режим (стратегию) для создания сжатых изображений? Если ничего не понимаете и не хотите вникать в тонкости процесса, то выбирайте только WEBP. Если хостинг слабоват, а товаров много (более 2000), то рекомендуется в качестве сжатого формата изображений использовать только WEBP, при этом не надо очищать уже существующий кеш изображений. Так вы не будете создавать лишней нагрузки на сервер. И создание WEBP произойдет практически без заметных на глаз тормозов страниц даже в режиме создания "на лету". Этот режим нормально работает даже в случае большого кол-ва товаров (> 10 000). Обычно для 10 000 товаров формируются не менее 30 000 картинок в кеше даже если у товара всего по одному изображению, т.к. формируются разные картинки по геометрическим размерам. Соответственно, если у товара в среднем 3 картинки, то для 10 000 товаров картинок в кеше уже будет примерно 90 000. Режим mozjpeg (а особенно optipng) рекомендуется включать только при достаточном запасе мощности вашего сервера, например, если у вас VDS или не слишком дешевый тариф на общем хостинге. Это особенно важно если товаров много (> 5000). optipng включайте крайне осторожно если у вас много PNG. Он работает в десятки раз медленнее чем WEBP, а эффективность его невысокая по сравнению с WEBP. Поэтому если у вас очень много товаров с картинками в PNG, то лучше откажитесь от optipng, иначе это на время создания изображений приведет к ощутимым тормозам вашего сайта, хоть и временным. Разумнее будет использовать для PNG только режим создания WEBP.
-
Если найду время, то поправлю. За год до этого то ли ни одной не было покупки, то ли была одна лишь покупка.... т.е. вроде как никому и не нужный функционал Что касается сжатых форматов (WEBP), то он нормально будет работать для картинок, вставленных в редакторе прямыми ссылками (на исходники). А если не использовать адаптивный ресайз от seo cms, то и для картинок в кеше все должно по идее работать в плане сжатого формата. в качестве сжатого рекомендую использовать WEBP везде, где это возможно.
-
Господа, на новой версии SEO CMS работоспособность не проверялась. Возможна несовместимость. Совместимость была обеспечена для более ранних версий SEO CMS. Модуль разрабатывался давно. В связке Компрессор 1.8.* + SEO CMS 39 проблем не было. Ввиду полного отсутствия спроса на данный модуль обновление произойдет пока неизвестно когда.
-
Исправил проблему в старых браузерах. Это касалось только webp + lazy load. Проверял на встроенном браузере смартфона выпуска лохматого 2013-го года. Также проверил в древнем Хроме 37-м (2013-го или2014-го). Все ОК. webp отображается. с lazy load проблем нет. Версию модуля Компрессор 1.12.2 сейчас подготовлю для скачивания покупателями.
-
@RaVIOLy , спасибо за детальный и тщательный анализ! По поводу древнего браузера мейзу ... Посмотрел на своем древнем планшете 2013-го, да есть проблема. Но тут проблема не с самим WEBP (с этим форматом проблемы нет), вопрос с lazy Load. Вопрос решу. Но у меня даже на более древних движках (Chrome 43, например, 4-х летней давности) проблем нет. Вот эта древность (4 года уже - срок?) работает с webp + lazy Load без проблем:
