Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

sitecreator

Users
  
  • Posts

    6,116
  • Joined

Everything posted by sitecreator

  1. Объяснить здравым смыслом поведение оценок гугла бывает крайне сложно. Если у вас несколько файлов CSS, JS и вы их еще не склеили в один, то гугл вас будет жестоко наказывать за это баллами. Абсурд? Совершенно верно, это - абсурд когда у вас включен на сервере протокол http 2. Склеили на сайте (сервер с http 2) кучу CSS, JS в два больших файла. И гугл словно идиот этому радуется и показывает кучу новых попугаев сверху. Но на деле фактическая скорость никак не изменилась. гугл не учитывает протокол http 2? Т.е. гугл уверен, что у всех браузеры настолько древние, что понимают только http 1.1? Почему много файлов при http 1.1 - это плохо, а при http 2.0 это не имеет значения? Дело в том, что в случае http 1.1 на каждый файл создается отдельное соединение и потом закрывается после получения файла. Открытие соединения 0 это затратная по времени операция и дополнительный трафик в виде служебной информации. В случае http 2.0 создается одно соединение для кучи файлов, т.е. http 2.0 уже сам на уровне протокола "склеил" файлы в один, а потому даже общий трафик будет меньше, т.к. служебной информации отправлять нужно меньше для одного соединения. Алгоритм подсчета попугаев за склейку файлов - это полнейшая профанация при наличии протокола HTTP 2. Но гугл упорно не замечает этот протокол. Разумного объяснения этому нету. Или есть? Надо также заметить, что в итоге гугл оценивает сайт не по эмуляции, а по реальным показателям скорости, который гугл собирает на основе своих счетчиков. И именно по ним он в итоге ранжирует сайт. Смотрите все же на реальную скорость, а не на попугаев, полученных в результате эмуляции, которая бывает часто мифической. Видите насколько не соответствуют реальные замеры гугла по сравнению с его эмуляцией. Гугл наэмулировал отрисовку первого контента в 4 сек, а в реальности она по замерам самого же гугла (!) составила 1.7 сек. задержка эмулированная - 1320 мс, а в реальности (по объективным замерам гугла) - 225 мс. Т.е. видим, что эмуляция не отражает реальной картины. Т.е. гугл в эмуляции реально занизил баллы сайту, который в действительности работает весьма шустро. Причем шустро по замерам самого же гугла. гугл и сам пишет, что эмуляция - это фигня, причем часто неверная. А сам он смотрит на реальные замеры. Вот снизится время отклика страницы раза в два, то в реальности это будет ускорение, в том числе по реальным замерам гугла. Снизили вес изображений раза в два - это тоже реальное ускорение. Включили HTTP 2.0 - тоже реальное.
  2. С настройками сервера, которые я увидел, все может быть. вы что-то делали с настройками php и они у вас стали ниже минимально допустимых для опенкарт. например, у вас даже выключено расширение ZIP php было, про остальное молчу. 2 Мег выставлено было для загрузки как лимит, т..е. по умолчанию. Поднял. поправил. лучше писать в личку по таким частностям. неверно настроенный сервер напрямую к модулю не имеет отношения. Никакой проблемы с установкой после этого не возникло. все работает сейчас у вас на сайте нормально. Свежая версия стоит, не вижу никаких проблем.
  3. никакого в этом смысла нет. его понимает единственный браузер, который по недоразумению не хочет понимать webp. Чтобы проблем не было нужно хорошо разбираться в этом вопросе. Нужно уметь грамотно сгенерировать webp для сайта и грамотно его вывести в нужный браузер. При этом учесть ускорители, кешеры и т.д. и т.п. Бесплатные решения даже близко не учитывают всевозможные особенности сайта и хостинга. Все учтено и все решено при максимальной скорости создания WEBP в коммерческом модуле: https://opencartforum.com/files/file/4572-image-compressor-watermark-webp-lazy-load-etc-by-sitecreator/ Модуль совместим практически со всем, что используется.
  4. Помните историю про картинки-невидимки WEBP, которые создает GD для части картинок? вот вам такая картинка после GD. вы ее увидите в FireFox, но не увидите в Хроме. вот она просто ссылкой: https://watermark.sitecreator.pro/img_test/webp/slojprizma-1-100x100.webp Вот так это выглядит в Хроме: В FireFox это выглядит так: Начиная с версии 2.0.3 в модуле Компрессор устранена проблема картинок-невидимок, создаваемых графической библиотекой GD. Проблема порождена багом в библиотеке php GD, баг этот до сих пор не устранен разработчиком php GD. Но модуль Компрессор теперь научился компенсировать данный баг, а потому картинки WEBP теперь нормальные даже после GD, который можно использовать при отсутствии других альтернатив по созданию WEBP. Но при прочих равных рекомендуется использовать cwebp или imagick для генерации WEBP. В модуле вы можете выбирать движок (инструмент создания) webp сами.
  5. Помните историю про картинки-невидимки WEBP, которые создает GD для части картинок? вот вам такая картинка после GD. вы ее увидите в FireFox, но не увидите в Хроме. вот она просто ссылкой: https://watermark.sitecreator.pro/img_test/webp/slojprizma-1-100x100.webp Вот так это выглядит в Хроме: В FireFox это выглядит так: Начиная с версии 2.0.3 в модуле Компрессор устранена проблема картинок-невидимок, создаваемых графической библиотекой GD. Проблема порождена багом в библиотеке php GD, баг этот до сих пор не устранен разработчиком php GD. Но модуль Компрессор теперь научился компенсировать данный баг, а потому картинки WEBP теперь нормальные даже после GD, который можно использовать при отсутствии других альтернатив по созданию WEBP. Но при прочих равных рекомендуется использовать cwebp или imagick для генерации WEBP. В модуле вы можете выбирать движок (инструмент создания) webp сами.
  6. Реализована работа с полями картинок, которым можно задавать произвольный цвет. Скажите, пожалуйста, это хоть кому то нужно? Просто был один заказчик, уверявший, что это нужно и полезно. Сделал до кучи, правда, сомневаюсь, что время потрачено не зря. Помнится делал под яндекс-маркет возможность создания заказных стикеров (для продвижения в Маркете). Но кроме единственного заказчика это ни разу никому и не потребовалось...
  7. В Lazy Load внесены изменения. Вы можете выбрать способ создания Lazy Load. По эффективности способ через JavaScript более эффективный и работает во всех браузерах. Даже гугл его оценивает выше. Своой алгоритм гугл оценивает на 96, а мой JavaScript Lazy Load на 97 Первый способ менее эффективный (особенно когда картинок много), но безконфликтный с другим Javascript. Работает только в Хроме. Второй способ самый эффективный, но при наличии метрики Яндекса с вебвизором его эффективность сильно убивается. А метрика у всех подключена через жо одно место. Из-за того что метрика подключается рано, то она пытается "отслеживать" загрузку каждой картинки через lazy load. Безусловно, что это очень "полезная" собираемая информация, ради которой непременно включается вебвизор, тормозящий страницу. При отсутствующем вебвизоре JavaScript Lazy Load отлично работает. При наличии метрики с вебвизором лучше включать вариант без JavaScript Lazy Load. Впрочем, любителям попугаев нужно знать, что наличие вебвизора понижает оценку на 20-30 баллов легко.
  8. В новой версии много принципиально нового. Переработан заново механизм создания и наложения водяного знака. Теперь этот процесс происходит на порядок быстрее (разов в 5 быстрее), фактически создание изображения и наложение водяного знака происходит за тоже время, что и просто создание изображений без водяного знака. При этом не имеет значения насколько сложные эффекты вы применили (поворот, изменение прозрачности). Учтен печальный опыт любителей загружать водяные знаки размером 6000 х 4000. Они, конечно, удивлялись почему долго идет наложение такого водяного знака с поворотом на 13 градусов и прозрачностью 97%. Поскольку водяной знак был не очень востребован, то внимания к нему особого не проявлял. И надеялся на разумность пользователей, что, впрочем, зря как обычно. Они загружали водяной знак 6000 х 4000 для картинки 600 х 600, и будут загружать. Это невозможно остановить! Ну загрузили бы 300 х 300, в крайнем случае 600 х 600, т.е. не больше всплывающей картинки, т.е. самой большой. Чтобы потом не появлялись чудо-спасители от "тормозного" водяного знака и Компрессора by SiteCreator я полностью переработал механизм обработки водяного знака. Работает очень быстро как под GD, так и под Imagick. Грубо говоря, если у вас картинки на странице создавались за 2.5 сек, то с водяным знаком будут создаваться за 2.7 - 3.0 сек. При этом с применяемыми эффектами. От лишних операций при наложении знака спасает многоуровневое кеширование и защита "от дурака" (от тех самых 6000 х 4000) Это в Новой версии 2.0.2
  9. Уважаемы заказчики, модуль Компрессор не исправляет автоматически все имеющиеся косяки на вашем сайте. Научитесь анализировать информацию от гугла, а не только смотреть на попугаев. Модуль снижает вес изображений, и делает это отлично (раза в два-три в среднем), добавляет отложенную загрузку (Lazy load) и делает прочие оптимизации изображений (приводит размер в соответствие с экраном смартфона, например), т.е. максимально выполняет рекомендации гугла в области изображений и, тем самым, реально ускоряет загрузку без оглядки на попугаев. Но, когда вы пять раз загружаете карту яндекса во время загрузки основной страницы, то это, естественно, тормозит ее и гугл вам это показывает в рекомендациях. Перестаньте смотреть на попугаев, но научитесь читать рекомендации гугла. А таком плачевном случае уберите хоть все изображения с сайта (снизьте с 10Мегабайт до нуля, например), но это вам не поможет, ибо карта яндекса будет грузиться, грузиться и грузиться! И будет грузить и тормозить весь ваш сайт. И JS будет работать по 5 секунд с лишним. в FAQ модуля все четко написано: Почему автомобиль на новой резине, но с неисправным двигателем медленно едет? Вес изображений == баллы гугла? Как Гугл измеряет скорость загрузки изображений. Чем она отличается от общей оценки Гугла PageSpeed.
  10. добрый. от конечных размеров не зависит. он режет исходники. а из исходников потом делаются разные "размеры". И к одному из "размеров" могут добавляться снова поля в зависимости от настроек. это лучше в личке смотреть на конкретных примерах с доступами.
  11. я мог бы добавить в модуль поле для регулярного выражения для заполнения пользователем. но пользователи все равно не умеют этим пользоваться, а могут только навредить. а в вашем случае без регулярок не обойтись. я так понимаю, что и окончание у ссылки может быть любое в общем случае. из описания модуля вообще ничего не ясно. непонятно как сделать универсальный вариант пока. модули под amp есть всякие и разные, и каждый делает по-своему. не имею возможность подстраиваться под всех. есть же модуль amp, который использует схему формирования url, которую предлагает гугл. но, впрочем, нормальных модулей под amp вообще не встречал.
  12. в модуле отключен JS для amp страниц. Это рекомендации гугла. для таких страниц отключено. и это работает у пользователей как надо на реальных проектах. другое дело, что не все следуют рекомендациям гугла. если у вас сделано нестандартно, то тогда мой подход не сработает. Я несколько позже добавлю возможность вносить вручную исключения. Но пока в приоритете другие задачи. Вы всегда можете ускорить реализацию за вознаграждение. Правила по доработкам: https://opencartforum.com/files/tutorials/59-{%3F}/
  13. Не встречал такого софта. Мог бы разработать. За вознаграждение, разумеется.
  14. Совершенно верно. И вы вправе выбирать сами необходимую вам стратегию создания сжатых изображений. WEBP рекомендуется как основной вариант. Mozjpeg - как запасной. Можно использовать также совместно Mozjpeg + WEBP в случае если мощности позволяют. Просто WEBP в плане создания нагрузки на сервер в момент создания сжатого изображения имеет большой плюс в сравнении с Mozjpeg - это время создания, т.к. WEBP работает раза в три быстрее при одинаковой эффективности (по сжатию) в сравнении с Mozjpeg. У Mozjpeg тоже есть свои преимущества. У нас есть пока единственный современный браузер (точнее - система, а еще точнее - движок браузера), который не поддерживает WEBP. Это Сафари. Вот ради него и нужны дубли картинок в JPG, PNG. Сжатый JPG (за счет Mozjpeg) тут будет кстати как раз. Вообще, apple из-за странной конкурентной политики лишает своих пользователей многих передовых технологий.
  15. Добрый! А зачем нужно несколько разных кешей? Если вы используете сжатие mozjpeg, например, то количество файлов в кеше будет не больше прежнего, может и меньше быть, но общий вес может снизиться процентов на 30%-40%, нередко на 50%. Совершенно точно, что суммарный вес будет существенно ниже. будет сформирован новый кеш вместо старого. В таком случае вам webp использовать не стоит, раз у вас " лимиты на inod ". Правда, обычно меняют тариф или хостера подходя к такому пределу. mozjpeg - это выход в вашем случае.
  16. Сегодня столкнулся с ошибкой на одном из сайтов. Белая страница или фатальная ошибка. что видим? Памяти 16М? Я меньше 128М не встречал за последние годы ни у одного хостера. Катастрофически мало выделили.
  17. FAQ по модулю Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator Для Opencart 3.0 и Opencart 2.* С поддержкой WEBP, Lazy Load и др. Дистрибутив теперь универсальный (он один) для движка 2-й и 3-й версий. Начиная с версии 1.18.3 Свежий дистрибутив вы можете всегда скачать с сайта автора, предварительно зарегистрировав сделанную вами ранее покупку. Место покупки значения не имеет. Важен факт ее наличия, который вы подтверждаете №, датой и местом покупки.
  18. Для Opencart 3.0 и Opencart 2.* С поддержкой WEBP, Lazy Load и др. Дистрибутив теперь универсальный (он один) для движка 2-й и 3-й версий. Начиная с версии 1.18.3 Новая версия доступна для скачивания у разработчика. сайт разработчика совпадает с ником разработчика: Как скачать новую версию написано в FAQ модуля: Где брать НОВЫЕ ВЕРСИИ модуля Compressor & Watermark & WEbP & etc?
  19. Не имеет значения где вы купили модуль и для какой версии. Вам будут доступны все дистрибутивы. Т.е. для движков опенкарт 1.5, 2.*, 3.0 Начиная с версии модуля 2.0 дистрибутив будет одинаковый для всех версий движков: 1.5, 2.*, 3.0 Сейчас два дистрибутива: 1) для opencart 2.* и opencart 3.0 единый дистрибутив начиная с версии модуля 1.18.* 2) отдельный дистрибутив для опенкарт 1.5
  20. Для Opencart 3.0 и Opencart 2.* С поддержкой WEBP, Lazy Load и др. Дистрибутив теперь универсальный (он один) для движка 2-й и 3-й версий. Начиная с версии 1.18.3 Новая версия доступна для скачивания у разработчика. сайт разработчика совпадает с ником разработчика: Как скачать новую версию написано в FAQ модуля: Где брать НОВЫЕ ВЕРСИИ модуля Compressor & Watermark & WEbP & etc?
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.