Скорость каталога: ленивая загрузка и подгрузка

Большой каталог — это всегда компромисс между «показать всё» и «показать быстро». Пока в разделе полсотни товаров, страница летает. Но стоит вывести на экран сетку из тридцати карточек с картинками, ценами, лейблами и кнопками, а под капотом иметь каталог на десятки тысяч позиций — и первая загрузка растягивается на секунды. Посетитель видит белый экран, скачущую вёрстку и «думающие» картинки, теряет терпение и уходит к конкуренту, у которого каталог открывается мгновенно.

Хорошая новость в том, что скорость каталога в 1С-Битрикс — это набор понятных, решаемых задач: ленивая загрузка изображений, продуманная подгрузка товаров, правильное кэширование и композитная отдача статики. Причём всё это можно внедрить без потери SEO, если аккуратно сохранить индексируемые ссылки и canonical. Ниже — практический разбор из наших проектов по ускорению сайтов на 1С-Битрикс: что именно тормозит каталог, чем это лечить и как замерить результат.

Почему скорость каталога — это деньги

Каталог — самая посещаемая и самая нагруженная часть интернет-магазина. Через него проходит основной трафик из поиска и рекламы, на нём принимается решение «смотреть дальше или уйти», и именно он чаще всего упирается в производительность из-за большого числа товаров и изображений. Поэтому даже небольшое ускорение каталога напрямую отражается на выручке.

Связь скорости и денег не абстрактная, а вполне измеримая. Медленная страница бьёт по бизнесу сразу с нескольких сторон:

• Отказы. Чем дольше грузится первый экран, тем больше людей закрывают вкладку, не дождавшись каталога. Потерянный на загрузке посетитель — это несостоявшийся заказ.
• Конверсия. Даже те, кто дождался, на медленном сайте кликают неохотнее: каждый переход между страницами каталога стоит им ожидания.
• Ранжирование. Скорость и стабильность вёрстки (Core Web Vitals) — сигнал для поисковых систем. Медленный каталог хуже ранжируется, а значит, получает меньше органического трафика.
• Стоимость трафика. Если каталог медленный, часть оплаченных рекламных кликов уходит в отказы. Вы платите за визиты, которые не превращаются в просмотры товаров.

Отдельно стоит различать реальную и воспринимаемую скорость. Реальная — это сколько миллисекунд сервер и браузер тратят на подготовку страницы. Воспринимаемая — насколько быстро пользователю кажется, что сайт «ожил»: появился контент, перестала прыгать вёрстка, картинки встали на места. Часто выгоднее вложиться именно в воспринимаемую скорость: отдать структуру страницы мгновенно, а тяжёлые картинки и дальние товары догрузить позже. Именно на этом строятся ленивая загрузка и композит, которые мы разберём ниже.

Из чего складывается медленный каталог

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

• Время ответа сервера (TTFB). Сколько бэкенд собирает HTML: запросы к базе за товарами, ценами, остатками, свойствами, сборка шаблона. На большом каталоге без кэша это самое дорогое место.
• Вес и число картинок. Сетка из десятков товаров тянет за собой десятки изображений. Если они тяжёлые и грузятся все сразу, браузер захлёбывается ещё до того, как покажет первый экран.
• JavaScript и CSS. Тяжёлые скрипты фильтра, слайдеров, аналитики блокируют отрисовку и «съедают» отзывчивость интерфейса.
• Объём разметки. Если в HTML сразу выводятся все товары раздела, а не первая порция, документ раздувается и дольше парсится.
• Отсутствие кэша. Когда каждый запрос пересобирает список товаров из базы, сервер работает вхолостую на одинаковых данных.

Смысл дальнейших разделов — разобрать каждое слагаемое отдельно. Картинки лечим ленивой загрузкой и оптимизацией форматов, объём разметки — подгрузкой товаров порциями, время ответа сервера — кэшированием и композитом. А чтобы понять, какое слагаемое у вас самое тяжёлое, в конце будет раздел про диагностику и метрики.

Ленивая загрузка картинок

Изображения — самый тяжёлый по весу тип контента в каталоге. На странице раздела их легко набирается три-четыре десятка, и если браузер начинает качать их все сразу, канал забивается, а первый экран ждёт, пока догрузятся даже те картинки, которые находятся далеко внизу и пользователь их, возможно, вообще не увидит. Ленивая загрузка решает ровно эту проблему: картинка скачивается только тогда, когда приближается к области видимости.

В 1С-Битрикс ленивую загрузку можно организовать двумя основными способами, и лучше использовать их вместе.

• Нативный атрибут loading="lazy". Самый простой и надёжный вариант: добавляете атрибут к тегам <img> в шаблоне карточки товара, и браузер сам откладывает загрузку внеэкранных изображений. Поддерживается всеми современными браузерами и не требует ни строчки JavaScript.
• IntersectionObserver. Скриптовый подход, когда реальный адрес картинки хранится в атрибуте data-src, а в src стоит лёгкая заглушка. Как только элемент попадает в зону наблюдения, скрипт подставляет настоящий адрес. Даёт больше контроля: можно задать отступ предзагрузки, показать плейсхолдер, плавно проявить картинку.

У ленивой загрузки есть важный нюанс, который часто ломает вёрстку, — сдвиг макета. Пока картинка не загрузилась, браузер не знает её размеров и отдаёт ей нулевую высоту. Когда изображение приходит, оно «раздвигает» соседние элементы, страница дёргается, а метрика CLS (сдвиг макета) портится. Лечится это просто: у каждого <img> должны быть заданы атрибуты width и height (или соотношение сторон через CSS aspect-ratio), чтобы место под картинку резервировалось заранее.

Ещё одна частая ошибка — вешать ленивую загрузку вообще на всё подряд, включая иконки, логотипы и мелкую графику интерфейса. Смысла в этом нет: такие элементы весят копейки, зато лишний JavaScript-наблюдатель на каждую иконку только нагружает страницу. Ленивая загрузка оправдана для тяжёлых контентных изображений — фотографий товаров, баннеров, превью, — а не для интерфейсной мелочи.

Оптимизация самих изображений: WebP, srcset, размеры

Ленивая загрузка откладывает скачивание картинок, но не делает их легче. Второй фронт работ — сами файлы: их формат, размер и способ доставки. Здесь скрыт огромный резерв, потому что в магазинах часто отдают исходные фотографии на несколько мегабайт там, где хватило бы сотни килобайт.

Три главных рычага оптимизации изображений:

• Современные форматы. WebP и AVIF при том же визуальном качестве весят заметно меньше, чем JPEG и особенно PNG. Перевод каталога на WebP — часто самый быстрый способ уполовинить вес картинок.
• Адаптивные размеры. Нет смысла отдавать на мобильный экран картинку шириной 1200 пикселей. Через атрибуты srcset и sizes вы готовите несколько версий изображения, а браузер сам выбирает подходящую под плотность и ширину экрана.
• Правильные миниатюры. В карточке каталога должна стоять именно миниатюра нужного размера, а не полноразмерное фото, ужатое стилями. В 1С-Битрикс превью генерируются через CFile::ResizeImageGet с нужными размерами и качеством.

Отдельная тема — доставка статики. Даже лёгкие картинки загружаются медленно, если сервер отдаёт их по одному соединению с того же домена, что и HTML. Вынос изображений и другой статики на CDN или отдельный домен без cookies разгружает основной сервер и приближает файлы к пользователю географически. Для большого каталога с миллионами обращений к картинкам это ощутимая разница.

Подгрузка товаров: «показать ещё» и прокрутка

Второй тяжёлый фактор после картинок — объём разметки. Если в HTML сразу выводятся все товары раздела, документ раздувается, дольше парсится и держит в памяти сотни карточек, которые пользователь, может, и не пролистает. Решение — отдавать товары порциями: первую страницу сразу, а следующие подгружать по мере необходимости.

Есть три типовых сценария, и у каждого свой баланс UX и нагрузки:

• Классическая пагинация. Товары разбиты на страницы, переход — по ссылкам «1, 2, 3…». Прозрачно для поисковика, но требует перезагрузки страницы и лишних кликов от пользователя.
• Кнопка «показать ещё». Первая порция грузится сразу, следующие подгружаются через AJAX по клику. Пользователь контролирует процесс, подвал сайта остаётся доступным.
• Бесконечная прокрутка. Новые товары подгружаются автоматически, когда пользователь докручивает до низа. Максимально «бесшовно», но мешает добраться до футера и требует аккуратной работы с SEO и производительностью.

На практике для большинства магазинов лучший вариант — гибрид: первая страница отдаётся сразу в HTML, дальше работает «показать ещё» (иногда с автоподгрузкой первых одной-двух порций), а под всем этим сохраняются настоящие ссылки пагинации для поисковика. Так вы получаете и лёгкий первый экран, и удобство подгрузки, и индексацию. Подробнее выбор между пагинацией и прокруткой с точки зрения поиска мы разбирали в отдельном материале про пагинацию и бесконечную прокрутку каталога.

Технически подгрузка в 1С-Битрикс делается на штатных механизмах компонента bitrix:catalog.section: он умеет отдавать очередную страницу списка по AJAX. Скрипт запрашивает следующую порцию по адресу с номером страницы, получает готовый HTML карточек и дописывает их в конец сетки. Важно, что порцию собирает тот же кэшируемый компонент, поэтому подгрузка остаётся быстрой и не бьёт по базе на каждый запрос.

Как не потерять SEO при подгрузке

Главная опасность любой AJAX-подгрузки — сделать товары невидимыми для поисковика. Робот в общем случае не выполняет пользовательские сценарии прокрутки и клики по «показать ещё». Он видит то, что пришло в исходном HTML, и переходит по обычным ссылкам. Если навигация построена только на бесконечной прокрутке, товары на дальних «страницах» просто не попадут в индекс — робот до них не доберётся.

Чтобы совместить быструю подгрузку и индексацию, придерживайтесь нескольких правил:

• Сохраняйте настоящие ссылки пагинации. Даже если визуально работает «показать ещё» или прокрутка, в разметке должны оставаться ЧПУ-ссылки на страницы каталога (/catalog/razdel/?PAGEN_1=2 или чистые ЧПУ вида /catalog/razdel/page-2/). Их можно скрыть от глаз, но не от робота.
• Отдавайте первую страницу в HTML. Первая порция товаров должна приходить в исходном коде, а не догружаться скриптом. Это и для пользователя быстрее, и для индексации надёжнее.
• Настройте canonical. Страницы пагинации указывают canonical на себя (не на первую страницу), чтобы каждая была самостоятельной единицей индекса, а служебные параметры сортировки канонизируются на чистый URL.
• Не плодите дубли. Один и тот же набор товаров не должен быть доступен по нескольким адресам с разным порядком параметров — нормализуйте URL.

Правильный подход к подгрузке — это «прогрессивное улучшение»: сначала делаем страницу, которая полностью работает на обычных ссылках и видна роботу, и только поверх этого добавляем скриптовую подгрузку для живого пользователя. Тогда быстрый интерфейс не конфликтует с индексацией, а поисковик обходит весь каталог по нормальным ЧПУ-ссылкам. Вопросы дублей и краулингового бюджета на большом каталоге тесно связаны с этой темой, и их стоит проектировать заодно.

Кэширование каталога в 1С-Битрикс

Ленивая загрузка и подгрузка облегчают браузер, но не трогают самое дорогое на большом каталоге — время, которое сервер тратит на сборку HTML из базы. Каждый запрос без кэша заставляет платформу заново читать товары, цены, остатки и свойства, прогонять их через шаблон и отдавать результат. Кэширование убирает эту работу, отдавая уже готовый результат.

В 1С-Битрикс есть несколько уровней кэша, и важно понимать, за что отвечает каждый.

Для каталога ключевой — управляемый кэш с автоматической очисткой по тегам. Его прелесть в том, что он снимает вечный компромисс «быстро, но неактуально». Компонент помечает свой кэш тегами инфоблока, и когда любой товар раздела меняется (правка в админке, обмен с 1С через события), система сама сбрасывает именно затронутый кэш. Пользователь всегда видит свежие данные, но подавляющее большинство запросов обслуживается из кэша.

Типичная ошибка — выставить тип кэширования компонента в «Не кэшировать» на время отладки и забыть вернуть обратно. Внешне сайт работает, но каждый заход в каталог пересобирает список из базы. Под нагрузкой это первое, что кладёт сервер. Перед выкладкой всегда проверяйте, что у компонентов каталога стоит кэш «Авто» и включён управляемый кэш в настройках главного модуля.

Композитный сайт: статика мгновенно

Композитная технология — отдельный и очень мощный инструмент ускорения, который логично завершает тему кэша. Идея в том, чтобы разделить страницу на две части: статическую, одинаковую для всех, и динамическую, персональную для каждого пользователя. Статическую часть Битрикс сохраняет целиком и отдаёт почти мгновенно, минуя тяжёлую сборку PHP, а динамику (корзину, авторизацию, «вы недавно смотрели») догружает отдельным запросом уже после показа страницы.

Для каталога это идеальный сценарий: сетка товаров, фильтр, описание раздела одинаковы для всех посетителей и прекрасно отдаются из композитного кэша. Пользователь видит структуру и товары почти сразу, а персональные блоки подтягиваются доли секунды спустя. Именно так резко улучшается воспринимаемая скорость и метрика LCP — первый значимый контент появляется без ожидания серверной сборки.

Главный страх при внедрении композита — «сломается корзина». На деле он не ломается, если правильно разметить динамические области. Всё персональное — счётчик корзины, блок авторизации, региональные цены — выносится в динамические зоны, которые обновляются после отдачи статики. В статику попадает только то, что одинаково для всех. Как устроен композит, что выносить в динамику и как не сломать корзину и авторизацию, мы подробно разобрали в отдельной статье про композитный сайт в 1С-Битрикс.

• В статику — сетка товаров, фильтр, тексты и SEO-блоки раздела, навигация.
• В динамику — корзина и её счётчик, блок авторизации, персональные цены и скидки, «недавно просмотренные».
• Никогда не кэшируйте персональные данные в статике — это прямой путь показать одному пользователю корзину другого.

Реализация в 1С-Битрикс пошагово

Сведём всё в практический порядок внедрения. Ниже — последовательность работ, которая закрывает и картинки, и подгрузку, и серверный кэш.

1. Включите ленивую загрузку картинок. В шаблоне карточки товара добавьте loading="lazy" ко всем изображениям, кроме первого экрана, и обязательно проставьте width/height, чтобы не поймать сдвиг макета.
2. Оптимизируйте изображения. Настройте генерацию миниатюр нужных размеров через CFile::ResizeImageGet, переведите отдачу на WebP, подключите srcset/sizes для адаптивных размеров.
3. Настройте подгрузку товаров. В параметрах компонента bitrix:catalog.section включите AJAX-подгрузку и режим «показать ещё», сохранив при этом стандартную постраничную навигацию в разметке.
4. Проверьте SEO подгрузки. Убедитесь, что первая страница приходит в HTML, ссылки пагинации остаются в коде, а canonical проставлены корректно.
5. Включите кэш компонентов. Для всех компонентов каталога выставьте тип кэша «Авто» и включите управляемый кэш в настройках главного модуля, чтобы сброс шёл по тегам.
6. Активируйте композит. Включите композитный режим, разметьте динамические области (корзина, авторизация, персональные блоки) и проверьте, что персональные данные не попадают в статику.
7. Вынесите статику на CDN. Настройте отдачу картинок, CSS и JS с отдельного домена или CDN с длинными заголовками кэша браузера.
8. Замерьте результат. Прогоните каталог через инструменты измерения Core Web Vitals до и после, зафиксируйте LCP, INP, CLS и время ответа сервера.

Как это выглядит в админке

Основные рычаги ускорения каталога живут в параметрах компонентов и в настройках производительности главного модуля. Схематично панель настроек кэша и подгрузки компонента catalog.section выглядит так:

Настройки производительности главного модуля дополняют картину: там включается композитный режим, управляемый кэш, сжатие статики и мониторинг скорости. Полезно держать в голове, что эти уровни работают в связке — композит опирается на кэш компонентов, а тот, в свою очередь, гасится по тегам при обмене с 1С. Если хоть одно звено отключено, ускорение получается частичным.

Метрики и Core Web Vitals

«Каталог стал быстрее» — субъективное ощущение до тех пор, пока вы не начали измерять. Чтобы управлять скоростью, нужны конкретные метрики. Основной ориентир сегодня — Core Web Vitals, набор показателей, которые отражают реальный пользовательский опыт и учитываются поисковыми системами.

Важно смотреть на метрики именно на странице каталога, а не на главной или в статье блога — нагрузка и структура у них разные. Полезно замерять в двух режимах: «лабораторно» (синтетический прогон в инструменте вроде PageSpeed или Lighthouse) и «полевым» способом — по данным реальных пользователей. Лаборатория показывает потолок и помогает искать узкие места, полевые данные — что на самом деле чувствуют посетители на своих устройствах и сетях.

Наши приёмы напрямую бьют по этим метрикам: ленивая загрузка и оптимизация картинок улучшают LCP и снижают вес, зарезервированные размеры изображений держат CLS, композит и кэш срезают TTFB, а лёгкая начальная разметка помогает INP. Поэтому после каждого шага внедрения имеет смысл переснимать метрики — так видно вклад конкретной оптимизации.

Диагностика: где именно тормозит

Прежде чем что-то ускорять, полезно точно понять, что именно тормозит, — иначе легко потратить силы не на то узкое место. Диагностика каталога сводится к нескольким шагам.

1. Разделите бэкенд и фронтенд. Посмотрите TTFB (время ответа сервера) и общее время загрузки. Большой TTFB — проблема на сервере (нет кэша, тяжёлые запросы). Маленький TTFB при медленной странице — узкое место в картинках, скриптах и вёрстке.
2. Профилируйте бэкенд. Включите отладочную панель или профилировщик Битрикса и посмотрите число и время SQL-запросов при загрузке каталога. Десятки тяжёлых запросов — признак того, что кэш не работает.
3. Разберите загрузку в браузере. На вкладке «Сеть» инструментов разработчика отсортируйте ресурсы по весу. Обычно верх списка занимают картинки — это подсказка, где оптимизировать.
4. Проверьте метрики. Прогоните страницу через Lighthouse и посмотрите на подсказки по LCP, CLS и «неиспользуемому» коду.
5. Сверьтесь с полевыми данными. Загляните в отчёт по Core Web Vitals в панели вебмастера — он показывает, как каталог ведёт себя у реальных пользователей.

Такая диагностика почти всегда даёт ясную картину: либо сервер долго думает (лечим кэшем и композитом), либо браузер захлёбывается картинками (лечим ленивой загрузкой и WebP), либо страница раздута всеми товарами сразу (лечим подгрузкой). Действуйте по фактам, а не по догадкам — так ускорение получается предсказуемым.

Частые ошибки

• Включили ленивую загрузку на всё, включая «геройскую» картинку первого экрана, — и ухудшили LCP вместо того, чтобы улучшить.
• Не проставили width/height у картинок — ленивая загрузка вызывает сдвиг макета и портит CLS.
• Отдают в карточке полноразмерные фото, ужатые стилями, вместо лёгких миниатюр — вес сетки товаров зашкаливает.
• Построили навигацию только на бесконечной прокрутке без ссылок пагинации — робот не добирается до дальних товаров, часть каталога выпадает из индекса.
• Отключили кэш компонентов «на время отладки» и забыли вернуть — каждый заход в каталог пересобирает список из базы.
• Включили композит, но не разметили динамику — рискуют показать корзину или региональные цены одного пользователя другому.
• Оптимизировали только фронтенд, оставив тяжёлые SQL-запросы, — TTFB так и остался высоким, а «зелёный» Lighthouse обманул.
• Внедрили ускорение, но не замерили метрики до и после — невозможно доказать эффект и понять, что именно сработало.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность каталога к запуску:

1. Картинки ленивые и с размерами. Внеэкранные изображения грузятся лениво, у всех проставлены width/height, картинка первого экрана грузится приоритетно.
2. Изображения оптимизированы. Каталог отдаёт WebP, миниатюры нужных размеров генерируются через ResizeImageGet, подключены srcset/sizes.
3. Подгрузка настроена. Работает «показать ещё» или прокрутка, первая страница приходит в HTML, ссылки пагинации сохранены.
4. SEO подгрузки проверено. Без JavaScript видны товары и ссылки на страницы, canonical корректны, дублей по параметрам нет.
5. Кэш включён. Тип кэша компонентов — «Авто», управляемый кэш активен, сброс идёт по тегам инфоблока.
6. Композит работает. Статика отдаётся мгновенно, динамика (корзина, авторизация) размечена и догружается, персональные данные не в статике.
7. Статика на CDN. Картинки, CSS и JS отдаются с отдельного домена или CDN с длинными заголовками кэша.
8. Метрики зафиксированы. Замерены LCP, INP, CLS и TTFB до и после, результат подтверждён полевыми данными.

Скорость и стабильность каталога тесно связаны с фильтрацией и SEO-структурой раздела: быстрый фильтр без лишних запросов и грамотная пагинация усиливают эффект от ускорения. Если хотите копнуть в эту сторону, посмотрите наши материалы про умный фильтр в 1С-Битрикс и про пагинацию и бесконечную прокрутку каталога — они хорошо дополняют эту статью.

Вывод

Быстрый каталог в 1С-Битрикс собирается из нескольких слоёв: лёгкая начальная загрузка за счёт ленивых и оптимизированных картинок, подгрузка товаров порциями поверх индексируемой пагинации, кэш компонентов с очисткой по тегам и композит, отдающий статику мгновенно. Ни один слой не работает в одиночку, но вместе они уводят LCP и TTFB в «зелёную» зону даже на каталоге в десятки тысяч позиций — и всё это без потери SEO. Главное правило: сначала измерьте, потом ускоряйте, а после каждого шага переснимайте метрики, чтобы видеть реальный вклад.