sitecreator
-
Posts
6,116 -
Joined
Content Type
Profiles
Forums
Marketplace
Articles
FAQ
Our New
Store
Blogs
module__dplus_manager
Everything posted by sitecreator
-
Не нужно мне указывать, что делать. Я вам предложил как решить вашу задачу, как минимум, двумя способами исходя из собственного опыта потому, что уже решал подобное. И в процитированном вами тексте как раз указано решение. Модуль Компрессор легко адаптируется для вывода изображений Ретина. Если вы этого не поняли или вам не нужен такой способ - это ваше дело. действительно, осталась мелочь. дерзайте. -
Эта информация поможет в расчете стоимости "полностью под ключ "? Т.е. вы ее привели чтобы показать, что часть бюджета (189 руб) уже освоена? Вообще, тут не приветствуются темы "создать хороший магазин", ибо это тема "ни о чем". Лучше начать с вашего планируемого бюджета. В соответствии с бюджетом получите результат. Раз нет даже крохотного наброска задания, то как еще?
-
Здравствуйте. С данным шаблоном проблем не припоминаю. Но вам нужна версия модуля под 3-ку. Она есть тут на форуме. Адаптация возможна для любого шаблона. Самое сложное, что встречал - это шаблон journal 3. Фактически это уже не шаблон, а переделанный опенкарт. Но и с этим шаблоном нет проблем если не включать адаптивный ресайз средствами шаблона, а воспользоваться таким ресайзом в самом модуле Компрессор. Проблемы может вызывать только включенный в шаблоне собственный ресайз. Но таких шаблонов буквально единицы. И они тоже работают при обозначенном выше условии (отключается в шаблоне свой ресайз). Например, для шаблона Лайтшоп в модуль встроена уже адаптация под нестандартный адаптивный ресайз, который генерирует шаблон. Подобных шаблонов есть еще штуки три на тысячи остальных. Но пока адаптацию никто не заказывал, т.к. люди просто не включают нестандартный ресайс с обрезкой в шаблонах. Адаптивный ресайз можно включить в модуле Компрессор. И можно включить свой тип такого ресайза для определенной страницы и определенных изображений на ней. Т.е. не для всех изображений разом. Кроме того для основного и всплывающего изображений доступны собственные настройки полей и размеров.
-
Скажем так, простыми средствами вы это не сделаете. Как пример реализации. В шаблоне journal 3 встроена поддержка Ретины. Никаких дополнительных модулей при этом не нужно. Т.е. создаются и выводятся такие изображения за счет самого шаблона. Нужно, правда, помнить, что это уже не вполне шаблон, а переделенный опенкарт. Т.е. возможны сложности с совместимостью некоторых модулей. Но именно с journal , который неплохо поддерживает Ретину совместим модуль Компрессор. Модуль Компрессор добавляет к поддержке Ретины сжатие и формат webp. Единственное, что я не делал для journal - это адаптация под ехо механизм адаптивной обрезки. Т.е. нужно в шаблоне отключить такой механизм, а при небходимости пользоваться адаптивной обрезкой, которая заложена в модуле Компрессор. Что еще полезного может дать модуль Компрессор? А вот это даже без поддержки Ретины. И все в автоматическом режиме. Т.е. модуль Компрессор сам создает и выводит уменьшенные изображения там, где нужно. А где нужно? Например, баннер шириной 1920 пикс. Такой баннер будет неуместен на экране шириной вьюпорта 360 пикс, о чем вас непременно уведомит гугл. Возможности модуля Компрессор для опенкарт 3.0 пока несколько уступают возможностям для 2.*. Но это временное явление и связано со слабым интересом вообще к версии опенкарт 3.0 как таковой. большинство даже новых магазинов делается на более стабильной версии 2.3. Модуль тут: Он же для 3-ки: В принципе возможны любые необходимые для вас разработки и доработки в области изображений. Разумеется, за счет заказчика. Пока что тема "Ретины" не находила отзывов в сердцах заказчиков, потому и не делал. Но, повторюсь, что есть вот это (в реализации для опенкарт 1.5 & 2.*) Хотя и тут мало кто из заказчиков может оценить даже эту полезную (в плане контроля лишнего трафика и ускорения загрузки) возможность модуля.
-
У меня есть вариант для 3-ки. Сделаю обновление на днях. Загружу версию для 3-ки.
-
Все же сильно по-разному эмулирует insights на сайте гугла и непосредственно в Хроме. Видно по скриншотам формирования страницы. Да и показатели Speed Index сильно разнятся, как и Макс. потенциальная задержка после первого ввода. В общем, совершенно непонятно почему такая разная эмуляция. И непонятно как вообще относиться к этим цифрам. Я бы понял когда разница на 20%, но не в пять же (задержка) раз?
-
верно. какой-то непонятный глюк гугла. При желании можно использовать некий прием для обмана гугла, а именно - загружать стили и картинки с определенной задержкой когда гугл уже завершил свой тест. Разумеется, это будет примитивный обман, не имеющий ни малейшего отношения к реальной производительности. А потому это никому не нужно кроме любителей посмотреть фокус.
-
Кажется, немного понял. Гугл, похоже, использует такие параметры для теста производительности. Тогда на своем десктопе получаются результаты как и гугла на сайте, точнее, они максимально близкие. Но тоже плавают.
-
В предыдущих сообщениях уже писали, что инструмент insights от гугла временами как-то странно загружает изображения. Т.е. от порядка их загрузки сильно скачут попугаи. Гугл неведомым образом сам определяет такой порядок загрузки. Обратили внимание, что сильно влияет момент загрузки фонового изображения. От этого идут пляски попугаев. А вот тут гугл "забыл" на совершенно исправном сайте вообще загрузить картинки. А потому оценка сразу взлетела! Я всегда писал, что самая быстрая страница - это без картинок и с минимумом текста, а самая быстрая - это просто белый лист. Т.е. картинки влияют на оценку гугла. Но, т.к. гугла периодически глючит и клинит, то к баллам нужно относиться скептически. Даже когда его и не клинит, то все равно - скептически!
-
Еще интересный момент. При использовании Lighthouse in Chrome DevTools Получаем результат на эмулированном Nexus 5X с симулированным процессором смартфона (грубо говоря, на тактовой в 4 раза ниже десктопа, в моем случае симуляция 1000 Мгц) плюс симуляция медленной сети. Результат: вот тут https://developers.google.com/speed/pagespeed/insights гугл указывает, что использует точно такой же инструмент для имитации (эмуляции_симуляции). Но почему производительность по гуглу у такого же инструмента lighthouse на странице гугла уже иная? Здесь у гугла какая-то иная производительность? Т.е. в одном случае - 98, а в другом - 84? Или 84 - это не производительность, а нечто иное?
-
В качестве демонстрации как влияют изображения на "мозги" гугла. Расценивать можно как прикол! Вот тут гугл глюканул и "забыл" загрузить вообще изображения. И сразу 90+. Это при совершенно исправном сайте. Убедительная просьба читать внимательно и не воспринимать как демонстрацию достижений. Также зрячий увидит, что гугл таки оценивает скорость загрузки по реальным замерам на реальных устройствах пользователей, о чем он и пишет прямо в самом начале.
-
да это так и есть. некешированный вариант рассматривать нет смысла. некешированный будет отдан 1 раз, к примеру, но потом 1000 раз уже кешированный. И, верно, формально попугаи погоду не делают. Важна только фактическая скорость и производительность. Нет смысла фанатично смотреть в сторону попугаев. Тут вообще никто и не спорит. Если заказчик решил, что webp, позволяющий в среднем сжать раза в два (и более), будет полезен в его случае, то пусть использует. В любом случае при этом лишний трафик для смартфонов уменьшится, что будет положительно. Но если заказчик считает, что не нужен ему webp, то тоже будет прав.
-
а что же вы не полностью цитируете? давайте будем любой сайт проверять принудительно задавая limit=500? Повторюсь. Я всего лишь показал пример боевого сайта. Просто как пример комплексной работы. За счет сжатия выигрыш в весе на уровне 30%-40%. Я нигде не писал, что сайт работает быстро по версии гугла лишь благодаря этому. Когда я делал сайт, то вообще на гугл не смотрел. Просто была задача - сделать быстрый сайт. Просто был вопрос: а умеет sitecreator делать сайты? Я отвечал на этот вопрос.
-
Вы правы. Вы немножко соврали. задали 500 товаров для вывода? Так таким образом можно любой сайт опустить. При том, что максимально можно выбрать 96. И при этом удивляться, что некешированная страница на 500 товаров быстро не загружается? Пользователь же просматривает за счет кнопки "показать еще" и не будет в смартфоне набирать в адресной строке limit=500 некешированный ответ для 500 товаров на страницу 1.2 сек. даже не знаю к чему вы тут можно докопаться. Просто я сообщение писал не столько относящееся к модулю как таковому. Просто проскочило ранее, что Sitecreator не умеет делать быстрые сайты, да и сайты вообще. А указанный сайт делался вообще без учета новых тенденций гугла в оценке методом попугаев, но, тем не менее, работает очень шустро визуально. Это просто пример моей работы.
-
Используется оптимизация (как для снижения веса, так и для более комфортного отображения) белых полей: Водяной знак используется. В плане сжатия используется mozjpeg + optipng. Просто нужно понимать, что совсем недавно гугл до смены своего алгоритма расчета попугаев только за оптимизацию изображений накидывал 30-50 баллов сразу. Это было и это факт. Во многих случаях достаточно было лишь оптимизации картинок. После смены своего алгоритма оценки Гугл уже не позволяет выехать лишь на одной оптимизации изображений. Гугл уже не считает оптимизацию PNG за счет optipng оптимизацией, а потому предлагает использовать WEBP. Если у вас товары используют картинки в PNG, то общий вес можно снизить в несколько раз за счет WEBP. Немало встречал таких магазинов, для которых поставщики дают изображения только PNG, да еще с прозрачным фоном нередко, а это уже колоссальный вес получается. За счет WEBP можно его снизить в 2-7 раз. Сейчас же с приходом нового алгоритма гугла, например, если у вас JS крутится секунд 15, то даже если вы с 10М снизите вес изображений до 1М, то гугл может отделаться добавлением вам 10 попугаев, не смотря на то, что вес загружаемой страницы существенно снизился. Т.е. возросла роль других факторов. Но это не означает, что реальный пользователь не заметит ускорения страницы за счет снижения веса в несколько раз. Гугл, разумеется, перестает ругаться на картинки при этом. В итоге что? Рекомендации гугла в плане изображений выполнили? ДА. Вес изображений снизился и за счет этого страница стала грузиться быстрее? Да. Гугл оценил это в виде дополнительных баллов? Если критических проблем нет в других местах, то гугл накидывает, например, 10-30 баллов. Если есть критические места, то над ними нужно также работать, при наличии серьезных проблем (по мнению гугла) он накинет в лучшем случае баллов 10 или вообще ничего Почему автомобиль на новой резине, но с неисправным двигателем медленно едет? Вес изображений == баллы гугла? Я давно написал эту статью в FAQ. Говорю все как есть. Лишь одна из задач модуля - это оптимизация изображений за счет сжатия. Если у вас не работает сжатие или не работает создание webp и его вывод, то тогда вопросы ко мне по работе модуля Компрессор. Если у вас не взлетели баллы с 20 до 90 в гугле - это уже не к модулю Компрессор вопрос. Рекомендации гугла выполнили в плане изображений? Значит, нужна оптимизация остального тоже. Я занимаюсь комплексной оптимизацией если у заказчика есть непременное желание нарастить попугаев, но это уже доп. работа.
-
немного статистики. Напрямую с изображениями это не связано. просто реальный магазин, сделанный с нуля. включая разработку многих модулей и дизайн с версткой. Тут довольно уникальная корзина, учитывающая специфику магазина, когда в корзине могут быть 50+ товаров. Разработка полностью моя. Товаров 15 000+ В сезон просмотров 300 000+ и посетителей 4000+ Сейчас несезон (запчасти для мото) Попугаи обычно в пределах 80-90 пляшут для мобильной версии, для десктопа обычно 95+. отклик любой страницы 50 -150 (200) мс версия модуля Компрессор тут довольно старая, а потому webp не используется, но есть mozjpeg. Lazy Load тут также нет. Переезжать магазин будет на новую версию движка (здесь 1.5), тогда и смысл будет все остальное подтянуть, включая попугаев 90+. Магазин на старой версии 1.5. Хозяин магазина решил, что для него попугаев достаточно пока выше крыши с учетом того, что новая версия магазина будет сделана уже на свежей версии. Магазин делался еще во времена когда у гугла был иной подход к попугаям чем сейчас, и был всегда в зеленой зоне. Но главное - это не попугаи, а реальная скорость работы.
-
Забавно гугл реагирует на собственную аналитику, которая что-то там тормозит (заблокировала)
-
я не знаю, что и как вы делали и в какой последовательности. Единственное, что вижу - это у вас файл от версии 1.17.* ничего не понял. Режим работы php не имеет значения. Но желательно перезагрузить веб-сервер с новым конфигом php. Достаточно в конфиге изменить хотя бы один параметр. И в чем проблема переустановить модуль? Пожалуйста, пишите в личку. Тут никому не интересны нюансы ваших попыток то ли восстановить что-то из бекапа, то ли еще чего-то. Когда делают бекап, то это вообще не влияет ни на что. Вероятно, что вы имели ввиду "восстановились из бекапа"? Пожалуйста, пишите точнее. В личке. И сразу с доступами
-
новый кеш и так автоматически будет создан. Нет никакого смысла в ваших ручных действиях. Любая страница будет открыта пользователем или поисковым роботом. У вас изображения создаются по расписанию для страниц, которые хотя бы раз открывались. Нет никакого смысла создавать изображения для страниц, которые удалены или которые никогда не посещаются.
-
Заблуждение. никакой дополнительной нагрузки не создается. В любом случае ощутить вы ее не сможете. тот же webp создается один раз в кеше ровно также как и любое другое изображение в кеше. webp создается очень быстро даже в режиме "на лету". Кроме того есть режим создания сжатых изображений по расписанию. Уж в этом случае хоть 1 000 000 + изображений у вас будет, то никаких проблем с нагрузкой нет. Задаете режим создания, например, с 2-00 до 4-00 ночи, выбираете желаемую степень нагрузки - и никаких проблем! Всегда рекомендую использовать именно сжатый формат WEBP везде где возможно. А возможно это в 99%+ случаев. Фактически модуль сейчас может работать с webp у любого хостера. Не только создавать, но и выводить. Что толку если вы создали и загрузили webp вручную? Ведь его вывести надо в нужный браузере. А это (вывод) не получится в 95% на общем хостинге. А модуль умеет выводить webp практически всегда, т.е. в 99% случаев. Модуль Компрессор выводит грамотно WEBP с учетом особенностей шаблонов, наличия кешеров и ускорителей, с учетом lazy load и много чего другого, например, изображений для экранов Ретина. Выводит с учетом браузеров, которые не поддерживают webp. Видимо, вы не вполне знаете как движок работает с изображениями. Не имеет значения, что именно вы загружаете. Движок обрабатывает (ресайз, поля) изображения и помещает их в кеш с новым именем. Модуль оптимизирует загрузку изображений на сайте за счет lazy load. Кроме того есть такая фишка: Вместо того чтобы на смартфон загружать тяжелые баннеры шириной 1920 пикс можно и нужно загружать соответствующие ширине вьюпорта (не путать с физическим разрешением матрицы экрана!) смартфона легкие по весу изображения. Вот это тоже умеет модуль. И такие изображения нужной ширины и веса он создает автоматически и автоматически подставляет. В большинстве случаев можно сделать более удобный просмотр картинок без ненужных полей, особенно это полезно на смартфоне. И это также сильно уменьшает вес дополнительно. Написанное относится к актуальным версиям модуля, а именно речь идет о 1.16.5 и 1.17.* В старых версиях все несколько иначе и в очень старых нет поддержки вывода WEBP. Только какой смысл говорить про старые?
-
чисто визуально так оно и есть. Но только не могу понять как такое происходит с одной и той же страницей? без какого-либо изменения кода. Я просто делал последовательные замеры попугаев. И они скачут с интервалом в 30 сек. Как так гугл умудряется моделировать, что у него всегда разный Speed Index? При том, что на сайте даже нет скриптов со сторонних сайтов за исключением аналитики от гугла. Получается, что если по какой-то неведомой причине виртуальный браузер гугла загружает картинку фона позже всего, то выставляет мало баллов. А если загружает картинку фона сразу, то баллов получается много. При этом совершенно непонятно, что именно может влиять на такое поведение этого виртуального браузера. Эмуляция - хрень еще та. Надо будет проверить это предположение.
-
Индекс скорости: Пытался понять по прогрессии в картинках чем же она лучше в данном конкретном случае чем на приведенных ранее скриншотах? И тут уже самый длинный TTFB (за всю серию последовательных замеров) никак не мешает получить самую высокую итоговую оценку. Какой-то магический этот Speed Index. И по мнению гугла вроде как не зависит от скорости парсинга HTML & CSS, рендеринга и JS. Ну никак не могу понять как при лучших скорости парсинга HTML & CSS, рендеринга и JS этот Speed Index может быть хуже. Могу предположить, что Speed Index измеряется неверно.
-
да, от одного идиотизма в оценке гугл избавился, но прибавил зато других, не менее странных критериев, которые не дружат с логикой и здравым смыслом.
-
В точку! Совершенно точно! Именно с этим и сталкиваюсь. например, сегодня. Вес изображений 7.5 Мегов. Отклик страницы 1.2 сек. Про отклик гугл молчит вообще, но кричит, что нужно снизить вес изображений. Ок. Снизил вес изображений до 700 К, т.е в 10 раз! Гугл проснулся и... увидел, что отклик велик и составляет более 1 сек. При том, что яндекс видит этот отклик независимо от того сколько изображений на сайте. Не смотря на то, что реально страница начинает грузиться быстрее на смартфоне с 3G за счет снижения веса с 7 Мегов до 700 К, но гугл уже начинает снижать баллы за "долгий отклик". А пока вес картинок был невъе внушительным, то он отклик вообще не считал, получается? Абсурд какой-то.
-
смотрите вторую пару для сравнения. там результат противоречит вашему выводу. у меньшего TTFB и баллов в итоге меньше. хотя я тоже сперва думал как вы. Не могу понять логику.
