Пошук по сайту

10 Скачать / Купить дополнение Кеширование Redis Драйвер кеширования Redis для Opencart 1.5.x - 3.x Redis — это высокопроизводительное распределенное хранилище данных. Высокая скорость работы обеспечивается за счет хранения данных в оперативной памяти, которые периодически сохраняются на диск. Для работы модуля необходим включенный Redis на сервере и библиотека php-redis Инструкция по установке Opencart 2.x - 3.x Стандартный установщик модулей. Opencart 1.5.x Распаковать архив в корень сайта. Добавить константы в файлы config.php и admin->config.php // Redis define('CACHE_HOSTNAME', '127.0.0.1'); define('CACHE_PORT', '6379'); define('CACHE_PREFIX', 'redis_'); define('CACHE_PASSWORD', ''); Redis для Opencart 3.x В OpenCart 3 драйвер Redis уже присутствует. В модуле заменены устаревшие функции и добавлена авторизация. Файл system->config->default.php Изменить $_['cache_engine'] = 'redis'; На $_['cache_engine'] = 'redisp'; Redis для Opencart 2.2 - 2.3 Файл system->config->default.php Изменить $_['cache_type'] На $_['cache_type'] = 'redis'; Redis для Opencart 2.0.x - 2.1.x Файл index.php и admin->index.php изменить $cache = new Cache('file'); На $cache = new Cache('redis'); Redis для Opencart 1.5.x файл index.php и admin->index.php изменить $cache = new Cache('file'); На $cache = new redis_cache(); После require_once(DIR_SYSTEM . 'library/cart.php'); Добавить require_once(DIR_SYSTEM . 'library/redis_cache.php'); Если вы используете VQMod добавить require_once(VQMod::modCheck(DIR_SYSTEM . 'library/redis_cache.php')); Добавил SirGrey Добавлено 20.11.2019 Категория SEO, карта сайта, оптимизация Системные требования Метод активации Без активации Ioncube Loader Нет ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 1.5.5.1.2 1.5.5.1.1 1.5.5.1 1.5.4.1.2 1.5.4.1.1 1.5.4.1 1.5.3.1 1.5.2.1 1.5.1.3 OpenCart.Pro, ocShop Не проверялось Обращение к серверу разработчика Нет  

Данная запись содержит личный опыт и наблюдения, как собственные, так и клиентские, поэтому не претендую на истину в последней инстанции и с удовольствием ознакомлюсь с аргументированной критикой. Убедительная просьба в комментариях придерживаться уважительного тона общения, дабы сохранить запись в удобочитаемом виде для всех желающих. Содержание записи для многих будет очевидно и понятно, однако есть немалое количество людей, которые до сих пор верят определенным мифам о PageSpeed, поэтому цель всего этого чтива – развеять мифы, простым и понятным языком объяснить, что же это за звери такие – попугаи PageSpeed, на что они влияют и с чем их едят, а в будущем при очередном повторении все тех же вопросов – отсылать пользователей на эту запись. Миф №1: Оценка PageSpeed влияет на позиции в поисковиках Как можно убедиться в документации Google, баллы PageSpeed действительно показывают оценку скорости работы сайта, а скорость работы сайта, как говорится в блоге Google для вебмастеров, действительно является фактором ранжирования поисковой выдачи. Итого мы имеем два утверждения, которые нередко преподносятся следующим образом: Баллы PageSpeed = оценка скорости работы сайта Скорость работы сайта = фактор ранжирования поисковой выдачи И вот, ознакомившись с этими двумя утверждениями, нередко можно увидеть и третье утверждение, которое эксплуатируется некоторыми разработчиками и фрилансерами, занятыми «накруткой» баллов: Баллы PageSpeed = фактор ранжирования поисковой выдачи Это утверждение ошибочно по одной простой причине – «оценка скорости работы сайта» и «скорость работы сайта» – это не тождественные понятия, хоть они и взаимосвязаны, но лежат в совершенно разных плоскостях. Даже у такой могущественной корпорации, как Google, нет ни физической возможности, ни реальной необходимости регулярно прогонять все сайты из поисковой выдачи через PageSpeed, поэтому в ранжировании принимают участие вовсе не конкретные цифры из PageSpeed, а гораздо более объективные и реалистичные данные, к примеру, из пользовательских метрик, в частности, фактическая клиентская скорость загрузки сайта из Google Analytics. Почему сам Google не должен и не будет полагаться на цифры из PageSpeed для поискового ранжирования? Есть немало причин: Этими данными легко манипулировать (их можно накрутить до невероятных значений, подсовывая боту не тот контент, что получат пользователи) На эти данные значительно влияет география серверов (утрированный пример – представьте себе скорость загрузки магазина на серверах, работающих в Минске, для бота, заходящего из США) Оценка и многие рекомендации PageSpeed ориентированы в первую очередь на пользователей интернета в США и Канаде, где технологии значительно отличаются от наших реалий (к примеру, в плане распространения ADSL) Результаты оценки имеют слабую точность и повторяемость, поскольку зависят от доступности сети и ее состояния в момент проверки, из-за чего два оценивания подряд могут иметь разброс в десятки пунктов Данные PageSpeed изначально не предназначены для оценки того, «любит» ли Google ваш сайт, а лишь для того, чтобы обнаружить узкие места в работе сайта Из всего вышеперечисленного легко сделать вывод о том, что оценка PageSpeed не имеет и не может иметь прямого влияния на позиции в поисковой выдаче, однако не спешите закрывать PageSpeed Insights и облегченно вздыхать – хоть у этой оценки и нет прямого влияния, это вовсе не значит, что красные циферки 17/42 можно игнорировать, поскольку стабильно плохие показатели (в красной зоне) сигнализируют о том, что с сайтом есть проблемы. Особенно если речь идет о крайне долгом отклике сервера и времени загрузки до взаимодействия – такие симптомы будут серьезно влиять и на поведенческие факторы, ведь никто не станет сидеть на вашем сайте минуту в ожидании его полной загрузки. Поэтому сильно проседающие показатели можно и нужно выводить до более-менее приемлемого уровня, ориентируясь на самостоятельные наблюдения и на те самые вышеупомянутые метрики, среди которых можно выделить процент отказов как один из индикаторов того, «нравится» ли посетителям ваш сайт. Если же вы переживаете из-за красной зоны, т.к. надеетесь, что поисковый трафик обеспечит вам основную часть продаж, то можно уже не переживать – с большой долей вероятности вы и так скоро закроетесь, потому что сегодня на одном только поисковом получится выехать лишь в очень узких, региональных и неконкурентных нишах. Это является еще одним аргументом в пользу того, что не стоит гнаться за оценкой 99/100, лучше направить эти ресурсы на более важные вещи – на рекламу или контент. Миф №2: PageSpeed показывает скорость работы шаблонов Так уж сложилось, что мне знакома ситуация с шаблонами, поскольку нередко ко мне обращаются с подобными вопросами о том, какой шаблон «быстрее», а в качестве аргументов рассматриваются именно цифры PageSpeed из демо-сайтов шаблонов. При этом данный миф активно эксплуатируется некоторыми авторами шаблонов, которые указывают в роли преимуществ шаблона его скорость работы и ссылаются при этом на конкретные цифры PageSpeed. Тут надо напомнить немного теории. На формирование итоговой оценки PageSpeed влияет множество факторов, значительная часть которых вообще не связаны с шаблонами, а зависят исключительно от настроек сервера и его времени отклика, наличия кеширования, оптимизации графики сайта и прочих технических особенностей. В частности, среди ключевых метрик рассматриваются три важнейшие: Отрисовка крупного контента (Largest Contentful Paint, LCP) - время, за которое браузер отрисовывает самый крупный видимый элемент в области просмотра. Отсчет начинается с того момента, когда пользователь запрашивает URL. Самым крупным элементом контента обычно является изображение или видео, но это также может быть объемный блочный элемент с текстом. Этот показатель важен, так как появление первых элементов на экране говорит посетителю сайта о том, что URL загружается. Первая задержка ввода (First Input Delay, FID) - время между первым взаимодействием пользователя со страницей (нажатием на ссылку, кнопку и т. д.) и ответом браузера. Учитывается нажатие на любой интерактивный элемент. Этот показатель позволяет оценивать эффективность страницы, на которой пользователи могут предпринять какие-либо действия, и определяет, с какой скоростью реагируют интерактивные элементы на ней. Совокупное смещение макета (Cumulative Layout Shift, CLS) - показатель того, насколько элементы на странице смещаются во время ее загрузки. Значения показателя находятся в диапазоне от 0 (без смещения) до 1 (максимальное смещение). Этот показатель важен, поскольку смещение элементов страницы при загрузке плохо влияет на удобство использования сайта. Даже если не углубляться в детали каждой из метрик, достаточно рассмотреть первую - LCP (или похожую по сути FCP - First Contentful Paint), на значение которой влияют следующие важнейшие факторы, согласно документации: Медленное время отклика сервера Ресурсы JavaScript и CSS, блокирующие отображение Время загрузки ресурсов Рендеринг на стороне клиента Как видите, сразу на первом же месте идет то, что обычно никак не контролируется шаблоном и зависит в первую очередь не от него, а от того, быстрый ли у вас сервер. Аналогичная ситуация будет и со временем загрузки ресурсов (хотя «продвинутые» шаблоны могут плодить их количество) и множеством других пунктов, поэтому если вы попросите у авторов шаблонов, хвастающих высокой оценкой PageSpeed, хотя бы 5 примеров реально работающих (не пустых) магазинов на их шаблонах и проверите их через PageSpeed – вы и близко не увидите тех красивых цифр, которые видите при проверке специально подготовленных и вылизанных демо-сайтов шаблонов. Можно ли в таком случае утверждать, что оценка демо-сайта шаблона не играет никакой роли при выборе шаблона? Лишь отчасти, ведь хотя эта оценка и показывает в первую очередь уровень подготовленности демо-сайта, вместе с тем она позволяет проверить и те факторы, которые все же зависят от шаблонов, например вышеупомянутый FID (Первая задержка ввода), повысить который, согласно документации, предлагается следующим образом: Уменьшить влияние стороннего кода – чем больше всякого «мусора» в виде скриптов и плагинов тянет шаблон с собой, тем хуже Сократить время выполнения JavaScript – на первый взгляд красивая и плавная JS-анимация с выдвигающимися товарами запросто может стоить нескольких секунд проигрыша Минимизировать работу основного потока – чем больше стилей, скриптов и захламленности, тем больше уйдет времени на анализ, компиляцию и выполнение всего этого добра Минимизировать количество запросов и размеры передаваемых данных Также немаловажно будет обращать внимание на следующие факторы: Размер структуры DOM – если рассматривать два гипотетических шаблона, у которых выводится одинаковое кол-во товаров в категории, то чем меньшей будет структура DOM, тем легче будет верстка шаблона Размер кода CSS – чем меньше вес и легче правила, тем лучше Размер кода JS – чем меньше вес и сложность в выполнении, тем лучше и быстрее все будет отрабатывать Разумеется, это не все факторы, на которые стоит обращать внимание, но цель рассмотрения данного мифа не в том, чтобы научить выбирать шаблоны, а в том, чтобы показать сомнительную целесообразность оценивания и сравнения шаблонов по оценке PageSpeed. Важность метрики CLS (Совокупное смещение макета) в плане юзабилити можно хорошо продемонстрировать следующим примером: При этом оценивающие инструменты вроде того же PageSpeed и Lighthouse подходят к вопросу измерения этой метрики очень формально, являясь автоматизированными инструментами, не понимающими контекста измерений и не знающими, по каким сценариям используется ваш интерфейс. Например, нередко эта метрика показывает плохие результаты из-за того, что определенные блоки инициализируются с помощью скриптов Javascript и могут быть не видны до момента инициализации. Самый распространенный пример – слайдшоу или карусели, на практике «внезапное» появление таких блоков выглядит следующим образом (обратите внимание на блок карусели дополнительных фото товара справа вверху): Можно ли от этого избавиться ради получения более низкого показателя CLS? Конечно, есть разные способы (от довольно простого и «глупого» принудительного указания рассчитанной высоты этого блока, чтобы на его месте до инициализации карусели выводилась пустота, до более серьезных и продуманных способов с выводом статичных миниатюр дополнительных фото, визуально идентичных таковым в инициализированной карусели), однако практической ценности у этого будет очень мало, кроме выигрыша «попугаев» этой метрики, да и то не факт. Улучшится ли UX (user experience, опыт взаимодействия пользователя) на сайте после этих действий? Нисколько, т.к. все эти скрипты, вызывающие смещения в макете, грузятся сразу со страницей, поэтому пользователь до их загрузки все равно ничего с сайтом не сделает и не сможет сделать, даже если поставить заглушки вместо неинициализированных блоков каруселей – заглушки будут нефункциональными до момента инициализации самих каруселей, а значит ими все равно невозможно будет пользоваться. Возможна ли ситуация, когда пользователь захочет нажать на какую-то из кнопок или ссылок под неинициализированным блоком карусели и промахнется из-за смещения блоков, последовавшего после инициализации карусели? В теории да, но на практике такая ситуация крайне маловероятна, поскольку чтобы нажать на кнопку покупки товара или на какую-то из информационных ссылок, их нужно как минимум успеть увидеть и прочесть. Конкретно в вышеприведенном примере даже при использовании медленного мобильного 3G-интернета основное фото товара загружается намного дольше, чем инициализируется карусель и подгружаются ее дополнительные фото (потому что при весе основного оптимизированного фото в 15.5 кБ дополнительные даже суммарно весят в 4 раза меньше), а кто будет нажимать кнопки покупки товара, не увидев его фото, не говоря про чтение описания и т.п.? Как видите, на практике результат оценки шаблона по такой метрике может быть низким даже тогда, когда никакого влияния на юзабилити эти измерения не оказывают, поскольку машинные алгоритмы физически не могут знать всех вышеуказанных нюансов и оценивают такие вещи исключительно с «машинной» точки зрения. Стоит ли из-за этого закрывать глаза на все случаи смещения макета? Конечно нет, по возможности это лучше исправлять, особенно если такие проблемы вызывают больше неудобств, чем в вышеуказанном случае (например, когда весь контент страницы дергается и съезжает вниз из-за загрузки большого фото). Миф №3: PageSpeed это зло До версии 5.0 инструмент PageSpeed сложно было назвать архиважным или очень информативным, но после того, как PageSpeed начал использовать Lighthouse, его оценка стала намного информативнее и объективнее, достаточно лишь относиться к ней со здоровой критичностью и видеть в ней не цель развития сайта, а ориентир – тот самый «Lighthouse» (в пер. с англ. - маяк), направление которого стоит учитывать, но не стоит принимать как единственно возможное. Если вы считаете, что все рекомендации PageSpeed выеденного яйца не стоят и никак не повлияют на поисковое ранжирование магазина, каждая страница которого грузится по 30 секунд, то в целом вы правы – ваши посетители убегут прочь с вашего сайта и забудут о нем как о страшном сне безо всякого участия и PageSpeed, и Google Однако если вы думаете, что достижение заветных цифр 99/100 проложит вам дорогу в Топ-3 поисковой выдачи по всем ВЧ-запросам, то вам стоит сразу написать это в письме Деду Морозу, ведь вы, скорее всего, все еще в него верите. Выводы для тех, кто читает только заголовки 1. Я не призываю и никогда не призывал "забить" на оценку PageSpeed 2. Оценка PageSpeed (абстрактные баллы 0..100) и метрики, на которых основана оценка PageSpeed (конкретные данные FCP, SI, LCP, TTI, TBT и CLS) – не одно и то же! 3. Оценка PageSpeed не является точным индикатором сама по себе, потому что не несет никакой конкретной информации, в отличии от метрик, на которых основана оценка PageSpeed (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS) Почему так? Распишу подробнее на примере из комментариев: 4. С умом улучшая метрики, на которых основана оценка PageSpeed, вы, естетственно, улучшаете и саму оценку PageSpeed Ключевое слово - "с умом", т.е. понимая за что именно отвечает каждая из метрик и каким образом ее правильно улучшать. Слепое выполнение всех рекомендаций без понимания их сути (например, назначение абсолютно всем изображениям атрибута loading="lazy") принесет больше вреда, чем пользы, хоть и может реально улучшить итоговую оценку! 5. Даже вывод всех метрик, на которых основана оценка PageSpeed, в зеленую зону - не сыграет большой роли в ранжировании вашего сайта и не может гарантировать высокие позиции в поиске При этом фактором ранжирования (одним из множества) является вовсе не оценка PageSpeed (абстрактные баллы 0..100), а данные метрик (вышеупомянутые FCP, SI, LCP, TTI, TBT и CLS), на которых эта оценка основана и которые собираются с помощью разных механизмов отслеживания пользовательского взаимодействия. Еще раз - поисковые системы не гоняют и физически не могут прогонять все сайты в поисковой выдаче через PageSpeed для их оценивания! 6. Оценка PageSpeed косвенно показывает то, насколько грамотно сделан шаблон, но она не может объективно показывать его «скорость», потому что зависит от массы факторов, никак не связанных с шаблонами (скорость ответа сервера, наличие кеширования и тому подобное). 7. Улучшать удобство и скорость работы можно и нужно независимо от оценки PageSpeed. UPD (20.12.2021): Запись актуализирована, убраны устаревшие скриншоты, а также добавлены выводы для тех, у кого сложности с чтением и пониманием. UPD (25.12.2021): Выводы дополнены информацией из комментариев.

99 Скачать / Купить дополнение Hi-Optimizer for Opencart - интеллектуальный оптимизатор сайта для повышения скорости загрузки страниц и оценки pagespeed google Максимальное ускорение вашего сайта. Бесплатное апробирование до 7 дней при получении тестового ключа по договоренности с автором. Подчеркну, что по договоренности, а не на безусловной основе, т.е. при наличии возможности, целесообразности и на условиях автора. При этом (для теста) автор также бесплатно может установить и настроить модуль Hi-Optimizer. Для тех, кто не вполне понимает, что такое договоренность: Сейчас из-за нехватки времени нет возможности предоставлять бесплатную настройку, эта бесплатная опция была раньше. Совместим с opencart 1.5, 2.*.*, 3.0.* Совместим с opencart (ocstore) 1.5 также. Модуль оптимизации hi-optimizer не влияет непосредственно на оценку гугла в https://developers.google.com/speed/pagespeed/insights/ Но влияет на нее косвенно. Конечная оценка гугла не является мерилом функционирования модуля. Модуль оптимизации hi-optimizer позволяет использовать определенные методы оптимизации с целью выполнения рекомендаций гугла по оптимизации. Т.е., например "объединение, минификация CSS" - это вполне конкретный функционал модуля hi-optimizer. Но совершенно другой вопрос - насколько в баллах это позволит поднять оценку гугла, тут невозможно дать однозначный ответ для любых сайтов. Выполнение различных приемов оптимизации влияет на скорость загрузки страниц сайта и косвенно влияет на оценку скорости гуглом. Но степень повышения данной оценки и/или индивидуальные ожидания заказчика, выраженные в цифрах желаемой оценки - не являются критерием работоспособности модуля hi-optimizer. Полезность модуля hi-optimizer заказчик в каждой конкретной ситуации оценивает самостоятельно исходя из собственных представлениях о полезности, но это не является критерием работоспособности модуля. Чтобы не было недоразумений рекомендуется всегда делать предварительный анализ сайта и воспользоваться тестовым периодом для оценки пользы от оптимизации. Позволяет оптимизировать с целью максимального увеличения скорости загрузки страниц (не обязательно, что все приемы будут полезны на любом конкретном сайте и будут работать все вместе и в любой комбинации): стили (CSS) скрипты (JavaScript) - группирование в конце HTML и пр. объединение, минификация CSS и т.п. откладывание выполнения JavaScript с малым приоритетом возможность асинхронной загрузки как определенных CSS, так и JavaScript оптимизация всевозможных метрик (Яндекс и др.), аналитик (Гугл, Фейсбук и др.)[с определенной осторожностью и по желанию, не является обязательным] оптимизация всевозможных виджетов (Яндекс, Фейсбук, В Контакте и др. ) виджеты могут загружаться при попадении их в зону просмотра (lazy load для виджетов) оптимизация всевозможных чатов (Jivosite, Яндекс и т.д) оптимизация карт Гугла и Яндекса (загружаются при попадении в зону видимости - lazy load для карт), и др. карт оптимизация загрузки фреймов (iframe) оптимизация видео-вставок Ютюб, youtube.com оптимизация загрузки и отображения шрифтов, причем, как из внешних источников, так и из CSS, загружаемых с вашего сайта отслеживание дублей CSS, JS и, соответственно, предотвращение их повторной загрузки оптимизация загрузки всевозможных Lightbox (magnific-popup, colorbox, fancybox) Основную работу по оптимизации модуль Hi-Optimizer способен выполнить самостоятельно в автоматическом режиме. Также можно в ручном режиме помечать любые скрипты, которым имеет смысл назначить низкий приоритет загрузки и выполнения. Такие скрипты будут выполняться только после загрузки страницы и ее важных компонентов. Модуль Hi-Optimizer не является панацеей для всех случаев. Бывают крайне неудачно сделанные сайты (соответственно с оценкой гугла близкой к нулю), которые без серьезной переделки невозможно оптимизировать, а это только ручная работа с версткой, кодом и т.д. Предлагаю сперва (до заказа услуги или покупки модуля) консультироваться с исполнителем и делать предварительный анализ и прогноз на предмет возможной успешной оптимизации конкретного сайта. На результат могут отрицательно влиять ошибки в коде HTML, CSS, JS, имеются ввиду грубые ошибки (непарность парных тегов, незакрытые кавычки, скобки, любые синтаксические ошибки и т.п.). Изначально предполагается, что HTML на странице не содержит грубых ошибок, в противном случае возможна некорректная работа hi-optimizer на таких страницах, тестирование hi-optimizer не проводилось на страницах, содержащих грубые ошибки HTML (синтаксические и иные), соответственно автор не несет никакой ответственности за корректную работу таких страниц. Проверяйте страницы (файлы стилей в том числе) на наличие грубых ошибок через валидатор: https://validator.w3.org/ Могут быть такие ошибки: Важное замечание для потенциальных заказчиков: Hi-Optimizer предназначен для выполнения конкретных рекомендаций гугла, т.е. когда гугл указывает достаточно точно проблемное место. Hi-Optimizer НЕ ПОМОЖЕТ в случае если есть только общие и/или абстрактные рекомендации гугла вида: минимизируйте работу в основном потоке, постарайтесь уменьшить количество запросов и размеры передаваемых данных. и т.п. Подобные рекомендации относятся ко всему сайту в целом и гугл просто показывает общий размер данных, общее кол-во запросов и т.д. и т.п. Совсем другое дело, когда гугл дает конкретные рекомендации с указанием проблемного места (конкретного скрипта JS, конкретного файла стилей CSS). Примеры ниже. Здесь гугл говорит про вполне конкретный код, который блокирует основной поток, и гугл указывает на вполне конкретные файлы JS, CSS, которые вызывают блокировку. В данном случае есть с чем работать, т.е. с конкретными файлами. Можно выполнить отложенную загрузку таких скриптов чтобы исключить блокировку основного потока. Т.е. мы можем выполнить вполне конкретные действия с вполне конкретными скриптами с помощью Hi-Optimizer. Любой ли сторонний код можно оптимизировать? Не любой и не всегда. Во-первых, предполагается, что сторонний код - это код, от которого не зависит работа самого опенкарт, в таком случае такой сторонний код может быть оптимизирован за счет, например, отложенной загрузки. Но если вы загружаете "сторонний код" (с другого сайта/домена) вроде jquery-3.4.1.min.js, то от этого кода зависит работа самого опенкарт и такой код обычно загружается не со "стороны", а с того же домена, на котором у вас работает сайт. В приведенном примере "сторонний код" jquery-3.4.1.min.js невозможно рассматривать как независимый, а потому невозможно использовать к нему прием оптимизации "отложенная загрузка". Вот код Jivochat - это пример независимого кода (от него работа самого опенкарт никак не зависит, т.е. опенкарт будет работать и без него). Независимый код (Jivochat как пример) может быть успешно оптимизирован. Любой код JavaScript, который необходим для работы опенекарт можно загружать со сторонних ресурсов, но это не означает, что такой "сторонний код" можно обязательно оптимизировать средствами модуля, т.к. "сторонним" он стал формально, но не стал при этом независимым (необязательным) кодом. Т.е. важное условие - это независимость работы опенкарт от стороннего JavaScript, тогда есть возможность его оптимизации. Например, опенкарт будет работать как с загруженным кодом Jivochat , так и без него - это и есть независимость кода. На скриншоте ниже пример независимого стороннего кода, который поддается оптимизации. Под спойлером пример кода, который необходим для работы опенкарт. Нет возможности его отложить, т.е. оптимизировать. Еще пример. Гугл предлагает оптимизировать отображение текста и сделать оптимизацию шрифтов. При этом гугл указывает вполне конкретные шрифты, которые могут быть оптимизированы. Это вполне конкретная рекомендация с вполне конкретным руководством к действию, а не общие слова. Если вы не вполне понимаете есть ли для вашего сайта конкретные рекомендации гугла, которые можно выполнить с помощью Hi-Optimizer, то, пожалуйста, напишите разработчику прежде чем покупать Hi-Optimizer. Если же вы видите только рекомендации гугла в стиле "улучшайте ваш сайт", то от таких советов нет никакой практической пользы. Ниже еще пример бесполезной рекомендации гугла насчет уменьшения кол-ва узлов DOM. Во-первых, невозможно уменьшить кол-во узлов DOM без серьезной переделки сайта, включая его верстку, изменение кол-ва модулей на странице и т.д. и т.п. Все это не входит в возможности Hi-Optimizer, т.к. задача кардинальной переделки, включая визуальные изменения, сайта не стоит. Во-вторых, на приведенном скриншоте узлов всего 1530, при том, что гугл рекомендует использовать на странице до 1500 узлов, т.е. это практически норма. Т.е. иногда гугл дает бесполезные советы в стиле что-то изменить и получить выигрыш в 1%. Еще раз повторяю. Если вы не видите кроме общих рекомендаций гугла ничего, то чуда в улучшении оценки гугла не случится. В данном случае гугл сам не знает за счет чего же можно ускорить ваш сайт. Чуда не случится. Не стоит в таком случае говорить, что модуль якобы не работает. Просто модуль умеет делать вполне конкретные и определенные действия, при этом вы сами определяете, что именно будет делать модуль Hi-Optimizer. Например, модуль умеет с вашим указанием откладывать второстепенные скрипты чтобы они не мешали работе основного потока. Но если нет ни одного второстепенного скрипта, т.е. вы не смогли указать такой скрипт, то и нет объекта, к которому можно было бы применить оптимизацию за счет отложенного выполнения. Ниже на скриншоте пример общих рекомендаций гугла, которые будут бесполезны для оптимизации сайта за счет Hi-Optimizer. Тут больше рекомендаций для настройки сервера (включить сжатие текста, настроить кеширование для браузера), и эти рекомендации вполне конкретны, т.е. их можно выполнить, но к Hi-Optimizer они не относятся. Выполненные хотя бы частично (полностью все выполнить невозможно в принципе) рекомендации гугла могут считаются критерием для успешной работы Hi-Optimizer. Конечный результат сильно зависит от индивидуальных особенностей сайта, в первую очередь - от примененного шаблона. Хотя бы одна успешно выполненная рекомендация говорит о том, что hi-optimizer выполняет свою задачу. В качестве примера показана рекомендация гугла "настройте показ всего текста во время загрузки веб-шрифтов", которая выполнена за счет hi-optimizer-а, насколько баллов это повлияет в конечном итоге сложно дать однозначный ответ, но наличие объективного факта оптимизации шрифтов можно проконтролировать, именно этот факт говорит о том, что модуль hi-optimizer выполняет свои функции. В случае сомнений полезности оптимизации на вашем сайте лучше всего воспользоваться триальным (тестовым) вариантом использования hi-optimizer-а до его покупки. Возможно, что еще на этапе анализа сайта будет понятно насколько перспективной (или нет ) может быть оптимизация. В случае негативного прогноза нет смысла в тестовом периоде. Наличие множества опций настройки в hi-optimizer не означает, что на любом сайте их можно и/или нужно использовать все и в любой комбинации. Для разных сайтов оптимальные и работоспособные комбинации могут сильно различаться. Автор данного программного решения не может брать на себя обязательств, что на вашем конкретном сайте в любом случае можно непременно достичь оценки гугла в 90+ баллов только лишь за счет применения программного решения "Hi-Optimizer". Оптимизатор Hi-Optimizer в первую очередь позволяет выполнять многие рекомендации гугла в плане оптимизации, например, позволяет снимать блокировку основного потока (сторонними скриптами) полностью (или, как миниум, существенно уменьшать ее). Под спойлером подробнее о том какими средствами объективного контроля (от гугла) можно оценить как Hi-Optimizer выполняет оптимизацию по конкретным рекомендациям гугла. Какие шаблоны из известных являются сложными для оптимизации? Есть несколько автоматических режимов оптимизации JavaScript , начиная с режима банального группирования скриптов в конце HTML, а также есть несколько режимов продвинутой оптимизации JavaScript. Модуль Hi-Optimizer использует продвинутые современные технологии распараллеливания загрузки скриптов и одновременного выполнения построения страницы, используются где необходимо асинхронная загрузка скриптов, отложенная загрузкаи и комбинация этих способов с синхронной загрузкой и выполнением. В модуле есть встроенный анализатор исходного кода страниц, который позволяет в ручном режиме визуально находить участки кода, которые требуют оптимизации. Такой анализатор непрерывно развивается и служит большим подспорьем для нахождения проблемных мест в коде HTML. За счет использовния модуля Hi-Optimizer будут выполнены максимально насколько возможно рекомендации Гугла (https://developers.google.com/speed/pagespeed/insights/). Это способствует существенному поднятию оценки Гугла и реальному ускорению. В настоящее время модуль Hi-Optimizer работает на самых разных сайтах ( примерное количество: 50+) на движке Opencart (OcStore) версий 1.5, 2.*, 3.0 Модуль Hi-Optimizer не занимается кешированием (ускорением) медленно работающих скриптов php на вашем сервере (хостинге), не ускоряет работу вашей базы данных и т.п. Это сугубо серверные задачи, для которых модуль не предназначен. Перед модулем нет задачи улучшить отклик сервера, данный параметр гугл называет Reduce server response times (TTFB) . Пример (это страница БЕЗ оптимизации): https://hi-optimizer.sitecreator.pro/home00.html Тут полный порядок с откликом сервера, в этом плане страница очень быстрая. Вообще в плане серверной оптимизации все идеально, и на сервере улучшать нечего. Но кроме работы программ на сервере есть работа программ на устройстве пользователя, т.е. на его смартфоне (в его браузере), на его компьютере, планшете и т.п. И вот работа этих программ оказывается в данном примере Не оптимизирована. Но гугл считает, что скорость этой страницы очень низкая и оценивает ее лишь в 24 балла. Это как раз говорит о том насколько важна не только (и часто не столько ) скорость отклика сервера, а скорость работы страницы сайта в браузере пользователя. В приведенной выше ссылке скорость отклика сервера очень хорошая, но общая скорость по замерам гугла оказывается очень низкой до оптимизации. Модуль Hi-Optimizer как раз и призван решить проблемы на стороне клиента, т.е. оптимизировать выполнение программ на устройстве конечного пользователя. Оптимизирует практически все, что загружается, работает и "крутится" в браузере пользователя. Особый упор сделан на оптимизацию работы программ (скриптов JS) на смартфонах. Всевозможные минификации в данном случае играют лишь слабую второстепенную роль в оптимизации. Так, например, оптимизация загрузки и отображения различных шрифтов вносит гораздо более весомый вклад чем пресловутая минификация HTML или CSS. С учетом того, что на любом хостинге используется сжатие gzip для HTML, CSS, JS, то минификация играет крайне слабую роль в оптимизации, а гугл очень слабо оценивает минификацию (если вообще оценивает). Т.е. сейчас для оценки скорости загрузки страницы важны совсем другие факторы нежели минификация HTML. Поэтому в данном модуле вы не увидите минификацию HTML (по сути это бесполезная функция). Гораздо важнее скорость анализа CSS, выполнения JS и собственно рендеринг страницы. Если большой вес изображений, то будет также полезна оптимизация изображений (как их веса, таки и загрузки - lazy load). Демо-сайт: https://hi-optimizer.sitecreator.pro админка (переходить строго по ссылке, доступ к другим настройкам в админке запрещен): https://hi-optimizer.sitecreator.pro/admin/index.php?route=extension/module/hi_optimizer hioptimizer hioptimizer Оценка сайта гуглом https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fhi-optimizer.sitecreator.pro%2F Эта же страница ДО оптимизации (ее оценка ДО оптимизации 27 баллов для мобильных): код на 100% совпадает с кодом главной страницы https://hi-optimizer.sitecreator.pro/ ДО оптимизации. https://hi-optimizer.sitecreator.pro/home00.html ссылка для проверки в гугле: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fhi-optimizer.sitecreator.pro%2Fhome00.html&tab=mobile Часть список из нескольких десятков сайтов, на которых работает Hi-Optimizer: Можно по комментарию в исходном коде HTML увидеть, что работает Hi-Optimizer, а также получить дополнительную информацию (такую как потраченное время на оптимизацию страницы). Добавил sitecreator Добавлено 10.04.2020 Категория Кэширование, сжатие, ускорение Системные требования php 5.6 - 7.4, Ioncube Loader версии не ниже 10+ Метод активации По запросу в ЛС По запросу на почту Ioncube Loader Требуется ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 1.5.5.1.2 1.5.5.1.1 1.5.5.1 1.5.4.1.2 1.5.4.1.1 1.5.4.1 1.5.3.1 1.5.2.1 1.5.1.3 OpenCart.Pro, ocShop Opencart.pro 2.3 Opencart.pro 2.1 Обращение к серверу разработчика Нет

Скачать / Купить дополнение OptiPic оптимизация изображений и конвертация в WebP Умная оптимизация изображений и конвертация в WebP на лету через OptiPic CDN. Что делает OptiPic CDN при попытке запросить у него изображение: Возвращает версию изображения WebP, если браузер поддерживает формат WebP. Возвращает сжатую / оптимизированную версию без webp, если браузер не поддерживает WebP. Делает изображение оптимизированным под мобильный экран, если изображение открывается с мобильного. Кеширует и ускоряет загрузку, снижая нагрузку с вашего хостинга. Преобразование в Webp и сжатие изображений происходит в фоновом режиме и не замедляет открытие изображений в браузере. Если оптимизированная версия еще не готова на момент запроса изображения, исходная версия возвращается без какой-либо обработки. Зачем нужна оптимизация изображений на сайте: Ускорение сайта. Улучшение SEO. Повышение конверсии. Повышение показателей Google Pagespeed Insights. Почему оптимизация изображений ускоряет работу вашего сайта? Бесплатная поддержка и помощь по установке Есть вопросы? Здесь вы можете получить бесплатную поддержку и бесплатную помощь в настройке модуля. Для получения дополнительной информации посетите официальный сайт OptiPic CDN. Видео-инструкция по настройке модуля в админке OpenCart: https://youtu.be/q4E2PGdF5Jw Добавил optipic Добавлено 19.03.2021 Категория Кэширование, сжатие, ускорение Системные требования Метод активации Без активации Ioncube Loader Нет ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 OpenCart.Pro, ocShop Обращение к серверу разработчика Нет  

Сервер: VPS Beget nginx. Версия CMS: Opencart 3.0.3.2. Уже установлен: модуль Opencart Lightning. Нужно ускорить имеющийся магазин до зеленой зоны Google Pagespeed Insights в следующих типах/шаблонах страниц: СТРАНИЦА --- текущие показатели мобила/десктоп 1. Главная - https://xn--80aeshfq1a7bxd.xn--p1ai/ --- 24 / 682. Услуга - https://xn--80aeshfq1a7bxd.xn--p1ai/programmirovanie-klyuchej-avto --- 38 / 703. Блог список - https://xn--80aeshfq1a7bxd.xn--p1ai/blog --- 34 / 844. Блог статья - https://xn--80aeshfq1a7bxd.xn--p1ai/kak-propisat-klyuch-v-avto --- 47 / 695. Каталог - https://xn--80aeshfq1a7bxd.xn--p1ai/avtomobilnye-klyuchi 28 / 626. Результаты фильтрации - https://xn--80aeshfq1a7bxd.xn--p1ai/klyuchi-audi-a4 --- 28 / 637. Карточка товара - https://xn--80aeshfq1a7bxd.xn--p1ai/vykidnoj-klyuch-audi-a4-rs4-2004-2009-8e0-837-220-q-s-chipom --- 15 / 65 Условия: на поддомене будет развернута техническая копия сайта. Все манипуляции будут произведены на ней и доказана работоспособность способа - есть результат, ничего не сломано. Как только способ будет утвержден с руководством, те же манипуляции будут произведены на основном домене. Оплата - 100% постоплата, по результатам pagespeed insights. Сроки, цена и прочие условия в личку.

Как вы знаете, я давно и успешно борюсь с медленными магазинами. Мы научились делать магазины с миллионом товаров, научились выгружать в яндекс-маркет несколько миллионов товарных предложений, научились держать 1.5-2к онлайна посетителей без единого разрыва. Сделали поиск, который умеет искать iphone-7 iphone7 и айфон7 и понимает разницу между iphone7 и iphone-8. И в процессе всех этих наработок как-то вот очень мимо меня проходил вопрос улучшения оценки под новый алгоритм pageSpeed. Последние пару недель появилась возможность провести определенные эксперименты с факторами, которые влияют на оценку, и наработать кое-какую методологию решения этой ситауции без потери работоспособности и масштабируемости магазина. К сожалению вот так взять и взять в целом описать что необходимо делать - фактически невозможно, так как выйдет целый букварь. Но кое-какие секреты я приоткрою. И давайте начнем с врагов. Часто-густо как оказалось, можно практически из воздуха получить 12-15 баллов, просто устранив чью-то глупость. Я не знаю кто это сделал. Но на многих-многих магазинах стоят модули СДЭК и Яндекс-Доставки. Разработчики этих модулей ходили на курсу программирования к Джигурде. Поэтому ничего зазорного не увидели в том, чтобы взять и на все страницы подключить api яндекс карт. Круто и клево. Вместо того чтобы рендерить страницы магазина, бразуер ваших клиентов стучит в яндекс и ждет-ждет яндекс карты. Зачем - я не знаю. У меня нет на это ответа. Но я знаю что делать. Если у вас есть какое-то такое подобное творение. Они разные все. Находите в коде кусок, отвечающий за подключение скрипта и делаете что то подобное: if (isset($this->request->get['route'])) { $route = $this->request->get['route']; if(strpos($route, 'checkout') !== false || strpos($route, 'simple') !== false || strpos($route, 'shipping') !== false) { ///...здесь пример из реального дополнения. У вас может быть другой код $this->document->addStyle('catalog/view/theme/default/stylesheet/sdek.css'); $this->document->addScript('//api-maps.yandex.ru/2.1/?lang=ru_RU&ns=cdekymap'); $this->document->addScript('catalog/view/javascript/sdek.js'); }; } В итоге, мы публикуем виджет карт, только там где он нужен. И не грузим ни сервер яндекса, ни своих посетителей. И в попугаях профит и покупателям быстрее. Такие же плюшки есть у @29aleksey в его модуле редактирования товаров, да и много-много где. Вобщем мораль басни такая. Сторонние скрипты да и скрипты в целом используем только там, где нам нужно. А теперь немного общей информации. Если раньше на оценку pageSpeed очень влияло время ответа сервера, то теперь за уменьшение ttfb от 2 до 1 сек для мобильных устройств, валидатор накидывает всего 6-8 баллов. И еще столько же при уменьшении от 1 до 200мс, как того требует стандарт. Также все эти новые форматы изображений, webp и вся прочая лабуда, на которой пытается хайпануть и нажится на несведущих пользователях @sitecreator в целом абсолютно бесполезна на сегодня и не является дефакто необходимым действием, при условии что вы в состоянии использовать jpegoptim и отказаться от png. С нормально сжатыми и очищенными Jpeg гугл вас любит. Также от этого никуда не денешься. Все скрипты и стили надо обьединять. К сожалению автоматически это сделать без потери для масштабируемости достаточно сложно. Но при желании возможно. Если не получилось объеденить стили просто пытаемся перенсти большую их часть в футер. Туда же идут font-awesome и гугл-шрифты. А еще оказывается просто волшебное действие на 15-20 попугаев оказывает удаление, выжигание напалмом модуля от одного очень много безответственно разговаривающего автора. Я думаю кому надо тот догадается. https://upyachka.io/img/f_boyangreposm_2c6c344.jpg Так вот там в модуле у автора есть подключение пары-тройки скриптов (капча, визивиг и прости господи bbcode 2019 год на дворе а у нас bbcode, следующим этапом морзянку можно еще вставить) на все страницы магазина по аналогии с Сдэком. А так как все его модули это архитектурная ошибка, которая не лечится, то проще все это снести и поставить нормальный модуль для статей. Что же касается внутренних страниц (категории, товары). То если вы используете любой фильтр, неизбежно вы получаете пессимизацию оценки, в силу того что набор элементов фильтра - это много-много объектов DOM, а делать рендеринг набора параметров фильтра по какому-либо событию, фильтрописатели еще не научились. Что касается карточек товаров. Там есть два вселенских зла. Одно всегда, второе приходящее. Первое - это всякие социальные share-кнопки, которые давно никому не нужны, но их все равно тулят во все шаблоны. Второе - это видосы с йотубера. Кнопки выжигаем. А йотобуер борем как то так: https://ruseller.com/lessons.php?rub=32&id=2125 это первое что нагуглилось в понятном формате. В целом 65-70 попугаев на мобиле - это не сложно, при условии того, что у вас в целом быстрый магазин, достаточно выкинуть весь лишний мусор и немного привести в порядок процесс генерации контента и подключения скриптов. Если же говорить о глубоком тюнинге и раскачке магазина совсем в зеленую зону оценки. То и это фактически возможно. Но. Во первых потребуется ограничение количества элементов в модулях на мобайл страницах и существенная переработка всех этих модулей. Во вторых в идеале необходимо разделить общий стиль css на части и подгружать каждый согласно пришедшего vieport. В третьих сделать все элементы максимально интерактивными, убрать лишний мусор и подгружать контент ровно там где он нужен. (тоесть если вам нужен фильтр, колбаса параметров должна грузиться по нажатию элемента, который его раскрывает. равно как и дерево меню и все остальные большие элементы). В четвертых необходима проработка модулей и разделение вывода изображений, или использование динмаических тегов верстки, для вывода разного размера изображений под разные форматы экрана. В пятых, все сторонние скрипты, типа тех же яндекс карт, виджетов вконтакта и прочих прочих, необходимо грузить по какому-либо пользовательскому событию, типа скролл, клик, свайп, а не сразу на страницу. На этом пока хватит. В целом друзья, не бывает плохих и медленных магазинов, бывают кривые руки выпускников курсов программирования имени Джигурды.

Пытаюсь оптимизировать сайт, чтобы понравится гуглу - Выполняю вроде его советы, но результат такой же, как и был. вот ссылочка Если конкретнее я пытался оптимизировать картинки из основного раздела раздела "необходимо к исправлению" и CSS файлы с Ява скриптами пробовал путем скачивания уже оптимизированных гуглом результатов отсюда http://prntscr.com/8m0imk А картинки пробовал 2мя способами. После того как не проканало вставить то, что мне гугл предложил скачать, я пробовал через запуск jpegtran и optiPNG Но все то же самое. Так же после того как я исправил некоторые баги с отображением в мобильной версии, при просмотре метрики в Яндексе я вижу как будто страниа по прежнему с той же ошибкой (в главном меню один элемент на другой наезжает) Кто подскажет в чем может быть проблема? Может кэшируется все это как то? Куда тогда? Как поправить?