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

20 Завантажити / Придбати розширення Автор Seriusis долучення 12.11.20 Категорія Модули Ioncube Loader Нет ocStore 3.0 2.3.0.2.4 2.3 2.2 2.1 OpenCart.Pro, ocShop Opencart.pro 2.3 Opencart.pro 2.1 OcShop 2.0.3.х Звернення до сервера розробника Нет  

29 Завантажити / Придбати розширення Автор markimax долучення 15.03.17 Категорія Кэширование, сжатие, ускорение 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 OcShop 2.0.3.х OcShop 1.5.6.4.х Звернення до сервера розробника Нет  

59 Скачать / Купить дополнение Image COMPRESSOR & Watermark & WebP & Lazy Load etc. by Sitecreator webp + lazy load + watermark + др. оптимизация изображений email разработчика: [email protected] WEBP (создание и вывод) работает везде просто и надежно ! Поддерживаются практически любые операционные системы: Linux Windows 32bit 64bit webp: модуль Компрессор позволяет создавать и выводить webp в браузеры, т.е. позволяет оптимизировать изображения формата jpeg и png. Оптимизируются изображения, которые отдаются (передаются по сети при загрузке страниц сайта) в браузер пользователя. Модуль позволяет отдавать старым браузерам без поддержки webp привычный формат jpeg/png. Модуль Компрессор позволяет использовать webp в качестве исходных изображений, которые могут быть, например, загружены вручную или получены путем импорта (парсинга и т.п.). Webp в папке исходных изображений преобразуются в jpeg, с возможностью дальнейшей обработки (ресайз и т.п.), т.е. webp может быть использован в качестве исходных изображений практически также как jpeg и png, данная возможность является расширенной (платной опцией) и по умолчанию не включена в модуле. К функции оптимизации изображений, создания и вывода сжатого формата webp указанная возможность не имеет отношения, и, по-сути, нужна очень ограниченному количеству заказчиков для специфических условий парсинга. Условия работы модуля Компрессор с webp в качестве исходных изображений (входного формата для последующей обработки): Важное замечание по работе в windows server: Компрессор для opencart всех версий: 1.5, 2.* & 3.0 Для использования на opencart 1.5.* должен быть сперва установлен vqmod (если он отсутствует), обычно в 95% он уже присутствует в движке. Ссылка на подробную документацию по установке: Гугл отмечает положительно в своем аудите выполнение рекомендаций по оптимизации изображений. Модуль Компрессор позволяет уменьшить кумулятивный сдвиг макета за счет задания размеров изображений в HTML до их загрузки и, тем самым, несколько увеличить общую оценку скорости. В определенных случаях это бывает полезно. Обычно гугл рекомендует для уменьшения сдвига макета выполнить рекомендацию: Никакой зависимости от хостера в плане создания и вывода WEBP! Работает WEBP везде почти без всяких условий! Важно чтобы была ОС Linux 64 bit / FreeBSD 11 (12, 13) 64bit или Windows (это будет в 99.9% случаев) В данном решении предусмотрено практически все, включая совместимость с ускорителями Jet Cache (изначально полная совместимость), Turbo (версии для опенкарт 2.1 и 2.3 - полная совместимость), Nitropack (см. примечание по версиям ниже). Остальные кешеры тоже поддерживаются полностью или частично, но с определенными условиями. WEBP (сжатый формат графики) можно теперь получить практически у любого хостера. Не имеет значения есть ли поддержка WEBP у вашего хостера или нет. Такая поддержка WEBP встроена в модуль Компрессор и работает на любой Linux 64 бит / FreeBSD 11 (12, 13) 64bit и Windows. На любом обычном (общем) хостинге всегда работает одна из разновидностей Linux 64 бит, очень редко используется FreeBS. . Linux 32 бит требует наличия 32-х битного софта mozjpeg, optipng, cwebp, такой софт не входит в состав модуля ввиду полной нецелесообразности, т.к. 32-х битные ОС не использует ни один хостер в качестве обычного хостинга и не предлагается хостерами для установки на VDS. Поддерживается любой современный браузер, способный отображать WEBP. Старые браузеры без поддержки webp также не забыты, они получат соответственно jpeg, png. Благодаря современному формату изображений WEBP удается снизить общий вес изображений в среднем в 2-3 раза на страницах сайта, и тем самым выполнить рекомендации Гугла по изображениям для вашего сайта. Модуль уникальный в своем роде, т.к. обеспечивает совместимый вывод WEBP для новых браузеров, а старым отдает соответственно jpeg, png , это справедливо почти всегда и в случае использования облачных технологий вроде cloudflare. Но с одним условием, что сам CloudFlare (или оное облако-кешеровщик) настроен на корректную работу с webp и браузерами с поддержкой webp и без нее. Если облако вроде CloudFlare неверно настроено, то webp может появиться на страницах с заметным опозданием или работать не вполне корректно, можете в таком случае отключить временно или совсем CloudFlare. В случае решений (которые есть в сети), например, "созданных на коленке" вы рискуете оставить пользователей Сафари (старых версий до июля 2020) вообще без изображений при использовании того же cloudflare. Модуль Компрессор содержит набор различных возможностей, отчасти определенные возможности дублируют друг друга, например, есть поддержка нескольких вариантов сжатых изображений (mozjpeg, optipng, webp). Это не означает, что у любого хостера будет возможность использовать все возможности, но будет выбор доступного варианта. Т.е. модуль Компрессор предоставляет возможности с избытком, но нет гарантии, что они могут быть задействованы все одновременно. Например, вы по желанию и возможности можете использовать сжатие изображений за счет mozjpeg или webp, но нет смысла использовать их одновременно, и такая задача одновременного использования не ставилась - разумно использовать лишь что-то одно. Модуль Компрессор создавался с целью выполнения рекомендаций гугла по оптимизации изображений и с целью передачи в браузер пользователя оптимизированных изображений. Исходники (т.е. те, что не в кеше) изображений модуль не сжимает, т.к. в этом нет необходимости поскольку речь идет о загрузке в браузер оптимизированных по весу изображений. Если на странице сайта есть изображение не из кеша изображений (из папки исходников, например, или из любой подобной папки), то для такого изображения будет создан оптимизированный вариант в формате WEBP, и именно WEBP будет передан в браузер, а исходник останется в качестве исходника в нетронутом виде. Основная цель - это уменьшить лишний трафик за счет передачи изображений в сжатом виде конечному пользователю чтобы у этого пользователя ваш сайт открывался быстрее и в целом работал быстрее. У модуля нет основной цели экономии дискового пространства у хостера, хоть и это можно сделать за счет использования технологии mozjpeg для сжатия jpeg изображений в кеше изображений opencart. Но если webp работает в 99.9% случаев, то mozjpeg можно эффективно использовать в 90%. Оптимизация (сжатие) изображений - Гугл PageSpeed одобряет. Теперь настоящий комбайн для работы с изображениями. Управление белыми полями изображений, фоном, размером, обрезкой картинок, отдельное управление изображениями для яндекс-маркета и т.д. Индивидуальные настройки для групп изображений ("всплывающие", "thumb-миниатюры"). "Компрессор" (Image Compressor) обеспечит максимальное сжатие изображений Opencart на обычном хостинге (функция proc_open php нужна для работы mozjpeg, optipng; но создание WEBP в режиме "по расписанию" не требует ее наличия в php, на котором работает ваш сайт) и всегда на VDS. Нужные функции (proc_open) вы можете сами включать даже на обычном хостинге (некоторые это позволяют, но не все). Установка софта для сжатия изображений Опенкарт (mozjpeg и optiPNG, WEBP) полностью автоматизирована в два клика на обычный хостинг и VDS (не требует знаний Linux). Для разработчиков и веб-мастеров, устанавливающих модуль своим заказчикам действует скидка Демо 2 (клиентская часть): http://watermark.sitecreator.pro Демо 2 (админка): http://watermark.sitecreator.pro/admin/index.php?route=extension/module/watermark_by_sitecreator Демо 1.5 (клиентская часть): http://watermark15.sitecreator.pro Демо 1.5 (админка): http://watermark15.sitecreator.pro/admin/index.php?route=module/watermark_by_sitecreator пользователь: DEMO пароль: DEMO Для Opencart 3.0 и Opencart 2.* С поддержкой WEBP, Lazy Load и др. Дистрибутив теперь универсальный (он один) для движка 2-й и 3-й версий. Начиная с версии 1.18.3 совместим со всеми сборками версий движков Opencart (ocstore, opencart.pro, русская сборка и т. д.) 1.5 и 2+ (2.0, 2.1, 2.2, 2.3), 3.0 Файлы движка не заменяются (используется vqmod или ocmod для соответствующих веток движка) Модуль Сжатия Изображений Opencart по максимуму использует возможности imagick (если установлен), что уже позволяет получить лучшие по качеству и размеру изображения. Кроме того, в отличие от дефолтного GD использование imagick позволяет уменьшить размер файла за счет очистки изображения от ненужной информации. Как избежать тормозов во время создания сжатых изображений? При обновлении до версии 1.12.6+ нужно проявить внимание! Внедрена защита "от дурака". Максимум настроек водяного знака Opencart (watermark): его позиция, поворот, прозрачность водяного знака и т. д. Можно настроить ограничение (запретить применять) для водяного знака как по имени файла/папок, так и по размерам. Также можно добавить к имени файла nowatermark , и на данное изображение водяной знак не будет накладываться. Адаптивный ресайз (resize, обрезка) изображения. Вот так работает WEBP Lazy Load модуля Компрессор. Гугл одобряет! Как включить нужную для максимального сжатия функцию? (в случае работы режима cron для создания webp это необязательно) требования: php 5.6+ (5.6; 7.0, 7.1, 7.2, 7.3, 7.4) Версию php у хостера вы можете изменить самостоятельно через панель управления. Ioncube Loader (версия 10+) Дистрибутив универсальный для всех версий PHP. Никаких отдельных файлов для разных версий! Только один установочный файл. Ускорители (кешеры) не влияют на работу водяного знака и сжатых форматов mozjpeg, optipng, но могут неверно влиять на вывод webp. Совместимые ускорители в плане WEBP, т.е. WEBP работает (выводится) корректно (но невозможно гарантировать бесконечную во времени совместимость с будущими версиями программного обеспечения сторонних разработчиков, данные приводятся на момент релиза модуля Компрессор версии 2.1.23): Jet Cache (все известные версии на момент выпуска модуля Компрессор версии 2.1.23) Turbo (версии для опенкарт 2.1 и 2.3 - полная совместимость) NitroPack (тестировался с NitroPack 2.5.3, про более свежие и будущие версии не берусь судить ). Это "старый Nitro". Больше не поддерживается, т.к. разработчик Нитро прекратил его продажу и поддержку. условно совместим (т.е. не всегда и не везде) nitropack.io / NitroPack IO (тестировался только на версии 3.8.1 в режиме включенной в Компрессоре совместимости с кеширующим ускорителем. Не путать с просто "NitroPack"! Возможны некоторые ограничения.) Новые и иные версии NitroPack IO не отслеживаются, совместимость не гарантируется, используете на свой страх и риск. Boost (проверялось только на опенкарт 2.*, не могу судить о версии на которой тестировался, т.к. разработчик в модуле не указал версию. Возможно, что есть несовместимые версии) Lightning (при включении опции совместимости с кеширующим ускорителем в Компрессоре и настройке в Lightning исключения для функции Компрессора [читайте инструкцию], в режиме совместимости эффективность использования webp может быть несколько снижена. Тестировалось на версии Lightning 3.38. Возможны некоторые ограничения.) Начиная с версии 2.1.0 модуль Компрессор позволяет включить повышенную совместимость с почти любым кеширующим ускорителем в режиме вывода webp. Независимо от того была ли сделана специально адаптация модуля Компрессор под конкретный ускоритель или нет. Эта возможность экспериментальная по принципу "как есть", нельзя заранее утверждать, что это будет работать везде на 100%. Например, в таком режиме может работать ускоритель Lightning (но желательно отключить (уменьшить агрессивность) в нем оптимизацию (минификацию) Javascript для HTML). В подавляющем большинстве случаев совместимость с Лайтингом работает, но нельзя гарантировать это со 100% для любого случая. Несовместимые в плане вывода WEBP (за счет модуля) ускорители способны не мешать корректному выводу WEBP если данный вывод делать за счет средств сервера. Например, за счет NGINX Конфиг (config) NGINX для вывода WEBP на VDS или Апачи при возможности (лимитирует хостер). Модуль совместим в плане корректного вывода WEBP (и отдачи для старых Сафари и др. старых браузеров JPEG, PNG соответственно) с ускорителями/кешерами Jet Cache и Turbo (версии для опенкарт 2.1 и 2.3 - полная совместимость) и, вероятно, с остальными. Совместим с NitroPack (тестировался с NitroPack 2.5.3 ). В случае использования модуля для сжатия только JPEG, PNG наличие ускорителя не сказывается на возможностях сжатия. Например, ускоритель Lightning совместим для работы с сжатыми форматами JPEG (mozjpeg), PNG (optipng) и совместим в режиме создания WEBP, но не совместим в режиме отображения картинок для старых браузеров и Сафари, который не понимает WEBP. В случае использования webp нужно понимать, что старым браузерам нужно отдавать jpeg/png. Именно так и работает модуль изначально, но ускорители могут за счет кеширования ломать такой алгоритм, а потому для указанных выше совместимых ускорителей была специально сделана адаптация чтобы не было проблем с webp. Модуль не заменяет файлы , используется ocmod для движка 2.*, аналогично в движке 1.5.* используется vqmod с 1.5.1 версии модуля. Просьба обратить внимание до установки модуля на то, не изменен ли код напрямую (или за счет модификаторов) в файлах (это нужно в том случае если вы собираетесь использовать водяной знак, на работу по созданию и выводу WEBP это не влияет): system/library/image.php, catalog/tool/image.php, admin/tool/image.php. Не гарантируется нормальная работа если у вас в движке были сделаны прямые (или за счет модификаторов) изменения кода указанных выше файлов. Это относится к работе водяного знака и т.п., на работу сжатого формата webp это никак не влияет. Желательно чтобы эти файлы были такими же как в дистрибутиве движка. Адаптация в случае изменений в вышеуказанных файлах может оказаться довольно сложной, пожалуйста, учитывайте этот момент. Для получения всех возможностей модуля предполагается, что файлы движка Опенкарт, отвечающие за работу изображений, не были изменены. Пожалуйста, лицензию запрашивайте, написав мне на почту или в личку. Пояснение к лицензированию. Лицензия предоставляется для одного домена с конкретным доменным именем (без возможности переноса на другой домен). Приобретая модуль вы соглашаетесь с принципом лицензирования. Подробно о лицензировании читайте здесь. mozjpeg, optipng необязателен к установке, это лишь рекомендация для достижения максимального сжатия. Софт mozjpeg, optipng, который входит в состав модуля, предназначен для Linux 64 bit. Этот же софт для Windows вы можете скачать и установить отдельно (ссылки и прилагаемые файлы есть ниже, софт существует как 32-х или 64-х битные исполняемые файлы для Windows, 32-х битный софт может работать на Windows 32 или 64 бит.) Процесс установки этого софта сводится к нажатию двух кнопок в модуле. Это работает как на обычном хостинге, так и на VDS. Самая распространенная "ошибка" после установки. Инструкция по установке дополнительного софта для WINDOWS : (для локальной машины разработчика, например. ). Модуль умеет накладывать водяной знак и сжимать изображения, которые вставлены по прямым ссылкам в описании товара, но с некоторыми условиями. Данная возможность предоставлена в качестве бонуса, но не как обязательная часть (может отсутствовать в дистрибутиве, но может быть предоставлена отдельно по запросу при наличии возможности), на некоторых шаблонах возможна несовместимость (не будет работать) с данной функцией (может потребоваться адаптация) поскольку шаблон может кардинально изменить существующий контроллер. Возможность данного функционала связана с особенностями конкретного шаблона, может потребоваться адаптация и доработка (на платной основе) для конкретного сайта. Для SEO CMS есть отдельное решение. Модуль умеет оптимизировать (сжимать) все изображения ваших шаблонов и логотип сайта. Это в дополнение к сжатию всех изображений, проходящих через движок (картинки товаров, категорий, баннеры и т. д. и т. п.) Для SEO CMS сделано решение, позволяющее также использовать супер-сжатие по максимуму и водяной знак в этом модуле. Сделано как отдельное дополнение к модулям "Компрессор" (Image Compressor) и SEO CMS. Такое решение обусловлено тем, что указанный модуль использует свою библиотеку и модели для работы с изображениями. Сжаты будут даже отображаемые оригиналы, вставленные по прямым ссылкам в статьях. И на оригиналы можно накладывать водяной знак и защищать их от кражи. Любые изменения с оригиналами обратимы. Например, можно менять водяной знак. Решение здесь: SEO CMS mod for Image Compressor & Watermark Решение по работе с фоном исходных изображений здесь: Можно обрезать, добавлять фон, делать аккуратные рамки цветом фона. Данное решение реализовано как плагин к модулю "Компрессор", т. е. все настройки делаются в модуле "Компрессор". Совместимость со специфическими модулями и модификаторами, (затрагивающими системную библиотеку и модель image.php) ПОДДЕРЖКА от автора модуля: Самодиагностика и вывод полезной информации - это первое средство если у вас "ничего не работает". А что это гугл пишет "изменение размера .... уменьшит"? Для работы с фоном исходных изображений (обрезка лишнего фона на исходниках) необходима дополнительная лицензия для работы соответствующего дополнительного плагина к модулю Компрессор. mozjpeg_3.1_x86.zip optipng.zip info.php Корректная работа модуля и совместимость гарантируются только в случае использования официальных дистрибутивов opencart, ocstore или "русская сборка". Решение вопросов совместимости и адаптация в случае использования нестандартного/измененного кода движка опенкарт возможно на платной основе. Добавил sitecreator Добавлено 26.08.2017 Категория Кэширование, сжатие, ускорение Системные требования php 5.6 - 7.4, Ioncube Loader версии не ниже 10+, ОС Linux 64 bit / FreeBSD 11 (12, 13) 64bit или Windows (относится к 99.9% случаев) Метод активации По запросу в ЛС По запросу на почту 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 OcShop 2.0.3.х OcShop 1.5.6.4.х Обращение к серверу разработчика Нет

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 Не проверялось Обращение к серверу разработчика Нет  

Приобрести модуль и узнать о нём подробнее можно здесь: Также рекомендую подписаться на тему поддержки, чтобы следить о ходе разработки и вносить предложения. На текущий момент в модуле реализовано около половины моих мыслей, но мои потребности покрывает. Если будет интерес у людей, то оставшаяся часть будет дописана. Мысли таковы: - упор на оптимизацию кода (сейчас библиотека составляет около 2000 строк); - скорость; - расширенные настройки; - компактность (то есть сколько всего можно в одном поле прописать); - подробное описание полей. Пример настройки демо сайта: Как видим легко и просто. Накидываем всё возможное, потом играемся ставя\убирая в начале строки " ; ", подбирая оптимальное решение. Сложность может быть, когда нужно писать js-код (нужен опыт и фантазия), чтобы разрешить какую-нибудь ситуацию, как в примере с видео окном (не хочу блок отправлять в lazy load html, так как он не хочет тогда отображаться на странице Google PageSpeed - на самом деле такова может быть прихоть заказчика, так как он будет думать, что перестал работать модуль). Для ценителей своего времени, есть возможность заказать настройку от автора (при заказе необязательно приобретать модуль). Большинство вопросов решает функционал "Замена в html-коде", когда отсутствует иная возможность. Например, мы хотим html тег <header> подгружать по скроллу, но в внутри <header> у нас встречается <noscript>, а значит нам нужно произвести его замену, так как loading lazy html построен по принципу применения тега <noscript>. В таком случае в loading lazy html предусмотрен атрибут data-busloadinglazy-remove, который удаляет ненужные теги. Но, есть задача: нам нужно подцепиться к ненужному тегу <noscript>. Для этих целей в функционале замены предусмотрена возможность замены несколько строк. Чтобы заменить такой код: Прописываем в поле "Замена в html-коде": В итоге получим: Обратите внимание на функционал кэша, а именно "Параметры работы" и "Параметры ограничения". Благодаря этим функциям у вас не будет быстро тратиться свободное место на сервере. А если ещё возможность позволит, то при отправки инлайн стилей и скриптов в файл сжатия - размер кэша каждой страницы будет весить на порядок меньше. Почему дисковое пространство может забиваться? Если у вас стоит модуль кэширования страниц целиком, то при отсутствии возможности ограничений по параметрам, любой человек может перебором любого параметра создать кэшированных страниц пока не закончится память сервера. Помимо этих функций модуль по умолчанию кэширует страницы с кодом ответа сервера 200. Точнее не кэширует, если обнаружит в заголовках любой ответ сервера не равный коду 200. Из скриншота настроек модуля вы могли заметить откладывание скриптов метрики и аналитики. Их можно откладывать и нужно для Google PageSpeed, но запустить необходимо как можно раньше (то есть по любым взаимодействиям с вашим сайтом). Google молодцы, даже код под это дело сделали удобным, а Яндекс нужно самому приводить к виду, как у Google. Суть работы такая: создаётся функция, она срабатывает и сохраняет время начала работы. После загрузки основного скрипта метрики и аналитики, они получают данные, на которые основывают поведенческий фактор. Обратите внимание, что у Яндекс метрики можно управлять временем одной из функций поведенческого фактора с помощью accurateTrackBounce - событие без отказов регистрируется через 10 секунд (учёт отказов). Суровый Google PageSpeed: Да нет, не суровый хоть и изменил алгоритм на суровый, просто сеть плохая между моим хостингом и сервером Google PageSpeed. В браузере страница загружается за пол секунды, а Google PageSpeed пишет про 2 секунды (First Contentful Paint 1,5 секунды на сетевой доступ + 0.5 секунды на загрузку содержимого). Это тот момент, когда правильный выбор хостинга или сервера практически решает вопрос по баллам Google PageSpeed. Есть ещё радикальный вариант - переписать стили, распределив по файлам, чтобы они точно относились по контроллерам и переписать весь код из jQuery на чистый js (это изначально нужно делать при проектировании шаблона), или придумать обвёртку, которая даст возможность отложить любые скрипты на jQuery. Если нет возможности переписать стили, то можно попробовать функцию модуля "Сбор критических стилей" и "Замена в css-коде, js-коде". С помощью инструмента "Coverage" Google Chrome можно найти ненужные стили и закомментировать, не трогая стили зависящие от ширины экрана (нужно иметь ввиду), подробности тут. Немного сократив стили bootstrap 3 (закомментировал иконки и загрузку шрифтов google), я могу в принципе метрику google запускать после загрузки страницы: Но, я никогда себе не поставлю метрику на рабочий проект и не буду лишать себя скорости, а своих клиентов анонимности: Поэтому прежде чем прибегать к оптимизации модулем, подберите себе хостинг или сервер (подбор хостинга или сервера с настройкой под ключ можете заказать у @snastik). После получения нормального сервера, возможно, простого сжатия стилей и скриптов будет достаточно (а такая возможность во многих шаблонах есть, а если нету, то есть лайтовая версия Буслік Кэш).

В последнее время на форуме все чаше стали обсуждать качество продаваемых шаблонов. Вот и я решил внести свою лепту, может разработчики шаблонов увидят этот пост и внесут корректировки в новых релизах. И так как многие из нас не будут обновлять шаблоны на уже рабочих сайтах, они смогут внести корректировки по представленным примерам самостоятельно, ну или с помощью кого либо. Так как много времени на написание полноценного материала нет, начну с малого и со временем дополню данный материал. Все что будет описано ниже внедрено на собственном сайте тут. И так поехали! 1. Проблема всех шаблонов с которыми я сталкивался это ширина и высоту для изображений задана не явным образом. Неужели трудно добавить через свои громадные модификаторы пару строчек в контроллеры для определения высоты и ширины картинки и вывести это дело уже в самом шаблоне? На примере категории продемонстрирую для простых пользователей с минимальными знаниями как это сделать. В контроллере категории /catalog/controller/product/category.php после: $data['products'][] = array( Вставляем: 'width' => $this->config->get($this->config->get('config_theme') . '_image_product_width'), 'height' => $this->config->get($this->config->get('config_theme') . '_image_product_height'), А в самом шаблоне делаем та: <img loading="lazy" src="<?php echo $product['thumb'];?>" width="<?php echo $product['width']; ?>" height="<?php echo $product['height']; ?>" alt="<?php echo $product['name']; ?>" title="<?php echo $product['name']; ?>" class="img-responsive" /> Ну и конечно в стилях должно быть так, а то картинки поедут... .img-responsive { display: block; max-width: 100%; height: auto; } Можно тут конечно обойтись и без контроллера, но это будет как некоторые говорят - не кошерно 2. Вторая супер мелочь, которая может прибавить пару Попугаев в PageSpeed Insights это нет свойство CSS font-display в описании шрифтов. Все довольно просто. Было так: @font-face { font-family: 'Open Sans'; font-display:auto; src: local('Open Sans'), local('OpenSans'), url('fonts/opensans.woff2') format('woff2'), url('fonts/opensans.woff') format('woff'), url('fonts/opensans.ttf') format('truetype'); font-weight: 400; font-style: normal; } Стало так: @font-face { font-display: swap; font-family: 'Open Sans'; font-display:auto; src: local('Open Sans'), local('OpenSans'), url('fonts/opensans.woff2') format('woff2'), url('fonts/opensans.woff') format('woff'), url('fonts/opensans.ttf') format('truetype'); font-weight: 400; font-style: normal; } Ну и обратите внимание чтоб в хедере шрифт был прописан с rel="preload", где-то так: <link rel="preload" href="opensans.woff2" as="font" type="font/woff2" crossorigin="anonymous"> 3. Почти у всех шаблонов есть поле для вставки счетчиков, но смысл его добавлять если этот ф-л уже есть в самом движке. Другое дело если б это было так, как реализовано в модуле от @spectre. Это бы избавило от лагов которые появляются от Аналитики и других подобных счетчиков и чатов. 4. Многие делают объединение файлов css и js в один файл. У некоторых это реализовано более менее, у других это полная катастрофа. Расскажу на примере. Было у меня на сайте в шаблоне реализация в таком виде: <script src="/min/f=catalog/view/theme/aurus/js/jquery/jquery-2.1.1.min.js,catalog/view/javascript/bootstrap/js/bootstrap.min.js,catalog/view/theme/aurus/js/aridius/blazy.min.js,catalog/view/theme/aurus/js/swiper/js/swiper.min.js,catalog/view/theme/aurus/js/common.js,catalog/view/theme/aurus/js/aridius/aridiusquickview.js,catalog/view/theme/aurus/js/aridius/slideout.min.js,catalog/view/javascript/jquery/magnific/jquery.magnific-popup.min.js,catalog/view/theme/aurus/js/aridius/module.js"></script> <link href="/min/f=catalog/view/javascript/bootstrap/css/bootstrap.min.css,catalog/view/theme/aurus/js/font-awesome/css/font-awesome.min.css,catalog/view/theme/aurus/stylesheet/stylesheet.css,catalog/view/theme/aurus/stylesheet/aurus.css,catalog/view/theme/aurus/stylesheet/module.css,catalog/view/theme/aurus/js/swiper/css/swiper.min.css,catalog/view/javascript/jquery/magnific/magnific-popup.css,catalog/view/theme/aurus/stylesheet/animate.min.css" rel="stylesheet" media="screen" /> Это полная жесть, мало того что такую конструкцию не удалось завести, когда я надумал перевести сайт под nginx, так такой запрос отдает кривой заголовок и браузер его не до конца понимает как css и не кеширует. Лучше уже создавать кешируемый файл, который есть физически на сервере и имеет нормальный заголовок. Тогда еще решил этот вопрос костылем, создал физические файлы на основе такого запроса и прописал их в шаблоне. Сейчас сменил на шаблон CyberStore от @29aleksey где это реализовано более менее, но тоже есть и тут не мало минусов, по крайней мере лучшего не нашел. 5. Еще один момент, многие используют в своих шаблонах отложенную загрузку изображений. И вместо картинки товара поисковик видит какую-то картинку без ничего в один пиксель. В коде это выглядит так: <img class="lazyload" src="lazyload.png" data-src="apple-200x200.jpg" alt="Apple" title="Apple" /> Лучше сделать так: <img loading="lazy" src="apple-200x200.jpg" width="200" height="200" alt="Apple" title="Apple" class="img-responsive" /> На этом пока все. Надеюсь, в скором времени дополню пост еще информацией. Если у Вас есть еще чем дополнить информацию пожалуйста предлагайте, будем дополнять. И еще, все эти мелочи и идеальные шаблоны не сделают ваш сайт по истине быстрым, особенно если на нем несколько десятков тысяч товаров. Тут еще может понадобиться улучшить ответ сервера, а для этого скорее всего понадобиться перейти на более мощный сервер, правильно его настроить, оптимизировать базу и избавиться от модулей с кривыми запросами или поправить их. С частью из этих вопросов помог справиться @Yoda. И только тогда вы увидите заветное слово в PageSpeed Insights – Отвечает Так же хочу сказать, что вся эта гонка за скоростью не принесет Вам много трафика, это как маленькая доля СЕО, которая скорее всего будет работать только в комплексе с другими видами СЕО оптимизации. Но как минимум сейчас это будет способствовать тому что пользователь не сбежит с сайта пока будет ждать прогрузки страницы. В будущем может это и будет одним из основных методов ранжирования… Так что стоит подготовиться за ранее, почему нет. Всем мирного неба над головой, щедрых клиентов и хороших продаж!

Зашел я сегодня посмотреть свежую ленту форума и увидел очередное хамство нашего героя: Это ужасно, ужасно ужасно в рамках поддержки платного дополнения, которое только разводит и не делает результат! Но мы же с вами грамотные красавчики. И мы понимаем что волшебной таблетки не может быть! Но нам гуглпейдж спид кажить все эти FCP CLS и весь этот бред типа. Друзья. ни один модуль не решит ваши проблемы. Потому как вот эта вся модель оценки вашего ресурса, она очень сложная, ее сложно обмануть, она учитывает пользовательскую статистику хрома, кроме того что вам любые модули могут обмануть бота, и все это уже не актуально. И у вас там может быть сложнейшая верстка, куча лишнего контента, да все что угодно. Но ок, что же нам делать, у нас есть рабочий интернет-магазин. мы хотим подтянуть позиции по выдаче и стоим на распутье, хотим быстрый First contetn paintfull и отсутствие Cumulative Layout Shift. Наверное в формате магазина невозможно достичь идеальных показателей, но мы можем к ним попробовать постремиться. Итак, что я вам советую сделать, чтобы у вас улучшились показатели, без хамства авторов дешевых бесполезных поделок и при этом своими руками и легко: 1. Все изображения во всех модулях, списках, баннерах и так далее идут в Lazy, просто берете и делаете нативное Lazy https://developer.mozilla.org/ru/docs/Web/Performance/Lazy_loading Просто добавляете к изображениям свойство loading="lazy" 2. все изображения переводите в webp, для этого не надо бежать к сайткиратору и покупать платный модуль, просто пользуете это: 3. В большинстве шаблонов у нас по умолчанию в верстке list, который потом через js переводится в grid, сделайте grid в верстке по умолчанию и это отличн вам решит CLS показатель, так как у вас не будет сдвига макета при рендере, если не знаете что это и не знаете как сделать - долбите авторов шаблонов. 4. Новые хотелки page speed хотят, чтобы skeleton разметки страницы был сразу с установленными параметрами размеров изображений. Если у вас единый размер, задайте во всех выводах изображений width и height принудительно. 5. Используйте современные шаблоны. Да я верю, что вы все положили много денег и ресурсов в то что у вас есть, но или Криво косо, но содержат в себе какие-то built in механизмы отпимизации-сжатия скриптов стилей и дадут вам меньше запросов на вебсервер. Несмотря на кривость реализации, это лучше чем ничего! А еще шаблон от @29aleksey все таки прилично выглядит по сравнению со всеми остальными поделками за полтосик. Мне бы в 2012 году такой, для моих магазинов. Реально Леха-кравачик и душу вложил! 6. Если вам вот прямо необходим JivoChat, Вот вам отличный мануал, как решить с ним проблему; https://habr.com/ru/post/447262/ 7. Да я молчу про TTFB, который тоже влияет на оценку pagespeed, да я знаю как это сделать, да, я с удовольствием сделал бы бесплатную таблетку, которая решала проблему быстрой загрузки HTML контента, но это не возможно к сожалению, Минимум что я вам могу рекомендовать, едьте на быстрые хостинги, пользуйте пхп 7+, следите за включенным opcache. 8. Если у вас там метрики и аналитика от гугла - снести все в футер, это плохой совет, возможно вы лишитесь 3-5% каких то показателей, но зато внешние скрипты не затупят. 9. если у вас модуль доставки типа сдэка - посмотрите, чтобы он не пытался грузить яндекс карты на все страницы магазина. 10. Если вы пользуете метрику, отключите в ней вебвизор, вы им вряд ли будете пользоваться и смотреть в него, если нужен - никто не мешает включить! 11. Счетчики, аналитики и т.д. Ни в коем случае не делайте их подгрузку по пользовательскому событию или в отложенную загрузку. Уж если сильно вам мозолит глаза 10-15 баллов, которые они навешивают, снесите их в футер. 12. Вывод и скрытие контента в зависимости от типа устройства. Используйте с умом. Пользуйтесь не js библиотеками а mobiledetect, от того что вы спрячете в display none какой либо элемент, он все равно будет опубликован в DOM страницы, если что-то хотите убрать для мобильных устройств, просто не выводите этот контент фактически при генерации html кода! Но даже если вы реализуете большую часть моих советов, у вас будут отличные оценки pagespeed, и вас не придется выслушивать блевотный бред от авторов которые не смогли, или пытаются нажиться на трех строчках кода на ваших болях, как тот же ситикриатор со своим вебп компрессором, не замечая, что рядом есть отличные бесплатные решения! upd: ну и еще банальшина, но проверяйте настройки кеширования сжатия статики, и если у вас webp то и для него добавляйте правильные заголовки. К примеру, если у вас ISP то должно выглядеть так: Если у вас странные шаред хостинги или нестандартные панели сервером - гуглите, как настроить кеширование сжатие для статики - в зависимости от вашего веб-сервера. Опять же возвращаясь к ISP менеджеру, который заполонил все, попросите вашего вебмастера или саппорт хостинга проверить, чтобы nginx отдавал вот для этого всего правильные заголовки: location ~* ^.+\.(webp|jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|flv|swf|woff2?|ico)$ { access_log off; expires max; break; } Вот прямо можете давать ссыль на статью и говорить - хочу вот так для вебп!

Данная запись содержит личный опыт и наблюдения, как собственные, так и клиентские, поэтому не претендую на истину в последней инстанции и с удовольствием ознакомлюсь с аргументированной критикой. Убедительная просьба в комментариях придерживаться уважительного тона общения, дабы сохранить запись в удобочитаемом виде для всех желающих. Содержание записи для многих будет очевидно и понятно, однако есть немалое количество людей, которые до сих пор верят определенным мифам о 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): Выводы дополнены информацией из комментариев.

Наверное то, о чём я хочу рассказать для многих не будет новостью, но я столкнулся с подобным впервые и решил поделиться. Надеюсь эта заметка кому-то сохранит нервные клетки. Пришла ко мне совершенно обычная задача, которую я делал десятки раз - адаптировать некий модуль под шаблон. А если быть точнее, то адаптация уже имелась (к более старой версии шаблона), нужно было разобраться почему не работает на актуальной версии и поправить. Первый тревожный звоночек был после того обнаружилось что обновления модификаций не применяются. Заметил я это не сразу, и очень удивился, когда увидел во фронте код вообще какой-то старой версии адаптируемого модуля, хотя в папке модификаций всё было нормально. Дальше классика жанра - обновить модификации еще пару раз, очистить кеш из админки, проверить редактор шаблонов, поискать всем известные модули "ускорители" и тд и тп. Все эти манипуляции ничего не дали. Пошел в папку /storage/cache/ и обнаружил там странную папку /home/ которая не типична ни для опенкарта, ни для модулей "оптимизаторов" которые мне знакомы. Это был второй тревожный звоночек. "Пхаха, наверное это новая фича - оптимизация на стороне хостинга" посмеявшись подумал я, снёс весь кеш руками, всё заработало. Всё было нормально, работу доделал и сдал. Через день клиент возвращается с очень странными симптомами. "Вот в этом товаре не работает это", "а вот в этом это", "а вот там в каталоге это", "а в быстром просмотре вот этого товара это". Убедившись что это и правда так я слегка прих**л. Заметил что в некоторых редких ситуациях при определённых действиях js код выпадал в Uncaught TypeError, но не в модуле с которым работал, а в разных местах. Я снова прошерстил установленные модули, модификаторы, посмотрел системные модификаторы, пробежался по файлам и проверил не редактировали ли некоторые системные файлы. Но сайт выглядел достаточно адекватным (что в нашем мире встречается редко). Изучив более детально я понял что всё-таки есть "нечто" которое делает плохие вещи, очень плохие вещи. Например я обнаружил что инлайн скрипты минифицируются, а некоторые вообще исчезают, в том числе системные опенкартовские! И происходит это в разных ситуациях по разному, в одних товарах есть скрипт нужного мне модуля, а в других его просто нет, хотя в кеше модификаций всё есть и никаких условий "отображать только если" - там нет. Я просто опешил от такой наглости и идиотизма. Грешным делом я стал ругаться на новую версию шаблона, хоть работал с ним раньше, и претензий не имел. Но ни в настройках, ни в демо шаблона я не увидел пунктов "сверхоптимизации быстродействия", все оптимизации были адекватными, в html коде демо-версии ничего из инлайна не минифицировалось и не вырезалось. В общем текста на эмоциях написал больше чем планировал, надо закругляться. Выбил я у клиента доступ к панели управления хоста. Хостом оказался таймвеб. Перерыл панель вдоль и поперёк и нашел это чудо: Таймвеб, вы серьёзно?! Вы ЭТО еще и продаёте?

14.99 При покупке доступ к обновлениям в течение 1 года После окончания основного периода доступ к обновлениям можно продолжить 10.00 USD за год Скачать / Купить дополнение Инструмент, который поможет ускорить мобильную версию OpenCart! Как сделать шаблон адаптивным? на мобильной версии скрыть "лишние" элементы. Нужно, что-бы при этом не пострадало usability? переместить модули и виджеты на другие позиции. Даже топовые шаблоны, поступают именно таким образом, элементы которые "не нужны" или наоборот необходимы только в мобильной версии: либо скрываются посредством css (display:none); либо перемещаются, хорошо если flexbox или bootstrap pull push но часто с помощью навешивания множества слушателей событий javascript. Даже адаптивность bootstrap основана на таких принципах. Всё это создаёт лишний "вес" и нагрузку, что конечно же замедляет работу сайта и заставляет процессор пользователя работать с повышенной нагрузкой шумя как майнинг ферма. Мы в наших продуктах пропагандируем использовать только то, что необходимо сейчас. И исходя из этих принципов нами был разработан модуль Мобильные схемы который поможет: уменьшить объём страницы (предотвратить чрезмерную нагрузку на сеть), сократить размер структуры DOM, ускорить время окончания работы ЦП, избавится от лишнего JavaScript кода (сократить время выполнения кода JavaScript), избавится от css костылей, а так-же: Устранить ресурсы, блокирующие отображение, Сократить время ответа сервера (время до получения первого байта, TTFB), Использовать подходящий размер изображений, и др. при этом даже улучшив адаптивность, гибкость в настройке и дружелюбность Вашего сайта! Поддерживает встроенные схемы популярных модулей, например поддерживает SEOCMS. В конце месяца большие скидки! Старая цена 15$ со скидкой 5$! данная версия поддерживает OpenCart 2.1.x, 2.2.x, 2.3.x, ocStore 2.1.x, 2.2.x, 2.3.x версию для Opencart 3.x, ocStore 3.x можно скачать здесь! Техническая поддержка доступна пользователям из списка покупателей и только после прочтения faq: Если вы обращаетесь с просьбой разобраться в проблеме, то для экономии времени укажите: адрес сайта доступ в админ-панель доступ на FTP-сервер По любым вопросам вы можете связаться с нами через: Личные сообщения на форуме; Режим работы с 10-00 до 18-00 по киевскому времени за исключением выходных и праздничных дней. Внимание Модуль не является кнопкой - нажал и сайт "полетел"... за "волшебством" лучше обратиться к другим модулям. Layout Type - инструмент, который даёт возможность настроить и ускорить мобильную версию магазина. Спасибо, что прочитал!) Лови купон с боольшой скидкой 678008-read Добавил Sha Добавлено 13.03.2018 Категория Кэширование, сжатие, ускорение Ioncube Loader Нет ocStore 2.3.0.2.4 2.3 OpenCart.Pro, ocShop Opencart.pro 2.3 Обращение к серверу разработчика Нет  

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 Обращение к серверу разработчика Нет  

Добрый день. Нужно увеличить скорость загрузки сайта. https://sfera36.ru/. Сайт древний, но пока как то так:) В каталоге pagespeed вообще 11... Ocstore 1.5.3.1

Здравствуйте. Есть готовые решения или рекомендации по поднятию Google pagespeed?

Друзья у нас тут есть много холивара по поводу pagespeed и влияние его на выдачу, есть три талантливых ремесленника, которые продвигают свои поделки как какую-то волшебную таблетку, которая там типа чего-то дает. И есть странный тип йода, который всем лечит какую то дичь, чистихвостит по чем зря и ваще. Так вот вашему покорному слуге, этому неграмотному программисту, который не знает пхп, только что и может настраивать сервера.. ну и все в таком духе. Кароче мне, один мой товарищ прислал два скрина, как оно бывает... Подоплека нашей с ним тесной дружбы была следующая, у него стояли какие то там лайтнинги, джет кеши, хрен пойми еще что, магазин не работал, падал в выдаче яндекса, а в гугле не было трафика совсем. В июне-июле мы сделали полнейший подход по настройке-оптимизации проекта, пришлось привлечь чуть ли не всю нашу банду, для закрытия вопросов с фильтром, версткой, и сделать огромное количество тонких настроек магазина, дабы он стал удобный и понятный для покупателя. Тогда помнится мы сразу получили вот такой результат: Это замечательно, фантастически - и мы вернули за три месяца трафик по яндексу и он даже начал расти, сугубо настройкой сервера и магазина... Однако, как вы видите у нас есть аномалия с гуглом. Если кто внимательно следит за гугл вебмастером, у них месяца четыре ничего не работало, нельзя было страницу в индекс добавить принудительно, и отчет о обходе страниц был с лагом в несколько недель. Так вот. Так совпало, что когда гугл починил вебмастер, вот те самые два скрина: Мысль одна: За это время с магазином глобального ничего не делалось, не проводилось больше никаких работ. Ничего. И тут вдруг такая фантастика. К чему это я все написал спросите вы? Йода, ты опять устроил черный пиар кривых своих доработок? Ты мстишь дырявому бракибраку? Думайте друзья что хотите, за что купил - за то продал. Единственное, что в отличии от всех остальных докладчиков, в нашей лабораторной работе мы можем наблюдать реально влияние скорости загрузки сайта на позиции в выдаче - а не гадать на кофейной гуще. Как другие докладчики типа: Ну и все это было бы не совсем полным описанием истории. Если бы я не привел еще один магический график: Если кто не знает где его взять - найдите его в в настройках в гугл вебмастере в разделе статистика сканирования. Вот как по мне - этот показатель наиболее ответственен за качество сканирования вашего магазина.

900 Скачать / Купить дополнение Оптимизация и ускорение сайта для максимального повышения оценки pagespeed Гугла УСЛУГА (работа): Оптимизация сайта на опенкарт 1.5, 2.1, 2.3 и 3.0 Необходимо заранее до оплаты услуги обговаривать с исполнителем все нюансы предстоящей работы по оптимизации. Без предварительного анализа вашего сайта не стоит делать оплату. Если нужен бюджетный вариант оптимизации, то можете приобрести модуль оптимизации hi-optimizer с установкой и настройкой Добавил sitecreator Добавлено 17.04.2020 Категория Услуги  

Недавно мне написал один товарищ-разработчик (имя которого из соображений профессиональный этики раскрывать не будем): Лирическое отступление, если кто не знает, что это такое: https://developer.mozilla.org/ru/docs/Web/HTML/Preloading_content Значение preload атрибута rel в элементе <link> позволяет вам запросить данные через <head> вашего HTML, указав необходимые вашей странице ресурсы ещё в начале её жизненного цикла, - до того, как сработает основной механизм отрисовки браузера. Это гарантирует, что предзагрузчик нужных ресурсов с меньшей вероятностью заблокирует отрисовку страницы, тем самым улучшая её производительность. Пример: Идеальный сценарий использования предзагрузчика контента описан в документации https://web.dev/uses-rel-preload/ Когда у нас на странице есть некая критическая цепочка ресурсов, к примеру, index.html содержит app.js, а в последнем идет подгрузка пары ресурсов styles.css и ui.js, то наша страница, очевидно, не будет полностью загружена, пока эта парочка ресурсов не будет также загружена и выполнена. Соответственно, узким местом такого сценария является загрузка и обработка app.js, до выполнения которой про вышеупомянутую парочку ресурсов никто не знает. Использование rel="preload" позволяет "вклиниться" в этот процесс и запросить загрузку дополнительных ресурсов (та самая парочка styles.css и ui.js) ДО того, как будет загружен и обработан app.js, поэтому при использовании предзагрузчика картинка заметно меняется и нам не приходится ждать, пока поочередно загрузятся все ресурсы, мы сразу заранее требуем их загрузчки: <head> ... <link rel="preload" href="styles.css" as="style"> <link rel="preload" href="ui.js" as="script"> ... </head> Так вот, у меня в шаблоне (да и не только у меня и не только в шаблонах) rel="preload" используется "втупую" для всех ресурсов, поскольку я не знаю, какие ресурсы могут оказаться критически важными, ведь отвечаю только за ресурсы шаблона, а пользователь может дополнительно поставить модули и подключать что угодно еще, что может быть как критичным, так и нет. Этот сценарий не особо эффективен и практического смысла в таком использовании rel="preload" мало, но я был уверен, что никакого заметного влияния на попугаев PageSpeed это иметь не может, поэтому, чтобы на практике подтвердить это, показал своему оппоненту результат использования/отсутствия rel="preload" на демке шаблона (много текста и картинок): С preload: 56/72 55/69 57/70 Без preload: 56/70 52/69 54/70 Как видите, разницы вообще нет, ведь что мы сделали, добавив всем ресурсам rel=preload? Да ничего полезного (и вредного) в целом, мы объявили, что все ресурсы - критические, и их всех надо грузить в первую очередь, в результате пузомерка больше не ругается на традиционный пункт: Устраните ресурсы, блокирующие отображение И накидывает нам 1-2 попугая, которых можно списать на статистическую погрешность. Изменилась ли фактическая скорость загрузки страницы? Да ничуть, ведь у нас как раньше все эти ресурсы грузились сразу, так и сейчас грузятся сразу. Мой оппонент, продолжая спорить и подчеркивая свою важность и экспертность, ответил мне, что всему виной мой быстрый сервер: Хотя по факту у меня на демо даже не VPS, но ладно - мы, как говорится, люди не гордые, иду на бесплатный Beget, разворачиваю там чистый движок и копию чистого шаблона и что же видим: С preload: 84/92 83/93 86/92 Без preload: 84/91 83/95 85/92 Оппоненту был неоднократно предложен доступ к FTP, чтобы он сам все своими руками проверил, если не верит мне и считает, что я как-то по особенному все настраиваю или подкручиваю цифры в свою пользу, также я попросил доступ к хоть одному из его клиентов, у которого, по его словам, наблюдаются такие просадки попугаев, которые мне озвучиваются, но увы - мои предложения были проигнорированы, а я получил еще один убийственный аргумент: Оказывается, бесплатный бегет слишком быстр, чтобы увидеть обещанную просадку попугаев. Ну что ж поделать, иду на медлительный бесплатный американский Awardspace (чтоб уж наверняка медленно все было, даже пинг в 2 раза дольше бегета) и повторяю процедуру, получая предсказуемое подтверждение отсутствия разницы в попугаях: С preload: 67/91 63/85 63/87 Без preload: 65/81 66/89 62/86 Какой я получаю ответ от оппонента? Думаете, признание собственной неправоты? Как бы не так! Оказывается, теперь уже тесты неправильные, а файл у меня внезапно оказался объединен (хотя выше 3 раза демонстрирую, что это не так и в тестах минификация выключена и проверяется подключение всех 12-ти штатных файлов, а не одного объединенного, но мой оппонент не опускается до таких скучных задач, как чтение аргументов). Внимание, вопрос! Что я делаю не так и почему не вижу разницы в попугаях и с чего вдруг использование rel="preload" должно давать просадку в 20-40 попугаев (как это утверждает мой оппонент)?

80 Завантажити / Придбати розширення Оптимизация для максимальной оценки PageSpeed от Google Проверенные шаблоны: default, disco, unishop 1 и 2, ultrastore, revolution, moneymaker2, aurus, Простор Делаю всё тоже самое, что и здесь. +Никаких копирайтов на вашем сайте со стороны клиентской части; +Установка и настройка модулей: модуль кэширования; генерация webp изображений (если сервер поддерживает); убирание циклических ссылок; отключение ненужных контроллеров по роуту; +Доступ к обновлениям модулей описанных выше. Оптимизация отклика сервера и скорости генерации сервером страниц (отдаваемый HTML) не входит в данную услугу. По оптимизации серверной части обратитесь к @snastik. УСЛОВИЯ СОГЛАШЕНИЯ На вашем сайте не должно быть ошибок в php и js коде (устраняются за отдельную плату); Отклик сервера и обработка php кода должно отрабатывать не дольше 0.8 секунды (за плохой отклик сервера Гугл снимает 15-20 баллов, а значит гарантировать не могу оценку 90 без кэша); После сдачи работы претензии и вопросы не предъявляются исполнителю; Если результат оценки не будет достигнут 80+ на всех страницах (имеющий шаблон и количество товара не больше 50шт.), будут возвращены деньги без комиссии данной площадки (-30%) и восстановлен сайт в исходное состояние (по желанию клиента). Автор buslikdrev долучення 28.04.20 Категорія Услуги  

Доброго времени суток дорогие друзья! Нужен очень хороший мастер который сможет мне ускорить время загрузки страниц! На сайт 100К товаров. Сейчас чтоб открыть сайт займет 16-27 секунд , нужно сделать что все максимально быстро открывалось и грузилось. Чтоб были хорошие показатели на https://gtmetrix.com/ , и https://developers.google.com/speed/pagespeed/insights/?hl=RU . Кто в этом деле профи прошу помощь, пишите свои предложения! Сайт: https://lunaopt.com.ua/

знаю этот вопрос поднимался уже 100500 раз и только я один с кривыми руками который не может нормально все поставить и исправить но Отключения блокировки воспроизведения JavaScript и CSS в содержании вверху страницы На странице есть ресурсы сценариев (1) и ресурсы CSS (2), которые блокируют загрузку. Это вызывает задержку воспроизведения страницы. Удалите файл JavaScript, который блокирует воспроизведение. jquery / jquery-1.7.1.min.js Оптимизируйте доставку файла CSS указанных ниже ресурсов. stylesheet / style.css? 02092014 /stylesheet/responsive.css пробовал загружать скрипт через <script async> скрипт отваливается пробовал переносить перед </ body> - отваливается. в на хосте ставил галочки на Настройки оптимизации сайта - там тоже не очень помогло - одно улучшилось другое отвалилось. просьба не советовать ставить модуль

Здравствуйте! Необходимо доработать загрузку сайта, что бы страницы грузились быстрее. В данный момент загрузке мешают js скрипты, всякие счетчики (метрики, гугла), дживо чат итп. Есть проблемы с фото и большим количеством запросов к БД. Это сказывается на показателях pagespeed (для мобильных 46 показывает). Нужно придумать как реально ускорить загрузку и отложить запуск js, но что бы сайт для пользователей грузился нормально. Рассмотрю любые варианты сотрудничества!