Бесконечная прокрутка выглядит красиво и современно: пользователь листает каталог, а товары появляются сами, без кликов по страницам. Но за этой лёгкостью прячется коварная механика: чем дальше проматывает посетитель, тем тяжелее становится страница. Сотни карточек в DOM, десятки запросов к серверу, лагающий скролл на смартфоне — и вот уже «удобный» каталог тормозит и роняет конверсию вместе с позициями в поиске.
Значит ли это, что бесконечную прокрутку нельзя использовать? Нет — её можно сделать быстрой, если понимать, где она бьёт по производительности, и заранее закладывать решения. В этой статье разберём, как реализовать подгрузку каталога на 1С-Битрикс без потери скорости: виртуализация, композитный сайт, кэш, ленивая загрузка и связь с SEO. Комплексно эту работу удобно вести в рамках аудита и оптимизации.
Коротко
- Бесконечная прокрутка удобна для просмотра, но по мере подгрузки раздувает DOM и тормозит на слабых устройствах.
- Без сохранённой пагинации с URL робот может не увидеть весь каталог — SEO страдает.
- Скорость держат виртуализация списка, композитный сайт, кэш умного фильтра и ленивая загрузка изображений.
- Часто оптимален гибрид: кнопка «показать ещё» плюс сохранённые адреса страниц для обхода.
Соблазн бесконечной прокрутки
Бесконечная прокрутка пришла из соцсетей, где лента без конца удерживает внимание. В интернет-магазине её ценят за плавность: пользователь погружается в просмотр, не отвлекаясь на клики по номерам страниц. На мобильных, где кликать по мелкой пагинации неудобно, это ощущается особенно естественно.
Но каталог магазина — не лента соцсети. У посетителя обычно есть цель: найти конкретный товар, сравнить, вернуться к понравившемуся. И здесь бесконечная прокрутка начинает работать против пользователя: невозможно оценить объём, тяжело вернуться к найденному, а страница по мере прокрутки становится всё медленнее. Поэтому решение о бесконечной прокрутке — это всегда компромисс, который нужно принимать осознанно, а не «потому что модно».
Три способа показать длинный каталог
Есть три основных паттерна вывода товаров, и у каждого своя ниша:
| Паттерн | Плюсы | Минусы |
|---|---|---|
| Классическая пагинация | Отличное SEO, возврат к странице, лёгкий DOM | Клики, менее «плавно» |
| Кнопка «показать ещё» | Контроль пользователя, гибрид скорости и удобства | Нужен ручной клик |
| Бесконечная прокрутка | Плавный просмотр, удобно на мобильных | Тяжёлый DOM, риски SEO, возврат к товару |
На практике лучший результат даёт не «чистый» паттерн, а их сочетание: визуальная подгрузка для удобства и сохранённые адреса страниц для робота и возврата. Выбор зависит от аудитории: для просмотрового каталога уместнее подгрузка, для каталога с поиском конкретных позиций — пагинация.
Чем бесконечная прокрутка бьёт по скорости
Главная проблема бесконечной прокрутки — накопление. Каждая подгруженная порция добавляет в страницу новые элементы, и они никуда не деваются:
- Растёт DOM. После сотни товаров в дереве тысячи узлов — браузеру тяжело их пересчитывать и отрисовывать.
- Копятся изображения. Каждая карточка тянет картинку; без ленивой загрузки это мегабайты трафика и памяти.
- Множатся обработчики. События на каждой карточке (наведение, добавление в корзину) накапливаются и нагружают браузер.
- Идут запросы к серверу. Каждая подгрузка — обращение к базе; без кэша это нагрузка на сервер.
Итог — деградация: сначала всё быстро, а после долгой прокрутки скролл начинает дёргаться, особенно на недорогих смартфонах. Именно поэтому нельзя реализовывать бесконечную прокрутку наивно, просто дописывая карточки в конец списка. Нужна дисциплина: виртуализация, кэш, ленивая загрузка. Дисциплину внедрения таких изменений мы описываем в статье про CI/CD и деплой на 1С-Битрикс.
Влияние на SEO и индексацию
Вторая большая проблема — поисковая. Если товары появляются только по скроллу через JavaScript и у них нет доступных ссылок на страницы, поисковый робот рискует не увидеть весь ассортимент. Робот не «прокручивает» страницу как человек — он идёт по ссылкам. Нет ссылок на следующие страницы в HTML — нет обхода дальних товаров.
Решение — держать полноценную пагинацию с URL (?PAGEN_1=2) и ссылками в разметке параллельно с визуальной подгрузкой. Пользователь листает бесконечно, а робот обходит каталог по обычным страницам. Эта связка напрямую пересекается с настройкой индексации каталога — как её выстроить, разбираем отдельно, но принцип один: удобство пользователя не должно закрывать товары от поисковика. Данные о товарах для такой выдачи лучше получать эффективно, о чём мы пишем в материале про D7 и ORM в 1С-Битрикс.
Виртуализация списка
Ключевой приём против раздувания DOM — виртуализация (виртуальный скролл). Суть в том, что в дереве держатся только видимые на экране карточки плюс небольшой запас сверху и снизу, а ушедшие далеко вверх элементы удаляются или заменяются лёгкой заглушкой, сохраняющей высоту.
Благодаря этому DOM не разрастается бесконечно: сколько бы товаров ни подгрузилось, в дереве всегда примерно одинаковое число узлов, и скролл остаётся плавным. Плата за это — усложнение реализации: нужно аккуратно считать высоту элементов, обрабатывать возврат к удалённым карточкам и не допускать «прыжков» контента. Виртуализация оправдана на действительно длинных списках; для коротких каталогов она избыточна.
Композитный сайт и первый экран
Скорость первого экрана — самое важное для восприятия и для метрики LCP. Здесь на 1С-Битрикс работает композитный сайт: статическая часть страницы каталога отдаётся из готового кэша практически мгновенно, ещё до выполнения тяжёлой серверной логики. Пользователь видит товары сразу, а динамические блоки (цена, наличие, состояние корзины) догружаются отдельно.
Бесконечная прокрутка отлично сочетается с композитом: первый экран — из статического кэша, последующие порции — через AJAX. Главное, чтобы AJAX-подгрузка не сводила на нет выигрыш композита тяжёлыми запросами. Композит закрывает старт, а за плавность дальнейшей прокрутки отвечают виртуализация и кэш. Про инфраструктуру, на которой композит работает стабильно под нагрузкой, мы пишем в статье про хостинг и BitrixVM.
Кэш и фасетный индекс при подгрузке
Каждая порция товаров при прокрутке — это запрос к серверу. Если каждый такой запрос заново дёргает базу и пересчитывает выборку, каталог под нагрузкой ляжет. Спасают несколько механизмов 1С-Битрикс:
- Кэш компонента списка товаров. Результаты выборки кэшируются, и повторные запросы отдаются из кэша.
- Фасетный индекс умного фильтра. Когда прокрутка идёт в отфильтрованной выдаче, фасетный индекс отдаёт результат без тяжёлых JOIN.
- Разумный объём порции. Не грузить по одному товару и не грузить по сотне — оптимальный размер порции снижает число запросов без перегруза.
- Тегированный кэш. Кэш сбрасывается точечно при изменении товаров, а не целиком, что держит его актуальным без потери скорости.
Ленивая загрузка изображений
Каталог — это прежде всего изображения товаров, и они же — главный вес страницы. При бесконечной прокрутке грузить все картинки сразу губительно: сотни изображений подгруженных карточек съедят трафик и память. Ленивая загрузка (lazy loading) подгружает изображение только когда оно приближается к области видимости.
Это критично именно для бесконечной прокрутки: пользователь может так и не долистать до дальних карточек, и грузить их картинки заранее — пустая трата ресурсов. В связке с современными форматами изображений (WebP, AVIF) и адаптивными размерами ленивая загрузка становится одним из главных рычагов скорости каталога. Браузеры поддерживают её штатным атрибутом, но при виртуализации логику приходится согласовывать с добавлением и удалением карточек.
Возврат к товару и позиция скролла
Самая раздражающая беда бесконечной прокрутки — потеря места. Пользователь долго листал, открыл товар, нажал «назад» — и оказался в начале списка, потеряв всё, что пролистал. Это прямая потеря конверсии: вернуться к найденному становится мучением, и человек уходит.
Решается сохранением состояния: позиция скролла и набор подгруженных страниц запоминаются (через историю браузера или параметры URL), и при возврате каталог восстанавливает нужное место. Это обязательный элемент, без которого бесконечную прокрутку внедрять не стоит. Если реализовать её без сохранения позиции, «удобный» просмотр обернётся оттоком именно на самом ценном сценарии — когда пользователь уже нашёл интересный товар.
Гибридный подход: кнопка «показать ещё»
Часто оптимальное решение — не чистая бесконечная прокрутка, а гибрид с кнопкой «показать ещё». Пользователь листает, видит порцию товаров и сам решает, подгружать ли дальше, нажав кнопку. Это даёт несколько преимуществ:
- Контроль пользователя. Человек управляет подгрузкой, а не «проваливается» в бесконечность.
- Доступ к футеру. При чистой бесконечной прокрутке футер недостижим — при кнопке он доступен.
- Мягче для DOM. Подгрузка происходит по клику, а не непрерывно, проще контролировать вес страницы.
- Совместимо с SEO. Кнопка легко сочетается с сохранёнными адресами страниц для робота.
Кнопка «показать ещё» — золотая середина между удобством подгрузки и контролем над скоростью и индексацией. Именно её мы чаще всего рекомендуем для каталогов на 1С-Битрикс.
Реализация на 1С-Битрикс
Собрать быструю подгрузку каталога можно по такой последовательности:
- Выберите паттерн под аудиторию. Просмотровый каталог — подгрузка/кнопка; каталог с поиском позиций — пагинация.
- Сохраните пагинацию с URL. Полноценные адреса страниц и ссылки в HTML для обхода роботом.
- Включите композит. Первый экран каталога — из статического кэша композитного сайта.
- Настройте кэш подгрузки. AJAX за следующей порцией идёт через кэш и фасетный индекс, а не в обход.
- Добавьте ленивую загрузку. Изображения грузятся по мере приближения к экрану, в современных форматах.
- Сохраните позицию. При возврате из карточки каталог восстанавливает место прокрутки.
- Профилируйте на слабых устройствах. Проверьте память, частоту кадров и Core Web Vitals на недорогих смартфонах.
Частые ошибки
- Наивная подгрузка. Карточки просто дописываются в конец, DOM растёт бесконечно, скролл лагает.
- Нет пагинации для робота. Товары только по скроллу, часть каталога не индексируется.
- Подгрузка в обход кэша. Каждый AJAX заново считает фильтр и выборку, сервер под нагрузкой ложится.
- Все картинки сразу. Нет ленивой загрузки — сотни изображений съедают трафик и память.
- Потеря позиции. Возврат из товара кидает в начало списка, пользователь уходит.
- Недостижимый футер. Чистая бесконечная прокрутка прячет важные ссылки в подвале.
- Проверка только на мощном ПК. На компьютере разработчика всё летает, а на смартфоне тормозит.
Чек-лист внедрения
- Паттерн выбран осознанно. Под аудиторию и сценарий, а не «потому что модно».
- SEO защищено. Сохранены адреса страниц и ссылки в HTML для обхода.
- DOM под контролем. На длинных списках работает виртуализация или кнопка «показать ещё».
- Композит и кэш. Первый экран из кэша, подгрузка через фасетный индекс и кэш.
- Ленивая загрузка. Изображения грузятся по мере необходимости, в современных форматах.
- Позиция сохраняется. Возврат из карточки восстанавливает место прокрутки.
- Проверено на мобильных. Core Web Vitals и плавность скролла на недорогих смартфонах в норме.
Вывод
Бесконечная прокрутка — не зло и не панацея, а инструмент со своими издержками. Её главная опасность в том, что она незаметно деградирует: сначала всё быстро, а после долгой прокрутки DOM раздувается, скролл лагает, а часть товаров рискует выпасть из индекса. Реализованная наивно, она убивает и скорость, и SEO.
Чтобы этого не случилось, закладывайте решения заранее: сохраняйте пагинацию с URL для робота, используйте композит и кэш для скорости, виртуализацию и ленивую загрузку против раздувания, а позицию скролла — ради возврата к товару. А во многих случаях лучший ответ — гибрид с кнопкой «показать ещё», который даёт удобство подгрузки без потери контроля над скоростью и индексацией.
