Лидеры

Небольшое уточнение к моему посту выше — про флаг lazy_load_disabled. Я назвал его «мёртвым кодом», но, разобравшись глубже, это неточно: правильнее — незавершённая заготовка ровно под эту задачу. Само имя выдаёт замысел: пометить картинку как «ленивую загрузку отключили». Уточняю, почему в текущем виде оно не работает — это подсказывает, где механизм не был доведён. Единственное присваивание — в хуке ab__preload hooks/common/image.pre.tpl: {if $restore} {$image_additional_attrs['lazy_load_disabled'] = true scope="parent"} {$restore = false} {/if} Ставится только в JS-режиме ($restore = true лишь когда на входе $lazy_load == true). В нативном режиме, где и возникает проблема с loading="lazy", флаг не выставляется вовсе. Потребитель не реализован. Значение нигде не читается: шифрованных файлов в ab__preload/ab__lazy_load нет, lazysizes 5.3.2 такого атрибута не знает, func.js ab__lazy_load его не проверяет, PHP тоже. И не может быть прочитан ab__lazy_load из-за порядка хуков — он выполняется раньше ab__preload (priority 190000 против 200000), поэтому на момент его работы флага ещё нет. Побочный эффект: render_tag_attrs булев true выводит как голый атрибут, поэтому в JS-режиме флаг протекает в разметку — <img … lazy_load_disabled> (невалидный атрибут, браузер игнорирует). Вывод: проще всего закрыть задачу форсированием loading="eager" в ab__preload (как в предложении выше) — это покрывает оба режима и не зависит от порядка хуков, а присваивание lazy_load_disabled тогда можно убрать (заодно уйдёт мусорный атрибут в JS-режиме). Если же сигнальную модель хочется сохранить, её придётся переносить: сигнал должен выставляться до работы ab__lazy_load, и на его стороне нужен читатель.

Снова приветствую. Тут еще в борьбе с гуглпейджспидом и дерганьем при загрузке нашли момент важный. --- Тема: в нативном режиме ab__lazy_load предзагружаемая картинка получает loading="lazy" — прелоад и ленивая загрузка противоречат друг другу, страдает LCP Оба модуля — ваши, и в связке они не примиряются, когда ab__lazy_load работает в нативном режиме (mode = native). Итог: главное фото товара (а также баннеры и плитки категорий) одновременно: предзагружается: <link rel="preload" as="image" fetchpriority="high" href="…"> (ставит ab__preload); и помечено loading="lazy" (ставит ab__lazy_load). Это прямой антипаттерн: прелоад говорит браузеру «грузи сразу с высоким приоритетом», а loading="lazy" — «отложи». Lighthouse/PageSpeed это ловит («LCP image was lazily loaded»), и предзагрузка фактически обесценивается. Причина (разобрана по коду): Оба модуля вешают хук на common/image.pre.tpl. Шаблонные хуки выполняются в порядке приоритета аддонов (fn.init.php: SELECT … FROM ?:addons … ORDER BY priority; SmartyEngine/Blocks/Hook.php: foreach по аддонам без пересортировки). Приоритеты: ab__lazy_load = 190000, ab__preload = 200000 → ab__lazy_load выполняется ПЕРВЫМ. В нативном режиме хук ab__lazy_load вешает атрибут loading="lazy": {if !$lazy_load} {$image_additional_attrs.loading="lazy" scope=parent} {/if} и при этом НЕ меняет переменную $lazy_load (в true её ставит только JS-режим). Хук ab__preload (выполняется вторым) свою защиту от lazy включает только веткой {if $lazy_load} — истинной лишь в JS-режиме. В нативном режиме $lazy_load = false, поэтому защита не срабатывает: предзагружаемая картинка так и остаётся с loading="lazy". Флаг lazy_load_disabled, который ab__preload при этом присваивает, нигде не читается (мёртвый код) — то есть текущая защита в нативном режиме не делает ничего. Подтверждено на реальных страницах и замерами. На пристинной установке (нативный режим) главное фото товара приходит с loading="lazy" при наличии preload fetchpriority="high" на ту же картинку. Сравнительный A/B (PageSpeed mobile, одна страница, по 2 прогона на режим): нативный режим устойчиво лучше JS-режима (score ~73–78 против 62–72; TBT ~250–380 мс против 510–590 мс — JS-режим грузит основной поток ленивой обработкой ~100 картинок). То есть переключение в JS-режим как обходной путь не подходит — чинить надо в нативном. Предложение (владелец фикса — ab__preload, т.к. он выполняется вторым и уже знает, что картинка приоритетная). В хуке ab__preload/hooks/common/image.pre.tpl, внутри блока принятия решения о предзагрузке, форсировать eager: {if ($ab__ll.mode|default:'') !== 'js'} {$image_additional_attrs.loading = 'eager' scope="parent"} {$image_additional_attrs.fetchpriority = 'high' scope="parent"} {/if} Поскольку ab__preload выполняется после ab__lazy_load, его loading="eager" перекрывает выставленный ранее loading="lazy". Guard !== 'js' оставляет JS-режим без изменений (там ab__preload уже разлочивает картинку через $lazy_load = false, и вмешательство в атрибуты может задеть lazysizes/srcset). Правка покрывает разом главное фото, баннеры и плитки категорий. Мотивация: предзагрузка картинок — ключевая функция ab__preload ради быстрого LCP — в нативном режиме ab__lazy_load сейчас не работает: браузер всё равно откладывает предзагруженную картинку. После правки прелоад начинает выполнять своё назначение, и у пользователей снимается замечание PageSpeed «LCP image was lazily loaded». Минусов нет: правка применяется только к тем картинкам, что ab__preload и так помечает на предзагрузку (приоритетные, первый экран); обычные картинки сохраняют нативный loading="lazy". JS-режим не затрагивается (guard). Проверено: в нативном режиме предзагружаемое главное фото становится eager, прочие картинки остаются lazy; в JS-режиме рендер идентичен прежнему.

Приветсвую. Изучите плиз на сколько Клавдия Антроповна говорит по дело. Я со своей стороны тесты погонял, замеры поделал. Вроде не вреть. Это и баг т.к. не работает и предложение как решить. Оно конечно только в связки с ядром сработает. Надеюсь вы со своей стороны простимулируете команду Карта к фиксу. Ну а если нет, то предлагаю добавить этот фикс к вам и информацию в справку модуля, как у вас сделано с модулем Мтеатегов например. Я им тоже написаль. Тема: прелоад шрифтов промахивается мимо query в CSS — шрифт грузится дважды fn_ab__p_get_css_timestamp() формирует query для <link rel="preload"> из собственной метки. Она никогда не совпадает с query того же шрифта внутри скомпилированного файла стилей standalone.*.css, потому что ядро (Tygh\Less::parseUrls) пишет туда компайл-тайм TIME, различный у каждого такого файла. Итог: предзагруженный шрифт браузер скачивает повторно при разборе CSS — прелоад не срабатывает, и вместо ускорения получается лишняя загрузка, то есть противоположное назначению модуля. Предложение: привязать query прелоада к cache_id: $cache_id = fn_get_storage_data('cache_id'); if ($cache_id) { return $cache_id; } return Registry::ifGet('ab__preload.timestamp', 0); и по возможности эскалировать правку в ядро (см. выше) — тогда query прелоада совпадёт и со скомпилированными файлами стилей, а с критическим CSS (если он на cache_id) совпадает уже сейчас. Мотивация: сейчас ключевая ценность модуля — предзагрузка ради быстрого первого рендера — для шрифтов не работает вовсе; после правки модуль начинает делать ровно то, что обещает, и снимает у пользователей замечание PageSpeed по шрифтам. Минусов нет: cache_id стабилен в пределах одной генерации ассетов и бампается при очистке кэша — busting сохраняется, а идентичные шрифты получают единый URL во всех скомпилированных файлах стилей.

@AndreyJ эти предложения были реализованы в данной версии: 1. https://community.abt.team/topic/2176-v4201b-unitheme2-obnovlenie-ot-21-maj-2026/page/4/#findComment-16487 2. https://community.abt.team/topic/2176-v4201b-unitheme2-obnovlenie-ot-21-maj-2026/page/2/#findComment-16401

Приветствую. Клавдия хочет предложить небольшую оптимизацию хука генерации превью в теме Unitheme2 (app/addons/abt__unitheme2/func.php). Даже прям настаивает. говорит несколько раз перепроверила. Гооврит уууххх как все ускорится, т.к. непрозрачных изображений 99% обычно. Суть Хук fn_abt__unitheme2_generate_thumbnail_post нужен для пересоздания превью прозрачных изображений (чтобы сохранить альфа-канал). Однако сейчас он первой же строкой вызывает fn_get_image_size() (а внутри — finfo_file(), чтение файла оригинала) для каждого изображения, и лишь затем проверяет флаг прозрачности: function fn_abt__unitheme2_generate_thumbnail_post($th_filename,$lazy,$image_path,$width,$height,$image){ list(,,,$tmp_path) = fn_get_image_size(Storage::instance('images')->getAbsolutePath($image_path)); if (!empty($tmp_path) && ( (!empty($image['transparent']) && $image['transparent'] == YesNo::YES) || (!empty($image['icon']['transparent']) && $image['icon']['transparent'] == YesNo::YES) )) { // пересоздание превью — только для прозрачных } } Поскольку признак прозрачности уже доступен в $image['transparent'] (поле transparent в cscart_images), чтение файла для непрозрачных изображений можно не выполнять. Это особенно заметно при включённом lazy_thumbnails: ядро в этом режиме намеренно откладывает работу с файлами, но хук вызывается всегда и читает оригинал на каждое изображение. Предложение — проверять флаг прозрачности до чтения файла: function fn_abt__unitheme2_generate_thumbnail_post($th_filename,$lazy,$image_path,$width,$height,$image){ if ( (empty($image['transparent']) || $image['transparent'] != YesNo::YES) && (empty($image['icon']['transparent']) || $image['icon']['transparent'] != YesNo::YES) ) { return; } list(,,,$tmp_path) = fn_get_image_size(Storage::instance('images')->getAbsolutePath($image_path)); if (!empty($tmp_path)) { // оригинальная логика пересоздания превью для прозрачных } } Логика для прозрачных изображений не меняется, а для остальных пропускается лишнее чтение файла. Просьба рассмотреть возможность включить такую проверку в тему. Спасибо!

Добрый день. Делаем аналитику ГА4 полноценную и она не цепляет вкладки в которых выводятся блоки этого модуля. А они важные. На виду. Добавте плиз хук или может тот экзит лишний и случайно там оказался. Все как обычно проверено кучей изысканий и поиском иных вариантов. но этот самый надежный и феншуйный. Дальше письмо со смыслом. --- Мы используем ваш модуль ab__intelligent_accessories (блоки «Сумісні / Схожі / Похожие товары» на карточке товара) вместе с модулем GA4-аналитики. Зачем пишем. Нам нужно снимать по этим блокам стандартную e-commerce-аналитику Google Analytics 4: view_item_list — показы товаров в блоке (какие сопутствующие товары реально увидел покупатель), select_item — клики по товару из блока. Это наполняет встроенные отчёты GA4 «Список товаров» (Item list), и мы видим, какой из блоков подбора приносит просмотры, клики и в итоге продажи — то есть насколько эффективен ваш модуль в деньгах. Сейчас эти блоки в аналитику не попадают, и мы буквально «слепы» по ним, хотя по категориям/поиску/каруселям всё уже трекается. Техническая причина. Товары вкладки наливаются AJAX-контроллером ab__ia_joins.get_join_products (app/addons/ab__intelligent_accessories/controllers/frontend/ab__ia_joins.php), который завершается через exit; (строка ~89). Из-за exit; обходится штатный механизм пост-контроллеров CS-Cart, и никакой сторонний аддон не может пост-обработать отрендеренный products_scroller (добавить в него разметку для аналитики). Просьба. Добавьте, пожалуйста, точку расширения — хук перед exit;: /** * Fires after the join products scroller is rendered, before the AJAX response is sent. * * @param array $block Block data * @param array $products Products shown in the join tab */ fn_set_hook('ab__ia_joins_get_join_products', $block, $products); exit; (при желании — с guard if (isset($block, $products)) { ... }). Изменение минимальное, логику модуля не меняет — просто даёт штатную точку расширения. Это позволит нам (и другим клиентам) корректно интегрировать аналитику без правок вашего кода. Спасибо!