Короткий ответ
Пороги Core Web Vitals 2026 года: LCP < 2,5 с (скорость появления главного контента), INP < 200 мс (отклик на клик), CLS < 0,1 (насколько «прыгает» вёрстка) — и считают их по данным реальных посетителей, а не по разовому лабораторному тесту. Хорошая новость: для магазина на 1С-Битрикс рецепт известен. Это PHP 8.x с OPcache (кеш кода — сайт не перечитывает свои файлы при каждом заходе), перевод агентов — фоновых заданий Битрикса — на расписание cron, автокеширование и композитный режим: гость получает готовую статичную страницу, и первая загрузка ускоряется в 3–5 раз. Плюс фасетные индексы для умного фильтра, лёгкие картинки в WebP с заданными размерами и отложенные сторонние виджеты.
Базовая оптимизация — кеш, композит, фасеты, чистка агентов и логов — укладывается в 1–2 рабочих дня и не требует переделывать сайт. Дальше идут серверные меры (быстрые NVMe-диски, настройка MySQL, при росте — выделенный сервер) и работа с фронтом: в основном борьба за INP с тяжёлыми скриптами чатов и квизов. И да, скорость — это напрямую про деньги: каждая лишняя секунда LCP съедает конверсию мобильного трафика, а Core Web Vitals — фактор ранжирования в обеих поисковых системах.
«Битрикс тормозит» — пожалуй, самый живучий миф рунета. Правда куда скучнее: тормозит обычно не платформа, а то, как её приготовили — shared-хостинг за триста рублей (один сервер на десятки чужих сайтов), старый PHP 7.4, выключенный композит и три мегабайта чужих виджетов. Мы в Interland поддерживаем сайты на 1С-Битрикс с 2008 года, ускорение — одна из самых частых задач, и диагноз почти всегда одинаковый. Ниже разберём, из чего складывается скорость магазина на Битриксе: что лечится настройкой за день, где понадобится сервер и как всё это связано с метриками, по которым вас оценивают Google, Яндекс и — главное — живые покупатели.
Три метрики: что их ломает в магазине на Битриксе
| Метрика и порог | Что её ломает | Чем лечить |
| LCP < 2,5 с (загрузка главного контента) | Сервер долго «думает» перед ответом (нет кеша и композита, слабый хостинг), огромные фото товаров | Композит, PHP 8 + OPcache, WebP и уменьшение картинок, критический CSS |
| INP < 200 мс (отклик на действия) | Тяжёлые скрипты: чаты, квизы, карты, аналитика — браузер занят ими вместо ваших кликов | Отложенная загрузка виджетов, ревизия скриптов шаблона |
| CLS < 0,1 (стабильность вёрстки) | Картинки и баннеры без заданных размеров, шрифты со «скачком», элементы, появляющиеся внезапно | width/height у изображений, font-display: swap, заранее оставленное место под баннеры |
Важный нюанс: поисковики смотрят полевые данные — статистику CrUX по реальным пользователям за 28 дней, — а не ваш разовый замер. Так что проверяйте PageSpeed Insights по мобильному профилю и смотрите именно блок «Данные реальных пользователей»: лабораторная сотка при красных полевых метриках ничего не стоит.
Слой 1. Сервер: фундамент, который дешевле всего игнорировать
- PHP 8.x + OPcache. Переход с PHP 7.4 на 8.2+ ускоряет работу кода на десятки процентов — по сути бесплатно. OPcache (тот самый кеш кода) обязателен: без него Битрикс заново перечитывает тысячи файлов на каждый заход посетителя.
- Диски и память. NVMe вместо старых HDD и достаточный innodb_buffer_pool для MySQL — база каталога должна жить в быстрой памяти, а не на диске.
- Правильный хостинг. Каталог от 10 000 позиций на shared-тарифе — источник вечных страданий: тесно, как большой семье в однушке. VPS от 4–8 ГБ под магазин — не роскошь, а норма, и требования растут вместе с каталогом. Этот слой мы всегда проверяем первым на технической поддержке.
Слой 2. Битрикс: настройки, которые часто выключены
- Агенты — на cron. Агенты — это фоновые задания, которые Битрикс выполняет сам, как посудомойка, пока вы заняты другим. По умолчанию они запускаются «на хитах» — то есть за счёт времени загрузки страниц у ваших посетителей. Перевод на cron (запуск по расписанию) — полчаса работы и обязательный пункт любого ускорения.
- Автокеширование включено везде. Компоненты каталога без кеша заново ходят в базу при каждом открытии страницы — и делают одну и ту же работу тысячи раз.
- Композитный режим. Гость мгновенно получает готовую статичную страницу, а «живые» части — корзина, избранное — подгружаются фоном: первая загрузка ускоряется в 3–5 раз. Есть тонкость: композиту мешают страницы с GET-параметрами и чрезмерная персонализация, так что настраивать его лучше осмысленно — мы разбирали технологию в отдельной статье.
- Фасетные индексы. Это заранее посчитанные «шпаргалки» для умного фильтра. Без них каждая галочка в фильтре большого каталога — секунды ожидания, с ними — мгновенно. Включаются в настройках инфоблока, пересчитываются индексом.
- Гигиена БД. Логи событий, почтовые события, старые агенты и журналы незаметно разрастаются до гигабайтов и тянут вниз каждый запрос. Чистка по расписанию — обычная часть ухода за сайтом.
- Обмен с 1С — по расписанию и только изменениями. Полная выгрузка каталога в рабочее время кладёт сайт надёжнее любого наплыва покупателей — разбирали в статье про ошибки обмена.
Слой 3. Фронт: где живут INP и CLS
- Изображения. Лёгкие форматы WebP/AVIF, уменьшение под реальный размер вывода (оригинал 4000px в карточке 300px — как диван ради табуретки), ленивая подгрузка ниже первого экрана и заданные width/height. На Битриксе всё это решается штатным ресайзом и модулями конвертации.
- Сторонние виджеты. Чат, квиз, карта, три счётчика аналитики и пиксели вместе легко набирают 2–3 МБ скриптов — и именно они убивают INP. Правило простое: всё, что не нужно на первом экране, загружается позже (по скроллу или первому действию посетителя). И полезно раз в полгода делать ревизию виджетов: половиной маркетинг обычно уже не пользуется.
- Шрифты. Хранить у себя, в современном формате woff2, с font-display: swap — и текст перестанет прыгать при загрузке.
Грабли ускорения
- Композит «включили и забыли». Если страницы сильно различаются для разных посетителей (регион, валюта, персональные цены в шаблоне), кеш композита постоянно сбрасывается — и пользы никакой. Сначала проектирование, потом галочка.
- Погоня за лабораторным баллом вместо полевых данных. Можно вылизать тест до 95, а реальные пользователи на 3G из региона всё равно ждут 6 секунд. Смотрите CrUX — он не льстит.
- Кеш прячет проблему. Медленные запросы под кешем никуда не делись: первый посетитель после сброса кеша получает всё те же 8 секунд. Тяжёлые компоненты стоит чинить, а не только прикрывать кешем.
- Сто модулей Маркетплейса. Каждый модуль — это код на каждом заходе. Неиспользуемые лучше удалять, а не просто выключать.
План ускорения: как это делаем мы
- 1. Замер. PageSpeed (мобильный профиль, полевые данные), монитор производительности Битрикса, медленные запросы MySQL. Фиксируем цифры «до».
- 2. Быстрые победы (1–2 дня). Агенты на cron, автокеш, композит, фасеты, чистка БД, сжатие и уменьшение изображений — обычно этого хватает, чтобы выйти из красной зоны.
- 3. Сервер (если нужен). PHP 8.x, OPcache, настройка MySQL, переезд с shared на VPS.
- 4. Фронт. Отложенные виджеты, шрифты, критический CSS — добиваем INP и CLS.
- 5. Контроль через месяц. Полевые данные обновляются 28 дней, так что финальную оценку смотрим по CrUX, а не назавтра.
Вывод
Скорость магазина на Битриксе — не магия и не повод переписывать сайт: 80% результата дают правильный сервер, включённые штатные механизмы (композит, автокеш, фасеты, агенты на cron) и аккуратность с изображениями и виджетами. А зелёные Core Web Vitals — это позиции выше, реклама дешевле и больше завершённых заказов с того же трафика.
Interland — золотой партнёр 1С-Битрикс в Новосибирске: мы ускоряем магазины в рамках технической поддержки и делаем быстрые интернет-магазины, у которых метрики зелёные с первого дня. Напишите нам в чат — бесплатно замерим ваши Core Web Vitals по полевым данным и честно скажем, какие шаги из этого плана дадут вам максимум эффекта за минимум бюджета.
