sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Смотрите в личке, там ваш ключ, пожалуйста. Просьба не писать в теме поддержки совершенно неинформативные и никому не интересные кроме вас сообщения, для этого и придумана личка. К тому же я в отпуске, о чем указано в моем статусе, а потому отвечать могу с некоторой задержкой. -
Здравствуйте. Не мог сразу понять кто такой Gron. cron? непонятно про какую картинку идет речь и где, а также неясно удаляли вы ее? Но, по идее после успешного создания тестовой webp-картинки вас она уже не должна интересовать, т.к. после перехода в рабочий режим тестовое создание webp уже не будет происходить, ибо нет смысла. Здравствуйте. Это есть в модуле hi-optimizer. Там есть отложенная загрузка видео-вставок, карт гугла и яндекса и разных прочих виджетов. вот вам пример такой загрузки: https://hi-optimizer.sitecreator.pro/ вот вам пример этой же страницы без оптимизации: https://hi-optimizer.sitecreator.pro/home00.html Соответственно оценка гугла будет разной для этих одинаковых страниц. Адаптивность для ютюб решается соответствующим html + CSS в коде ютюб-вставки.
-
Здравствуйте. Это к изображениям не имеет отношения. В модуле есть возможность включить нативный lazy для изображений. Можете переключиться в этот режим если хотите и если он у вас сейчас не включен. Но судя по всему он у вас уже включен и работает.
-
не надо включать. В новых версиях модуля админ-бар не поддерживается ввиду невостребованности данной функции. Эта кнопка оставлена для отключения админ-бара. потому, что у вас возникает ошибка JS. Не включайте в модуле "совместимость с кеширующим ускорителем" если у вас не Лайтинг. И не включайте без надобности " Если в ускорителе включена оптимизация JS ". Если у вас в ускорителе Лайтинг накручен режим агрессивной оптимизации JS, то он будет ломать работу вывода webp. Если включили оптимизацию JS, то оставляйте умеренный вариант или не используйте ее. К сожалению, автор Лайтинга не оказал помощи в вопросе достижения полной совместимости модулей, поэтому для Лайтинга есть компромисное решение, которое исправно работает при соблюдении определенной осторожности в настройках. Такие вопросы лучше задавать в личку с предоставлением доступов и указанием подробностей. Сейчас я во многом гадаю, т.к. не знаю установлен ли у вас кеширующий ускоритель, и какой... и т.д. и т.п. Я не вижу ваших настроек и т.д. и т.п.
-
Здравствуйте. В этом: включите у хостера эти функции. Если это невозможно, то используйте возможности создания webp, которые есть в графической библиотеке GD или imagick (включите ее на хостинге). Или, еще один вариант, устанавливайте cwebp и используйте режим создания webp по расписанию (cron), этот вариант годится для случая когда у хостера нет других возможностей, но cron есть у любого хостера. В самом модуле есть все необходимые тесты различных движков webp, в инструкции все есть.
-
в вашем случае document.write - необходимость. в нем кеширование только для клиентской части, серверные скрипты не кешируются и в принципе не обрабатываются. Клиентская часть - это программы, которые работают на стороне клиента, т..е. в браузере смартфона, ПК и т.п. Серверная часть отвечает только за скорость отдачи страницы, далее все происходит на клиентской стороне, и оценка гугла, как минимум, на 90% строится именно на скорости работы клиентской части сайта при условии, что страница отдается сервером не более чем за 1 сек. Если страница отдается сервером за 0.5 сек или быстрее, то оценка гугла уже будет на 99% строиться на основе скорости работы клиентской части. Мои модули дружат между собой. С Лайтингом тоже дружат, но при правильной настройке. В случае неправильной могут быть конфликты.
-
во-первых, это никакая ошибка. Это лишь рекомендация, которую также уместно выполнять не во всех случаях, впрочем, как и др. рекомендации гугла. во-вторых, без необходимости не нужно включать опцию Включить СОВМЕСТИМОСТЬ с любым кеширующим страницы (HTML) УСКОРИТЕЛЕМ! Ее нужно включать только в случае крайней необходимости. Кеширующие ускорители вроде jetcache (любая версия), turbo, nitropack (версии 2.5) не требуют включения данной опции. В случае Лайтинга включить необходимо, но это вынужденная мера. Только с включением указанной опции используется document.write, т.к. без него невозможно обойтись в данном конкретном случае, и он выполняется максимально быстро если говорить про данный конкретный случай. К сожалению, многие заказчики включают без разбора нужные и ненужные опции. В модуле есть очень много разных опций для того чтобы модуль мог работать практически в любом программном окружении и на любом сервере, но это не означает, что все они могут быть включены на конкретном сервере для определенного сайта. Опция "Включить СОВМЕСТИМОСТЬ с любым кеширующим страницы (HTML) УСКОРИТЕЛЕМ!" вообще не нужна если нет кеширующего ускорителя, не нужна она в случае приведенных выше ускорителей. Ее включение несколько снижает потенциал модуля Компрессор, и если без нее можно обойтись, то включать ее не нужно.
-
здравствуйте. Вы можете добавить в список разрешенных этот тип файла. Этот список локальный для модуля, а не для всего сайта в целом. 'uploadAllow' => array('image/jpeg', 'image/png', 'image/gif', 'image/svg+xml', // "особые" типы древних IE добавил на всякий случай sitecreator 'image/pjpeg', 'image/x-png'), 'uploadDeny' => array('all'), Можете вставить непосредственно перед 'image/jpeg'. 'application/pdf' у вас должна верхняя строка после этого выглядеть так: 'uploadAllow' => array('application/pdf', 'image/jpeg', 'image/png', 'image/gif', 'image/svg+xml', правки нужно делать в файле system/library/sitecreator/trueFileManager/ControllerCommonTrueFileManager.php Отсчет файла идет от корневой папки сайта
-
Изображения в формате webp
sitecreator replied to cyberkekc's topic in Opencart 2.x: Setting and optimization
Черный фон вместо прозрачного не лечится никакими костылями кроме смены версии самого GD. Вы привели кусок кода от другой болезни, коих в GD предостаточно, особенно в старых версиях под php 5.6. Но и этот код в целом неверный, т.к. нельзя к любым файлам добавлять в конец нулевой байт, иначе будут возникать другие проблемы. . -
которая меньше чем комиссия яндекс-кассы для предпринимателей раза в 2.5 как минимум. И бесплатный расчетный счет предлагает сбербанк. Что еще нужно для спокойного интернет-эквайринга? Другое дело, что еще и налоги нужно будет не забыть заплатить вместе со страховыми выплатами. В случае р/с тут довольно все прозрачно в отличие от кошелька физического лица. Не вижу вообще никаких проблем. Пару лет работаю с интернет-эквайрингом, плачу налоги и т.п.
-
По поводу нативного lazy load и якобы, что оно "не работает". Если вы этого не видите, то это не означает, что "не работает". Интеллектуальные алгоритмы современных браузеров стараются делать загрузку страницы максимально плавной и сами решают когда и в какой порции загружать картинки. В FireFox отлично видно как это работает. Под спойлером или по ссылке мультфильм, показывающий работу нативного lazy load в FireFox . В Хроме это также работает, но Хром сам определяет (в зависимости от скорости соединения) когда и в каком объеме подгружать изображения в случае установок lazy load. Если скорость соединения высокая, то Хром может загрузить большинство картинок не дожидаясь когда они попадут в область просмотра - таков интеллектуальный алгоритм Хрома. FireFox явно указывает инициатора загрузки: lazy-img. Хром в таком случае указывает: Other. Все это видно если открыты инструменты разработчика. В обоих браузерах можно увидеть визуально как меняется счетчик запросов по мере работы azy load https://i.imgur.com/4xvdHX2.mp4
-
Здравствуйте. Становится размытым, судя по вашему скриншоту, вы это имеете ввиду. Модуль Компрессор позволяет вам полностью контролировать качество. Лучшего контроля вы не найдете, да и для web его уже выше и не может быть. Наилучшего качества позволяет добиться применение графической библиотеки imagick, плюс сжатый формат webp с верно подобранными параметрами. Вы верно поступили, что для четкого текста выбрали формат png. Хоть и jpeg позволяет часто получить качество не хуже. Могу сказать, что ко мне специально обращались не раз владельцы сайтов, которые сами делают фотосессии для своих товаров и очень дорожат качеством изображения. И для сжатого формата webp находили оптимальные параметры чтобы и качество не страдало, и вес не был бы излишним.
-
именно так. на основной домен ключ был выдан. Дистрибутив модуля для скачивания доступен покупателю на этом форуме, как и все последующие обновления. именно так. во первых: Человек просил выдать лицензию сразу на два равноценных домена. во-вторых там же на странице описания модуля указано: вот сама ссылка на этом форуме на правила лицензирования: https://opencartforum.com/files/tutorials/64-{%3F}/ Самым подробнейшим образом расписано что и как. включая это: и это: Лицензия для тестового домена - это вообще не обязанность разработчика, это его добрая воля. а была хотя бы одна причина? Лицензия (вечная и безвозвратная ) вместе с файлами дистрибутива заказчиком получены. с моей стороны все обязательства выполнены.
-
[Поддержка] CKEditor for Opencart by sitecreator, полная версия
sitecreator replied to sitecreator's topic in Редакторы
редактор делает в точности то, для чего был задуман и как это задумано разработчиками редактора. описание возможностей здесь: https://ckeditor.com/ckeditor-4/ Вы можете там поинтересоваться. Вставить без проблем можете inline-style, т.е. стиль в самом теге. Почему сделано так или иначе - это лучше спрашивать у разработчиков редактора, я лишь подготовил адаптацию по опенкарт. -
и снова неверная информация. либо вы забыли, либо не знаете, либо делаете вид, что не знаете. Я же вам в личке все сразу показал. И сделал акцент на одинаковом ID. Вы отлично видели эти скриншоты. ВЫ эту информацию приняли, но сейчас пытаетесь все представить в ином свете? это вы так думали. А на само деле было иначе: Вы же сами подтверждали, что видели два счетчика после того как я вам на на них указал. А я вам указал на счетчики с одинаковым ID. И вы этого не отрицали на тот момент. А сейчас забыли просто? Доступа уже не было 15 числа сразу после того как ваш хостер "пошаманил" на сервере. Не знаю повлияло ли здесь шаманство, но доступов у меня уже не было. Я также просил у вас доступ 14-го поскольку было сомнение насчет верной работы вашего сервера. Вы пообещали, и ничего не дали: Итого, у меня не было возможности проверить определенные моменты, которые касались долгого отклика сервера в 2-7 секунд. А это очень важный фактор. Вы просто местами забываете некоторые факты, с метрикой - явный пример. Или просто думаете, что что-то сделали, на само деле - не сделали. 15-го у меня не было ни доступов, и никакого контроля над ситуацией с вашим сайтом.
-
Только вы сильно лукавите, специально не рассказывая вашу историю про ваши эксперименты с несколькими метриками одновременно. Почему бы вам не составить график и не указать в каком промежутку у вас работало 3 метрики, 2 метрики и 1 метрика? Кроме того вы сами крутили разные настройки на сайте после установки оптимизатора, но при этом отключили мне доступ. Я лишь видел внешние проявления ваших экспериментов, но не имел возможности посмотреть и подсказать вам, что произошло неправильного. У вас одновременно было несколько различных факторов. Вы умалчиваете о собственных ваших действиях. Вы в это же время вели еще работы на сервере. Вы же сами писали, что в это время ваш хостер шаманил с сервером. Это же ваши слова? И что показывают ваши графики? Отклонения в пределах статистической нормы. Вы порой что-то делаете и сами не понимаете что. Вроде бы сделали, а вроде бы и нет. Мистика, говорите? Несколько счетчиков разных (с разными ID!!!) могут быть. Но ваша проблема была в том, что у вас было несколько счетчиков с одинаковыми ID. Забавно, что вы пытаетесь как-бы не замечать проблем, которые сами создали. И пытаетесь делать вид, что ваши собственные действия вообще не имеют значения. Мы когда с вами разбирались в ваших тормозах сервера, то неожиданно всплывали неизвестные факторы, которые могли влиять серьезно на скорость. Это еще раз к тому, что вы не отдаете себе отчет в том что вы делаете полезного, а что - вредного. Обнулять каждый раз (каждый день!) кеш изображений с вашим огромным кол-вом товаров - это зло и провоцирование всплеска нагрузки на сервер. Сколько еще странных и неизвестных действий вы производите? И по вашему все они, конечно же, не имеют никакого значения? Чистое лукавство. Вы (или вам) сейчас просто поставили задачу подтасовать нужные факты под определенную теорию. На самом деле, когда заказчику важен результат, то он общается с разработчиком, а не делает что-то втихаря и блокирует доступы. Любые возникающие проблемы должны анализироваться чтобы понять их корень. Я на вашем сайте был лишь пару часов. Я вам сразу написал: У вас были проблемы на сервере. Мы договорились, что вы дадите возможность посмотреть поскольку было одно вполне обоснованное подозрение по поводу сервера. Но далее вы доступы блокируете, прежние договоренности уже не выполняете. И что-то "шаманите", выражаясь вашими словами, на сервере вместе с хостером, самостоятельно и т.д. Т.е. с этого момента у меня не было никакого контроля над сайтом и я не имел возможности что-то скорректировать или хотя бы подсказать вам какие режимы не будут совместимы с вашими изменениями. Результат (не в лучшую сторону) вашего шаманства был виден в замерах по вашему сайту, я вам говорил об этом. Но публике вы не рассказываете вообще об иных действиях и факторах в это время, словно бы они и не существовали. Вам не кажется это странным?
-
Пример всего навсего одной полезной возможности автоматической оптимизации. Удаление множественных дублей всевозможных каруселей, лайтбоксов и тп. Многие шаблоны и модули грешат тем, что при появлении на странице очередного блока карусели и т.п. происходит очередная загрузка соответствующей библиотеки и заново инициализация всех уже существующих каруселей. Даже странно что приходится пояснять вполне очевидные вещи, которые просто и так понятны из названия пунктов оптимизации . Это к вопросу о практической пользе. И это отлично работает. Было: Стало:
-
Версия 2.1.22 улучшена совместность с опенкарт версии 2.0.0 и с Турбой для 2.3, улучшен lazy load, добавлено асинхронное декодирование изображений.
-
Вот эти данные показывают, что на сайте (без оптимизации) в случае даже мощного компьютера 4 Х 4 ГГц (не смартфона!!!) загрузка аналитики от гугла происходит через 2.5 сек, загрузка метрики от яндекса происходит через 4.5 сек. На смартфоне эти параметры соответственно будут хуже (время больше) в разы. Так вот даже на десктопе счетчики начинают работать с большим опозданием. И разница между замерами гугла и яндекса составляют 2 секунды (!!!) даже на десктопе, на смартфоне разница уже будет от 5 секунд и выше между двумя счетчиками. Т.е. изначально счетчики просто неспособны фиксировать те же отказы если они происходят в течение первых секунд. Счетчик гугла немного в лучшей ситуации, счетчик яндекса - в плохой изначально. Что счетчик Яндекса может зафиксировать ранее 4.5 сек на сайте? Ничего, он еще не начал работать. На данном конкретном сайте это именно так? Не пора ли Яндексу пессимизировать сайт за это? В результате оптимизации счетчик Яндекса имеет возможность просто загружаться раньше и отлавливать больше событий, включая отказы по сравнению с тем, что было до оптимизации. Это особенность отложенного асинхронного скрипта. Если не понимаете, то, добро пожаловать, в изучение JS. В вашем распоряжении инструменты браузера, профайлер и т.п. Смотрите и измеряйте реальные параметры.
- 142 replies
-
- 1
-
-
- ускорение
- оптимизация
- (and 6 more)
-
@pmshirshov , вопреки рекомендациям Яндекса вы разместили код счетчиков не в начале страницы (в <head>), а в самом конце. Про дублирование счетчика я уже писал. Так вот ваш код Метрики сработает только после загрузки страницы и загрузки всех CSS, JS на ее странице, т.к. они практически все работают в синхронной загрузке. Ваш счетчик сработает в таком случае на несколько секунд позже (на 20 сек запросто). Лишь малая часть информации ниже. У вас даже первая отрисовка блокируется на 2 с лишним секунды различными скриптами. До запуска Метрики еще очень и очень далеко. У вас уже изначально заложен неверный сбор информации. У вас страница грузится с сервера 3 сек, далее 2 сек идет только первая отрисовка. Итого только на этом этапе пользователь ждет 5 сек. за эти 5 сек. нецелевой пользователь мог закрыть страницу, а вы этого не увидите потому, что Метрика даже не начала работать. Это без всякой оптимизации. Это ваша Метрика. У вас изначально Метрика считает неверно, вы ее сами так сделали, что она не может увидеть многие отказы. Про дублирование счетчика (грубая ошибка) я уже писал выше. Если строить дальше график срабатывания скриптов на вашем сайте, то вы увидите, что ваша метрика сработает через несколько секунд. Фактически вы Метрику поставили в условия синхронного выполнения. Оптимизированная Метрика может на вашем сайте даже точнее работать, т.к. она может загружаться быстрее ввиду асинхронного выполнения отложенного скрипта. Отложенный скрипт - это вовсе не означает, что он будет выполняться намного позже чем изначально заложено. Для асинхронных скриптов это так не работает. Но чтобы это понять нужно разбираться в JS, но среди критиков тут таких просто нет. Я попробовал насколько возможно простым языком донести то, что у вас сбор данных с самого начала идет неверный.
-
вы уже в этом противоречите сами себе. Если счетчик не работал, но он не мог бы зафиксировать отказ. Что такое отказ? Это когда пользователь зашел на страницу и быстро ее закрыл. Если бы счетчик запаздывал (загружался бы после реакции пользователя), то он не смог бы зафиксировать отказ. А у вас счетчик считает отказы, это как раз говорит о том, что счетчик все видит и считает. Не работает - это когда перестает видеть отказы. В вашем случае должно было бы быть меньше отказов, т.к. неработающий счетчик их не мог бы ловить на ранней стадии. Также задайтесь вопросом у скольких пользователей стоит в браузере adBlock, adGuard и сколько информации вы вообще не получаете от Метрики, которая целиком и полностью блокируется в таком случае? Также не забывайте про собственный косяк с Метрикой. Отчего вы в своих "объективных" выводах закрываете глаза на изначально некорректно работающую по вашей вине Метрику?
-
Любая теория подтверждается или опровергается практикой. К чему фантазии? Проверяется все банально просто. Например, на сайте работают Метрика и Аналитика одновременно. Как известно, идентичными их показания никогда не бывают. Можно ли уже на этом основании заявлять, что один из счетчиков работает неверно? Думаю, что некоторые могли бы целую теорию на этом построить и в зависимости от убеждений гнать волну либо на Яндекс, либо - на гугл. Попробуйте сделать простой эксперимент. Используйте код Аналитики, который загружается как обычно и код Метрики, который загружается оптимизированным способом. Сравните показания в таком случае между Аналитикой и Метрикой. На протяжении какого-то времени. Потом сделайте вариант наоборот. Вы увидите, что эти показания будут различаться ровно на столько же как и до экспериментов. Можно еще сделать эксперимент. Ставите один счетчик Метрики с одним id в бронебойном варианте "загрузка картинки", т.е. от JS влияние будет нулевым. И второй оптимизированный счетчик, но с другим ID. Сравниваете показания обеих Метрик. в вашем случае вообще неуместно говорить про объективность и "правильность". У вас с самого начала работают счетчики неправильно. У вас то три метрики сразу работают, то две одновременно. Почему вы решили, что можете ставить как угодно Метрику, где угодно и сколько угодно и при этом говорить о какой-то "объективности"? Вам бы для начала стоило убрать ошибки. Это анекдот уже какой-то получается.... Вы сравнивали показатели когда у вас было три метрики, а потом стало две метрики? А если начнете сравнивать с ситуацией когда вместо двух метрик стала одна метрика, то будете уверять снова, что у вас Метрика работает "неправильно"? Вы же изначально дурачите Яндекс с Метриками, установленными в нескольких экземплярах! Где там все знающие про пессимизацию? Будет ли сайт пессимизирован из-за того что владелец сайта дурит Яндекс кучей одновременных Метрик с одинаковым ID на сайте? Может быть это ради накрутки сделано чтобы подняться в ТОП? Или это банальная ошибка, вызванная непрофессионализмом? В любом случае есть выбор: оптимизировать или нет счетчики. Это выбор владельца сайта. Если вы верите, что от этого будет вред, то не оптимизируйте счетчики.
-
так у вас эта проблема и на компьютерах есть. впрочем, это не суть. у вас есть артефакты еще до начала работ. Подергивания из-за lazy load и т.п. подобное у вас с самого начала есть и никуда бы не рассосалось само собой. Что не так? Я вас спрашивал Это будет, как минимум, некорректно с вашей стороны. Здесь же не рекламная площадка сторонних услуг, это раз. Да и разбирать минусы разработок и подходов других авторов - это тоже будет не комильфо, это два. И для корректного сравнения нужны одинаковые условия. С плавающим откликом сервера вообще сложно говорить о корректных замерах.
-
все верно. именно так у вас благодаря изначально заложенной в шаблоне концепции JS загружается страница. Выше я уже сделал пояснение на эту тему. Но ощутимо заметить это можно лишь при низкой скорости интернета и/или малой мощности железа. Особенность вашего шаблона в том, что страница не строится в основном и сразу на основе HTML и CSS, как это делается обычно в большинстве случаев. У вас перестроение страницы идет за счет JS. В совокупности с гигантским кол-вом узлов 12 000+ такое перестроение не может быть быстрым и идеальным. С таким тяжелым шаблоном нужна просто более долгая работа в плане оптимизации. Я лишь вам показал, что можно сделать на скорую руку бесплатно. Я не делал никаких экспериментов в стиле "а вот если так, то будет ли лучше". Всегда можно постараться сделать лучше, но вы дали четко понять, что вас не устроит никакой результат кроме 90+ или, на худой конец, 80+. Я никогда не утверждал, что могу сделать идеальный результат за 3000 р. на любом сайте. Попробовали? Не понравилось? Не используйте дальше. В чем вопрос? Просто на демо шаблона узлов в 4 раза меньше, существенно меньше картинок и блоков, на демо это не так бросалось бы в глаза. Большой DOM - большие проблемы. Вообще, у вас изначально есть куда более серьезные проблемы, но они почему-то вас не смущают. На странице (там не работает Оптимизатор) у вас верстка разъезжается, блоки налезают один на другой, горизонтальный скролл. Переверните планшет из одного положения в другое и увидите баги и расползание верстки. Прошу заметить, что это у вас изначально такое поведение. Смысл обращать внимание на не очень существенные моменты и не замечать кучу других багов? Впрочем, это ваш сайт.
-
Проблема с summernote
sitecreator replied to Rashp's topic in Opencart 3.x: Setting and optimization
перейти на CKEditor и забыть про ужасы Summernote. Как вариант. Вы можете попробовать еще один вариант (в нем уже многие баги исправлены)
