Медленный магазин теряет деньги дважды: посетители уходят, не дождавшись загрузки, а поисковик понижает позиции за плохие Core Web Vitals. На 1С-Битрикс это особенно заметно — платформа мощная, но требовательная: без грамотного кэша, настроенной базы и композита даже хороший сервер отдаёт страницы медленно. Хорошая новость в том, что у Битрикса есть сильные штатные инструменты ускорения, и большинство проблем решаемо без переписывания сайта.
Это практический чек-лист ускорения магазина на 1С-Битрикс: композит, кэширование, memcached, оптимизация MySQL и индексов, фронтенд и Core Web Vitals. Системное ускорение под нагрузку — часть аудита и оптимизации 1С-Битрикс, но пройти по чек-листу и снять быстрые улучшения можно и своими силами.
Коротко
- Сначала измерьте узкое место (база, PHP, фронтенд), потом оптимизируйте — не наоборот.
- Композитный сайт + memcached — самая сильная связка ускорения на Битрикс.
- Основной резерв часто в базе: индексы под свойства, буферный пул InnoDB, разбор медленных запросов.
- Скорость влияет и на SEO (Core Web Vitals), и на конверсию — это деньги, а не техническая роскошь.
Почему скорость — это деньги
Скорость витрины напрямую конвертируется в выручку по двум каналам. Первый — поведение: чем дольше грузится страница, тем больше посетителей уходит, не дождавшись, и тем ниже конверсия. Второй — SEO: Core Web Vitals входят в факторы ранжирования, и медленный сайт теряет позиции, а с ними — трафик.
Для магазина это двойной удар: одновременно падают и продажи с текущего трафика, и сам трафик из поиска. Поэтому ускорение — не «вылизывание ради цифр в тесте», а прямая работа с деньгами. И на 1С-Битрикс резервы обычно большие, потому что штатные инструменты часто недонастроены.
Сначала измерить, потом ускорять
Главная ошибка — оптимизировать вслепую. Прежде чем что-то менять, снимите метрики и найдите реальное узкое место.
- Панель разработчика Битрикса. Время генерации страницы, число запросов к базе, время SQL — прямо в интерфейсе.
- Медленные SQL-запросы. Лог медленных запросов MySQL показывает, что именно тормозит базу.
- Core Web Vitals. LCP, INP, CLS — как страница ведёт себя у реального пользователя.
- Время ответа сервера (TTFB). Насколько быстро сервер вообще начинает отдавать страницу.
Композитный сайт
Композитный сайт — один из самых мощных инструментов ускорения на Битрикс. Он делит страницу на две части: статическую (шапка, каркас, большая часть контента), которая отдаётся почти как готовый HTML из кэша, и динамическую (корзина, авторизация, цена клиента), которая догружается отдельным лёгким запросом.
Эффект — резкое падение времени до отображения контента и снижение нагрузки на сервер, особенно на каталоге и карточках товара. Динамические блоки при этом остаются актуальными, потому что подгружаются отдельно. Композит опирается на быстрое хранилище кэша — поэтому его связывают с memcached. Подробнее о том, как включить композит и push в окружении, — в контексте настройки сервера, где всё это конфигурируется.
Многоуровневое кэширование
Помимо композита, Битрикс даёт несколько уровней кэша, и их нужно использовать все.
| Уровень | Что кэширует | Эффект |
|---|---|---|
| Кэш компонентов | Вывод каталога, меню, блоков | Меньше запросов к базе |
| Тегированный кэш | Данные с зависимостями | Сброс только изменённого |
| Композитный сайт | Статику страницы | Мгновенная отдача каркаса |
| Кэш меню и инфоблоков | Структуру и элементы | Разгрузка навигации |
| Управляемый кэш | Автосброс по событиям | Актуальность без ручной чистки |
Особенно важен тегированный кэш: он позволяет сбрасывать не весь кэш каталога при обмене с 1С, а только реально изменившиеся товары. Это держит витрину и быстрой, и актуальной.
memcached и сессии в памяти
Файловый кэш упирается в скорость диска и на высокой нагрузке порождает массу операций ввода-вывода. Решение — держать кэш и сессии в оперативной памяти через memcached.
- Кэш в памяти. memcached отдаёт данные быстрее диска и разгружает файловую систему.
- Сессии в памяти. Хранение сессий в memcached снимает нагрузку с диска и базы.
- Стабильность под нагрузкой. В пик (акции, рассылки) память держит нагрузку лучше диска.
- Связка с композитом. Композитный кэш эффективен именно поверх memcached.
memcached включается на уровне окружения BitrixVM и подключается в настройках Битрикса. Это одна из самых недооценённых, но действенных мер.
Оптимизация MySQL и индексов
Часто главное узкое место магазина — база данных. Каталог, умный фильтр и обмен с 1С генерируют тяжёлые запросы, и без правильных индексов они сканируют таблицы целиком.
- Включите лог медленных запросов. Найдите топ запросов, съедающих время — обычно их немного.
- Проверьте индексы. Выборки по свойствам, разделам и фильтру должны опираться на индексы, а не на полный скан.
- Настройте буферный пул InnoDB. Отдайте под него значимую часть ОЗУ, чтобы «горячие» данные жили в памяти.
- Оптимизируйте кастомный код. Замените неэффективные выборки на грамотные запросы.
Современный способ писать быстрые выборки в Битрикс — через ORM. Как это устроено, мы разбираем в статье про D7 ORM в Битрикс: правильные запросы через ядро D7 снимают часть нагрузки с базы и легче кэшируются.
Ускорение каталога и умного фильтра
Каталог с умным фильтром — самая нагруженная часть магазина, и её ускоряют отдельно.
- Кэш результатов фильтрации. Частые комбинации фильтра кэшируются, а не пересчитываются каждый раз.
- Тегированный кэш каталога. Сброс только изменившихся товаров при обмене с 1С, а не всего каталога.
- Индексы под свойства. Фильтрация по характеристикам опирается на индексы.
- Разумный размер выборки. Число товаров на странице кратно сетке и не перегружает рендер.
Плюс композитный сайт для мгновенной отдачи каркаса страницы каталога. Важно, чтобы кэш фильтра корректно сбрасывался при обмене только для реально изменившихся позиций — иначе либо витрина устаревает, либо кэш бесполезен.
Фронтенд: картинки, скрипты, шрифты
Даже быстро сгенерированную страницу способны убить тяжёлый фронтенд. После бэкенда оптимизируют то, что грузится в браузере.
- Изображения. Современные форматы (WebP), сжатие, правильные размеры, ленивая загрузка вне экрана.
- Скрипты. Уберите блокирующие рендер, объедините и отложите некритичный JavaScript.
- Стили. Критический CSS в первую отрисовку, остальное — отложенно.
- Шрифты. Подгрузка без блокировки текста, ограничение числа начертаний.
Тяжёлые несжатые картинки в карточках товара — самая частая фронтенд-проблема магазина. Их оптимизация часто даёт быстрый и заметный прирост.
Core Web Vitals
Google оценивает реальный опыт пользователя тремя метриками, и под них стоит целиться прицельно.
- LCP (отрисовка основного контента). Улучшается композитом, кэшем, быстрым сервером и оптимизацией главной картинки.
- INP (отзывчивость на действия). Страдает от тяжёлого JavaScript — облегчайте скрипты, особенно на мобильных.
- CLS (сдвиг макета). Задавайте размеры картинок и блоков, чтобы контент не «прыгал» при загрузке.
Эти метрики — и фактор ранжирования, и честное отражение того, как магазин ощущается пользователем. Держите их под наблюдением до и после каждой оптимизации.
Код и агенты на cron
Скорость упирается и в качество кода. Неоптимальные компоненты, отсутствие кэширования в кастомных вставках, тяжёлые агенты на хитах — всё это замедляет страницы. Два системных шага:
- Агенты на cron. Переведите фоновые задачи и отправку почты с хитов посетителей на планировщик — страницы станут легче, а фон стабильнее.
- Кэш в кастомном коде. Оборачивайте тяжёлые выборки в кэширование, не дёргайте базу на каждый хит.
Чистый, кэшируемый код — фундамент стабильной скорости. При росте проекта это ещё и вопрос сопровождения: аккуратная архитектура и деплой разобраны в материале про CI/CD и деплой Битрикс.
Частые ошибки
- Оптимизация вслепую. Правят то, что не тормозит, а узкое место остаётся.
- Не включён композит. Один из сильнейших инструментов ускорения простаивает.
- Файловый кэш вместо memcached. Диск становится узким местом под нагрузкой.
- Нет индексов под фильтр. Запросы каталога сканируют таблицы целиком.
- Сброс всего кэша при обмене. Каждый обмен с 1С обнуляет кэш каталога — витрина «холодная».
- Тяжёлые картинки. Несжатые изображения убивают LCP.
- Агенты на хитах. Фоновые задачи замедляют страницы посетителей.
- Разовое ускорение. Настроили и забыли — скорость деградировала с ростом каталога.
Полный чек-лист ускорения
- Метрики сняты. Узкое место найдено по замерам, а не по догадкам.
- Композит включён. Статика отдаётся из кэша, динамика догружается.
- Кэш настроен. Компонентный и тегированный кэш работают, сброс точечный.
- memcached подключён. Кэш и сессии в памяти, диск разгружен.
- MySQL оптимизирован. Индексы под фильтр, буферный пул, разобраны медленные запросы.
- Каталог ускорен. Кэш фильтра, тегированный сброс, разумная выборка.
- Фронтенд облегчён. WebP, сжатие, ленивая загрузка, отложенные скрипты.
- Core Web Vitals в норме. LCP, INP, CLS в зелёной зоне.
- Агенты на cron. Фоновые задачи сняты с хитов.
- Мониторинг настроен. Скорость под наблюдением, просадки не копятся.
Вывод
Скорость магазина на 1С-Битрикс — это выручка: медленная витрина теряет и конверсию, и позиции в поиске. Но у платформы сильные штатные инструменты, и большинство проблем решается без переписывания сайта. Начните с замеров, чтобы найти реальное узкое место, затем бейте прицельно: композит и memcached, многоуровневый кэш, оптимизация MySQL и индексов, разгрузка фронтенда.
Главное — не разовый рывок, а система: связка «композит + memcached», точечный сброс кэша при обмене с 1С, индексы под фильтр, лёгкий фронтенд и мониторинг Core Web Vitals. Пройдите по чек-листу, снимите быстрые улучшения сами, а сложную настройку под нагрузку доверьте специалистам — и магазин будет открываться мгновенно даже в пик распродажи.
