sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
WEBP работает везде просто и надежно ! Никакой зависимости от хостера в плане создания и вывода WEBP! Работает WEBP везде без всяких условий! Не надо спрашивать будет ли работать на вашем хостинге WEBP. Ответ простой - у вас будет WEBP! В данном решении предусмотрено практически все, включая полную совместимость с ускорителями Jet Cache, Turbo. WEBP (сжатый формат графики) можно теперь получить практически у любого хостера. Не имеет значения есть ли поддержка WEBP у вашего хостера или нет. Такая поддержка WEBP встроена в модуль Компрессор и работает на любой Linux и Windows. Поддерживается любой современный браузер, способный отображать WEBP. Благодаря современному формату изображений WEBP удается снизить общий вес изображений в среднем в 2-3 раза на странице, и тем самым выполнить рекомендации Гугла. -
Новая версия модуля Компрессор 1.16.5 Столкнулся на днях с "чудесами" у одного из хостеров. В php заявлена поддержка WEBP, но сам php не в состоянии записывать формат webp. Причем, что самое неприятное - это то, что php не выводит ошибку, но зато вылетает 502-я, т.е. средствами php невозможно отследить и не допустить ошибку, разумеется, что никакие try-catch не работают. Похоже, что у хостера просто криво собранный PHP в плане поддержки WEBP. И только определенная версия так криво работает, на других проблем нет. Поэтому пришлось подумать как учитывать такие редкие случаи, связанные с проблемой на стороне хостера. Модуль Компрессор теперь способен тестировать такие случаи тоже и не допускать вываливания 502-й. В общем, нельзя верить всему, что написано. Пойдет в копилку разных багов и глюков хостера. Наряду с картинками-невидимками WEBP, которые любит создавать GD. В новой версии присутствует защита от такого "обмана" со стороны imagick. В дополнение к другим защитам от некорректного софта. Рекомендуется всегда использовать софт для создания WEBP, идущий вместе с модулем, т.е. CWEBP (скомпилирован из исходников от Гугла для любой Linux и Windows), который устанавливается одной кнопкой и работает у любого хостера, никакие ограничения не действуют, достаточно наличия хотя бы CRON у хостера, а в 95% вы всегда можете использовать режим "создание на лету webp".
-
@dexion , с вашей подачи, думаю, что это (lazy load для всех форматов и всех браузеров) появится теперь быстрее чем я планировал ранее.
-
Для тех, кто заблудился в темах есть как раз раздел:
-
Так никто и не спорит с этим. Безусловно. Но думаете большинству это интересно? Они не читают рекомендации. Большинству интересны лишь баллы гугла. Тупо баллы, общие баллы. И такие заказчики будут недовольны даже в случае ускорения, которое видно на глаз, но которое "гугл не оценил". К примеру, на странице вес снижается с 8 М до 1М (довольно часто бывает если много баннеров PNG), но заказчик остается все равно в претензии, что "он ожидал большего", его абсолютно не интересует, что гугл не сильно поднял баллы, например, из-за тормозного JS. Все не так однозначно. Есть заказчики, которые до покупки будут мучиться вопросом "а будет ли работать webp или не будет на моем хостинге?". Это при том, что у 95%-98% заказчиков с этим никаких потенциальных проблем нет. Но из-за этих сомнений будут опасаться покупать даже те, у кого с хостингом в плане webp нет сложностей совсем. Поэтому я просто сделал чтобы понимали все, что у них будет работать webp обязательно независимо от хостинга. Это мы с вами понимаем, что lazy load будет полезен в любом случае (и для тех самых 20% пользователей сафари). Но понимающих это заказчиков вряд ли наберется 20%. Скорее всего, понимающих важность этого момента будет тоже примерно 2%-5%. К сожалению, многих сам факт реального ускорения и снижения пустого мобильного трафика мало интересует. Порой складывается впечатление, что сайт уже не для людей должен работать, а лишь для оценки гугла в баллах. Поэтому данная задача в планах есть, но пока не в близких планах.
-
пока не делал, т.к. особого смысла в этом не видел. 1) гугл этого не оценит 2) раз не оценит гугл, то подавляющее большинство пользователей тоже не оценят 3) по статистике 80% трафика будет приходиться на webp. Возможно, что позже добавлю. Но это будет для меня разработка, которая не окупится. Точно также как не окупится разработка (которая сделана уже и внедрена) для поддержки тех 2% пользователей, у которых хостер заблокировал любую возможность создания WEBP. Т.е. чисто технически проблем нет, но пока непонятно зачем тратить на это время.
-
Эмуляторы браузеров на мобильных устройствах.
sitecreator replied to Pirks's topic in Допомога програмістам та розробникам
Вы сможете выбрать нужное устройство и нужную версию iOS. Apple довольно хорошо заботится о разработчиках и предоставляет много возможностей, но только на компьютерах под своей OS. Поэтому если у вас другая платформа, то VMware решит вопрос. Когда я искал решение, то на VirtualBox завести OS от Apple не было возможности, поэтому и предлагаю смотреть в сторону VMware. Мне удавалось хорошо отрабатывать всякие нюансы вплоть до переворачивания экрана, соответственно можно обнаружить проблемы рендеринга, JS (и т.п.) в этом случае тоже. -
Эмуляторы браузеров на мобильных устройствах.
sitecreator replied to Pirks's topic in Допомога програмістам та розробникам
-
Эмуляторы браузеров на мобильных устройствах.
sitecreator replied to Pirks's topic in Допомога програмістам та розробникам
Пользуйтесь инструментами от apple для отладки на macOS, iOS. Например, устанавливаете на виртуальную машину OS от apple и работаете в Сафари. Если установите еще инструменты разработчика дополнительно, то сможете запускать также сафари на iOS различных версий. Дебаггер и пр. доступны. VMware это позволяет. Смотрите в эту сторону. Я не теоретизирую, а именно так и работаю. -
Полный контроль над полями, обрезкой и пр. и пр., что только можно и нужно делать с изображениями. https://opencartforum.com/files/file/4572-image-compressor-watermark-webp-lazy-load-etc-by-sitecreator/ Для опенкарт 3.0 здесь: https://opencartforum.com/files/file/6148-image-compressor-watermark-for-opencart-3/
-
забавно, что автор того модуля пишет: Ошибочное утверждение. Если раза в 2-3 снижается вес изображений (а по статистике именно так после перехода на WEBP), то это никак не влияет на скорость? гугл считает иначе. И своими баллами также это подтверждает. Просто нужно не забывать, что просто создать webp будет недостаточно, за это вам, действительно, никто баллов не накинет. WEBP еще нужно правильно вывести в браузер, а старым браузерам отдать jpeg/png. Вот это все умеет модуль Компрессор на любом хостинге. И вам нет особой нужды думать о том поддерживает ли ваш сервер WEBP. Модуль Компрессор максимально автоматизировал и упростил для вас этот процесс, включая возможность использования WEBP Lazy Load.
-
что за сжатие кода и зачем оно? HTML сжимать? Так это бессмысленное дело. Он и так сжимается сервером. А всякие минификации по удалению пробелов и тп. только отжирают ресурсы и тратят напрасно время, т.к. выигрыш в итоге будет нулевой если сравнивать итог после сжатия gzip файла.
-
какие расширения поставить для ускорения сайта 2.3?
sitecreator replied to hitball's topic in Загальні питання
Что такое "Стандартное сжатие"? И где оно есть? Сжатый формат WEBP позволяет по статистике сократить трафик (изображения) раза в 2-3. Т.е. уменьшить суммарный вес изображений. Это если сравнивать со стандартной работой графики GD в Опенкарт (а ничего другого стандартного в Опенкарт и нету). Стандартно GD работает с качеством 90 для JPEG. Оптимальным для WEBP является качество 83-87. Также учитывайте, что баннеры, всякие заливки часто через кеш опенкарт вообще не проходят. Они нередко из фотошопа уже идут с избыточным весом. Для PNG выигрыш получается очень значительный, там и в 5-7 раз можно вес снизить за счет WEBP. А вы точно уверены в том, что знаете как и где работает WEBP? Во-первых, FireFox уже с конца прошлого года (версия 65+) понимает формат WEBP без всяких проблем и танцев. Опера так вообще долгие годы его понимает наравне с Хромом. А если говорить про старые браузеры, то им webp не отдается, им отдается JPEG/PNG, т.е. то, что они понимают. Тому же IE отдается JPEG/PNG. Новый IE понимает WEBP тоже, но смысл про него (IE) говорить если им практически никто не пользуется? Т.е. каждый браузер получает то, на что он способен. "JS конвертер" в здравом уме на смартфонах никто не использует. Эту технологию можно рассматривать лишь чисто как эксперимент, но не более. @hitball , оптимизация изображений - это лишь часть необходимой работы по оптимизации (ускорению) работы сайта. Необходимая часть, но недостаточная. Если плохой отклик (время генерации страницы), то можно поставить кешер Jet Cache. Но кешер поможет только улучшить отклик. Если же есть проблемы с JS (долго работает), то тут нужна ручная работа в любом случае. не удивительно если нужно ждать 45 сек прежде чем что-то можно нажать на вашем сайте. Работа нужна в комплексе! По отдельности ни одно решение вам не поможет. Каждое решение поможет подтянуть свою проблемную часть. Но если у вас JS работает 15 секунд, то на это нужно обратить внимание обязательно. даже молниеносная отдача страницы сервером не избавит вас от проблем тормозного JS. Простых и магических решений в таком случае не бывает. без специалиста вы вряд ли обойдетесь. Вы можете прекрасно все ускорить на сервере, включая изображения. Но у вас останется клиентский JS. -
Уже думал об этом тоже. У меня по поводу GD многократные красные предупреждения стоят. Видимо, придется отключить совсем, т.к. у очень многих хостеров стоит нежизнеспособный GD в плане генерации WEBP. Из кеша WEBP-невидимки можно удалить через сам модуль Компрессор. Там кнопочка есть. А вот в других папках (не кеш) уже надо руками удалять. Т.е. формально в GD может быть поддержка WEBP, но на деле получается на выходе либо черный фон (после прозрачных PNG), либо (что вообще никак не лечится) часть картинок в "невидимом" формате WEBP, т.е. для Хрома часть таких картинок будет словно пустое прозрачное место, хоть они прекрасно видны в том же новом FireFox (65+ версия). В общем, только в новых сборках GD есть исправление всех этих недугов. Но кто-то из хостеров следит за этими моментами? Практически никто не следит, а многие просто от греха подальше даже не включают для GD поддержку WEBP, и это даже лучше чем поддержка WEBP с багами. стоит отключить автоматический обход страниц с целью создания кеша изображений, иначе в случае mozjpeg это создаст большую нагрузку. И оптимизацию изображений средствами того модуля также стоит отключить. Что и как там оптимизируется не знаю, софт для сжатия изображений там не используется на вашем сервере. Если только там гоняются изображения туда-сюда.... Но я бы такой способ положил бы на лопатки лишь одним своим заказчиком, т.к. у него сервер (не VDS!) 8 ядер 32 Гиг памяти, и 150 Гиг (!!!!) кеша изображений. Ставится везде одинаково. Просто обычно на общем хостинге сам хостер следит за верными настройками сервера, а на VDS каждый настраивает "как умеет".
-
Добрый день. 95%-98% хостеров и хост-площадок не видят в этой функции никаких проблем. Переходите на свой VDS если для вас это важно и управляйте любыми ограничениями самостоятельно. Или используйте WEBP как отличную альтернативу. Модуль Компрессор - это единственное решение, которое позволяет как создавать WEBP у любого хостера, так и выводить WEBP в браузер также у любого хостера. Альтернатив модулю в плане WEBP (особенно это касается вывода) не существует. Вообще, только создание WEBP без возможности вывода не имеет никакого смысла. а вывод - не менее сложная задача, особенно на общем хостинге. Модуль Компрессор выполянет обе этих задачи. Модуль предлагает сразу несколько альтернативных технологий сжатых форматов. У большинства (95% как минимум) они будут доступны все сразу. Оставшиеся могут использовать WEBP практически в любом случае, но для них не будет доступен mozjoeg. И почти всех в основном интересует отношение гугла к сайту, т.е. баллы, а они как раз достигаются за счет WEBP. И большинство таких пользователей (как и сам Гугл) мало волнуют проблемы айфонов. И это указано в описании к модулю. Что требуется proc_open. Требования же не просто так написаны, не так ли? Возможно, что позже сделаю вариант создания mozjpeg, optipng по расписанию, т.е. proc_open не будет обязательной, но для создания "на лету" эта функция нужна. Но, опять же, это практически никому не нужно, а тем 2%, кому это нужно на словах, на деле тоже не нужно, т.к. никто не готов заплатить за такой функционал.
-
Версия модуля Компрессор 1.16.4 Добавил статистику для режима создания WEBP по расписанию (CRON). Чтобы не возникало вопросов "работает или не работает" предлагаю смотреть статистику. Вы сразу увидите сколько обработано за все время входных файлов, суммарный вес входных файлов и выходных. А также их соотношение. Графически показано насколько уменьшился суммарный вес обработанных файлов.
-
Новая версия модуля Компрессор 1.16.3. Полноценный режим работы по расписанию для создания WEBP в фоновом режиме. Создание WEBP работает даже на хостинге, где нет возможности создавать на лету WEBP из-за того, что у хостера нет никакого софта для создания WEBP кроме глючного GD, который создает массу картинок-невидимок WEBP. А также у хостера отключен exec, open_proc, да и запуск cgi-bin скриптов тоже запрещен. Но даже на таком ущербном с ограничениями хостинге вы получаете работающий WEBP. Пример такого хостинга: hoster.ru. Сплошные ограничения у этого хостера. Но теперь модуль Компрессор работает даже там, т.е. практически везде WEBP можно создать и вывести в браузер. Был бы только доступен CRON (Планировщик) у хостера. Но без планировщика не бывает хостинга, правда, если не брать во внимание бесплатные и прочий треш, непригодный для опенкарт в принципе.
-
а это уже ваш баг. вашего сервера. И проявляется он независимо от модуля Компрессор. Проявляется ВАШ баг с полностью отключенным модулем Компрессор. Кроме того эта 503-я ошибка тормозит ваш сайт из-за множественных таких обращений. Именно сервер отдает такой неверный тип в заголовке ответа. Сервер NGINX. Это уже проблема настройки конкретного сервера. думаю, что в данной теме малоинтересно кому-то читать о совершенно частных проблемах, да еще никак не связанных с модулем. возможно, что у вас на диске свободное пространство закончилось. такое запросто бывает. И у вас очень на это похоже. Поэтому чтобы не гадать нужно обращаться в личку со всеми доступа. В том числе к панели управления хостера (к VDS тоже если есть) В модуле есть отладчик. Пользуйтесь им в первую очередь для вывода информации. Только кешер отключайте на время отладки! Иначе непонятно что будет кешироваться, а потом отдаваться.
-
Еще немного пояснения по составлению команды для cron. Можете протестировать работу создания webp (команда для cron) прямо на вкладке "Настройки и тестирование CRON" модуля Компрессор. Это возможно если proc_open не заблокирована (доступно обычно в 95%-98% случаев). Если же эта функция заблокирована (ситуация возможна в 2%-5% случаев), то проверить тоже сможете, но для этого вам нужно будет специально зайти в SSH. Напоминаю, что обычно (часто) для Centos 7 (при установленном php 7.1) путь к php (cli) 7.1: /opt/php71/bin/php Вы можете попробовать разные команды. Все это нужно лишь для того чтобы вы могли правильно указать путь к интерпретатору php (cli) любой версии от 5.6 до 7.3 включительно с ioncube loader 10+. Вы\также можете узнать этот путь просто задав вопрос вашему хостеру.
-
Здравствуйте. Прошу с доступами в личку.
-
Новая версия модуля Компрессор 1.16.2 Для настройки режима работы по расписанию (cron, планировщик) сделал возможность теста командной строки прямо в модуле. Сразу скажу, что нужно обладать хотя бы начальными знаниями Linux. Если не понимаете, что такое cron, то закажите услугу настройки модуля в этом режиме. Описание для cron приведено в самом модуле максимально информативно. Информации более чем достаточно чтобы понять как настроить и сделать тест. Командная строка для cron формируется почти полностью автоматически, за исключением пути к интерпретатору php. Но для его правильного нахождения также имеются инструменты. Тест PHP CLI был специально мною сделан, т.к. часто пользователи не понимают, что это такое PHP CLI . Тест сделан чтобы была возможность написать правильную команду для cron и протестировать ее. По поводу безопасности. Она на высоком уровне, у пользователя нет возможности набирать произвольные команды, при желании он сможет их выполнить только через SSH. Более полно смотрите демо-версию: Демо 2 (админка): http://watermark.sitecreator.pro/admin/index.php?route=extension/module/watermark_by_sitecreator пользователь: DEMO пароль: DEMO
-
Для работы WEBP в новых версия модуля Компрессор не нужен никакой софт для WEBP у вашего хостера. При полном отсутствии такого (WEBP ) софта у вашего хостера, а также в случае запрета exec (proc_open) модуль Компрессор все равно без проблем создаст для вашего сайта изображения WEBP и выведет их в браузер. Вам не нужно волноваться будет ли работать на вашем хостинге сжатый формат изображений WEBP. Практически в 100% случаев он будет работать. В предыдущих версиях модуля Компрессор охват хост-площадок составлял примерно 98% в плане работоспособности WEBP. Также режим работы по расписанию (cron) надежно гарантирует отсутствие превышения необходимой нагрузки и тормозов страниц. Справедливости ради нужно сказать, что и предыдущие версии не вызывают никаких тормозов в случае работы с WEBP. Даже в случае создания WEBP "на лету" в форсированном режиме с самым глубоким уровнем оптимизации. Благодаря тому, что существует контроль нагрузки. И благодаря тому, что модуль Компрессор серьезно оптимизирован в плане скорости генерации изображений WEBP.
-
??? а в чем стандартность то? Интернет-эквайринг зависит от банка, с которым вы работаете. И ничего стандартного тут нет. Бывает, что для конкретного банка и программного обеспечения такого нет. А для вас это как само-собой разумеющееся? Можно, конечно, подключить какой-нибудь агрегатор платежей. Это будет "стандартно", но вы за такой стандарт будете отдавать комиссию 8%-12% вместо, например, 2-3% в случае прямого договора с банком. да и это все индивидуальный набор способов и методов, но никак НЕ стандартный. тоже самое касается и вот этого:
-
В версии 1.16.0 cron для webp пока работает в режиме теста. Т.е. важно в принципе понять насколько заказчику будет понятно как настроить данный режим. И не менее важно увидеть успешность теста на хост-площадках, на которых заказчиков обделили возможностями по работе с WEBP и не только, там и mozjpeg не работает.
-
Версия 1.16.0 доступна для скачивания. С поддержкой CRON для WEBP. Работать должно у любого хостера. Если кому-то нужна работа по расписанию (создание WEBP), то вы можете протестировать такую возможность. Это открывает возможности работы WEBP у хостеров, которые запрещают exec php и при этом нет возможности создавать WEBP за счет imagick, GD. GD можно вообще не рассматривать как вариант для WEBP. У многих хостеров стоит крайне глючный вариант GD с поддержкой WEBP . Теперь WEBP можно будет получить, например, у хостера hoster.ru (у него exec под запретом). Прежде чем настраивать CRON нужно обязательно установить CWEBP. Если вы этого не сделали. Все это делается через модуль Компрессор. Выбирайте версию для Linux 2.6 если не знаете какую установить надо. Особенно если у вас вот такой запрет:
