Если я все верно понял, вы хотите улучшить скорость загрузки сайта, преобразовав картинки в WebP?
Использовать подобные модули для Magento не оптимальный подход, а пре-процессить все картинки в скинах - совсем плохая.
Намного профитнее такой подход: настроить на хостинге mod_pagespeed (есть как для Apache, так и для nginx). Он эффективно справится и с этой задачей, и с многими другими нужными оптимизациями прозрачно для Web-разработчика. А еще он сам определит, поддерживает ли конечный клиент WebP, или надо отправлять ему старые форматы.
Оптимальным с точки зрения производительности, как раз является препроцессинг всех файлов, если вы будете каждый раз жать в онлайне, у вас увеличивается TTFB к каждому файлу и вы перегружаете процессор, память своего сервера при КАЖДОМ обращении, статическое же сжатие проходит делается гораздо реже, при инициализации или замене файлов. Хотя, если после онлайн дожималки вы поставите varnish сервер или правильно настроите обратный кеширующий прокси, тогда ок, но это опять же дополнительное процессорное время и память, в которой хранится кешированные изображения кеширующим сервером.
Место занимаемое статически скомпрессированными файлами занимает на средних проектах - не так много места, по сравнению с нагрузкой и дополнительным временем ожидания, которые создаются любыми он-лайн компрессорами. Но если у вас миллион картинок, тогда да, компрессия может быть проблемой, особенно после обновления кеша, но в таком проекте медиа должна храниться на сетевом диски, за компрессию должны отвечать отдельные виртуальные машины или даже по запросу надо поднимать таких несколько и распределять нагрузку через rabbitmq.
Определяет - поддерживает ли браузер посетителя WebP, Gzip, Brotli и другие капабилити плюшки - не модуль PageSpeed, а строчка в настройках apache | nginx
То же самое касается дожимания скриптов и стилей, которые можно статически скомпрессировать в gzip или даже лучше в brotli, который экономит еще 10-15% места. Причем, статические файлы вы можете компрессировать с более высоким коэффициентом, чем онлайн, а это минус 3-7% к размеру файлов.
Задача оптимизатора - заставить клиентский браузер хранить как можно дольше кеш, минимизировать процессорное время, занимаемую системой память, размер файлов на отправку в браузер посетителя и отправлять их как можно быстрее по запросу, желательно уметь переопределять приоритет, отправляемых файлов ( http/2 push). Ну и по большому счету надо, что бы доставленные браузеру файлы занимали как можно меньше памяти и процессора на стороне клиенсткого браузера, с учетом мощности клиентской железки, при предоставлении для него оптимального функционала, но это уже высший пилотаж.
p.s. тоже самое можно сделать за денежку, ежемесячно, за вас дожимают медиа файлы, хранят кеш, делают вам HTTP/3 и другие плюшки такие решения как cloudinary...