v1.3.5 обновление от 30-Окт-2025

[ab.support.serhii]

Дорогие друзья, сегодня мы выпустили релиз обновления:

Preload (Предварительная загрузка) v1.3.5 от 30-Окт-2025

Новые возможности и улучшения:
[+] Добавлена совместимость с CS-Cart 4.19.1.

Обновления доступны всем пользователям с активной подпиской, производятся через Центр обновлений CS-Cart.

Хотите, мы оповестим Вас о следующем обновлении? Подпишитесь на наши каналы для анонсов:
– Telegram
– WhatsApp
– YouTube

[a.stepanovna]

Почему в случае использования вот такого вывода изображений в карточке товара в секцию preload не попадает второе изображение.  Вот с июня 2025 года ждем https://community.abt.team/topic/786-v134-obnovlenie-ot-22-noja-2023/#findComment-14194

Изменено 30 Марта, 2026 в 16:17 пользователем a.stepanovna

[a.stepanovna]

Должны ли на главнйо странице попадать в прелоад баннеры? Сейачс не попадает ни один

https://stile.me/

[ab.support.serhii]

В 30.03.2026 в 18:22, a.stepanovna сказал:

Почему в случае использования вот такого вывода изображений в карточке товара в секцию preload не попадает второе изображение.

По той же ссылке есть и ответ на этот вопрос.

Ещё не реализовали такую возможность специально для "Каскадной галереи".

[ab.support.serhii]

В 30.03.2026 в 18:59, a.stepanovna сказал:

Должны ли на главнйо странице попадать в прелоад баннеры? Сейачс не попадает ни один

Нет смысла дублировать на форум то, что вы уже обсуждаете в тикете.

[a.stepanovna]

А когда при таком отображении карточки товара в preload будут попадать оба изображения которые видно при первоначальной загрузке?

 

[ab.support.serhii]

@a.stepanovna релиз модуля с этой задачей ещё не брался в работу.

[a.stepanovna]

@ab.support.serhii Критично же, нет?

[andreyandreenko]

Как настроить чтобы работала предзагрузка изображений первых 4-х товаров?

Проверено на вашем демо https://abd-f94e56797c.demos.abt.team/ru/odezhda/

частб окна браузера уменьшал, не помогает

Изменено 6 Июля, 2026 в 14:16 пользователем andreyandreenko

[ab.support.serhii]

@andreyandreenko в ближайшем обновлении модуля должно быть исправлено.

[AndreyJ]

 

 

Приветсвую.

Изучите плиз на сколько Клавдия Антроповна говорит по дело.

Я со своей стороны тесты погонял, замеры поделал. Вроде не вреть.

 

Это и баг т.к. не работает и предложение как решить.

Оно конечно только в связки с ядром сработает. 

Надеюсь вы со своей стороны простимулируете команду Карта к фиксу.

Ну а если нет, то предлагаю добавить этот фикс к вам и информацию в справку модуля, как у вас сделано с модулем Мтеатегов например.

Я им тоже написаль.

Спойлер

 https://forum.cs-cart.ru/t/tygh-less-parseurls-dobavlyaet-k-assetam-v-url-kompajl-tajm-time-rassinhron-odinakovyh-shriftov-kartinok-mezhdu-skompilirovannymi-fajlami-stilej/27380?u=andreyj

 

 

 

 

Тема: прелоад шрифтов промахивается мимо 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 во всех скомпилированных файлах стилей.

[ab.support.serhii]

@AndreyJ записал, разработчик изучит это предложение при случае.

[a.stepanovna]

@AndreyJ Мы такое часто ловим, тоже бесит вот уже много лет. Иногда после некоторых очисток кэшей нормально работает

[AndreyJ]

Снова приветствую.

Тут еще в борьбе с гуглпейджспидом и дерганьем при загрузке нашли момент важный.

 

---

 

Тема: в нативном режиме 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-режиме рендер идентичен прежнему.

[AndreyJ]

Небольшое уточнение к моему посту выше — про флаг lazy_load_disabled.

Я назвал его «мёртвым кодом», но, разобравшись глубже, это неточно: правильнее — незавершённая заготовка ровно под эту задачу. Само имя выдаёт замысел: пометить картинку как «ленивую загрузку отключили». Уточняю, почему в текущем виде оно не работает — это подсказывает, где механизм не был доведён.

Единственное присваивание — в хуке ab__preload hooks/common/image.pre.tpl:

{if $restore}
    {$image_additional_attrs['lazy_load_disabled'] = true scope="parent"}
    {$restore = false}
{/if}

1. Ставится только в JS-режиме ($restore = true лишь когда на входе $lazy_load == true). В нативном режиме, где и возникает проблема с loading="lazy", флаг не выставляется вовсе.
2. Потребитель не реализован. Значение нигде не читается: шифрованных файлов в ab__preload/ab__lazy_load нет, lazysizes 5.3.2 такого атрибута не знает, func.js ab__lazy_load его не проверяет, PHP тоже.
3. И не может быть прочитан ab__lazy_load из-за порядка хуков — он выполняется раньше ab__preload (priority 190000 против 200000), поэтому на момент его работы флага ещё нет.
4. Побочный эффект: render_tag_attrs булев true выводит как голый атрибут, поэтому в JS-режиме флаг протекает в разметку — <img … lazy_load_disabled> (невалидный атрибут, браузер игнорирует).

Вывод: проще всего закрыть задачу форсированием loading="eager" в ab__preload (как в предложении выше) — это покрывает оба режима и не зависит от порядка хуков, а присваивание lazy_load_disabled тогда можно убрать (заодно уйдёт мусорный атрибут в JS-режиме). Если же сигнальную модель хочется сохранить, её придётся переносить: сигнал должен выставляться до работы ab__lazy_load, и на его стороне нужен читатель.