ускорение сайта на 1с-битрикс: 15 приёмов оптимизации

с чего я начинаю диагностику, а не с советов

Прежде чем что-то оптимизировать, я всегда открываю встроенный модуль «Монитор производительности» (Настройки → Инструменты разработчика → Монитор производительности) и смотрю, сколько времени страница тратит на PHP, сколько на запросы к базе, сколько отдаётся статикой. Без этого шага легко потратить день на webp-картинки, когда 70% времени страницы съедает один тяжёлый SQL-запрос в компоненте.

Второй обязательный инструмент — вкладка Network в браузере на холодном кеше (Ctrl+Shift+R). Она показывает реальную картину: сколько запросов уходит на сторонние скрипты, какие ресурсы блокируют отрисовку, сколько весит страница целиком. На моих аудитах страница на 1С-Битрикс без оптимизации обычно весит 4-8 МБ, из них больше половины — неоптимизированные изображения.

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

приёмы 1–3: кеширование ядра

1. Композитный кеш. Настройки → Настройки продукта → Автокеширование → Композитный сайт. Кеширует страницу целиком как статику для неавторизованных посетителей, а «живые» блоки — корзина, счётчик, персональные виджеты — подгружает отдельными запросами. На типичном каталоге даёт падение времени отдачи страницы в 3-5 раз, это самый быстрый эффект из всех 15 пунктов.
2. Автокеширование компонентов. Настройки → Настройки продукта → Автокеширование → длительность кеша по умолчанию. На каталогах с редко меняющимся ассортиментом ставлю 3600-7200 секунд вместо стандартных 3600 — заметно снижает число обращений к базе на повторных заходах.
3. Кеширование меню. Отдельная галочка в том же разделе — меню и разделы каталога перестают собираться SQL-запросом на каждый визит. Мелочь, но на сайтах с многоуровневым каталогом (300+ разделов) экономит 100-200 мс на странице.

приёмы 4–6: изображения и статика

4. Перевод изображений в webp. На аудитах вижу разницу в весе в 30-60% против исходного jpg/png при том же визуальном качестве. Модуль «Ускорение сайта (CDN)» умеет конвертировать на лету, либо это делается один раз пакетно через модули маркетплейса.

5. Lazy load для изображений ниже первого экрана. Атрибут loading="lazy" на теге img или отдельный JS-модуль — браузер не грузит картинки, которые пользователь ещё не долистал. На карточке товара с 10-15 фото в галерее это убирает 70-80% начальной загрузки страницы.

6. Подключение CDN. Настройки → Облако 1С-Битрикс → Ускорение сайта (CDN). Статика — картинки, css, js — раздаётся с ближайшего к посетителю узла, а не с одного сервера в Москве. Для аудитории из регионов даёт заметное ускорение отдачи статики, для аудитории рядом с сервером эффект скромнее.

приёмы 7–9: сервер и php

7. Актуальная версия PHP. Переход с PHP 7.4 на 8.2-8.3 на моих проектах даёт 15-25% ускорения выполнения кода без единой правки в самом сайте — просто за счёт того, что новый интерпретатор быстрее работает с тем же кодом. Перед переходом обязательно проверяю совместимость модулей маркетплейса.

8. PHP-FPM вместо mod_php. FPM работает пулами процессов и лучше держит нагрузку при одновременных посетителях — на сайте с трафиком от нескольких сотен человек одновременно разница ощутима именно в стабильности времени ответа под нагрузкой, а не в скорости одного запроса.

9. Включённый Gzip/Brotli на сервере. Сжатие текстовых ресурсов — html, css, js — перед отправкой браузеру. Экономит 60-70% веса этих файлов в передаче. Проверяется одной строкой в заголовках ответа сервера (Content-Encoding), включается на уровне веб-сервера или в настройках хостинга.

приёмы 10–12: база данных и агенты

10. Ревизия cron-агентов. В «Монитор производительности» отдельная вкладка показывает, сколько времени съедают агенты — фоновые задачи вроде обмена с 1С, рассылок, переиндексации поиска. На одном аудите нашёл агент старого модуля, который запускался каждую минуту и держал таблицу базы заблокированной по 3-4 секунды — это било по скорости всех страниц сайта, а не только по обмену.

11. Индексы на часто используемые поля инфоблоков. Если каталог фильтруется по свойствам товара (цвет, размер, бренд) — без индекса каждый такой запрос делает полный перебор таблицы. На каталоге в 20-30 тысяч товаров без индексов фильтр может отрабатывать 2-3 секунды, с индексами — 100-200 мс.

12. Миграция на PostgreSQL при серьёзном масштабе. Это не приём «для всех» — я рекомендую его только при реально большой базе и нагрузке, когда MySQL упирается в потолок по параллельным подключениям. У меня есть отдельный разбор кейса миграции Битрикс24 с MySQL на PostgreSQL — там честно про то, когда это оправдано, а когда просто лишний риск.

приёмы 13–15: фронтенд

13. Минификация и объединение css/js. Настройки → Настройки продукта → Производительность → Оптимизация CSS/JS. Склеивает файлы в один-два вместо десятков и убирает пробелы и комментарии. Меньше запросов браузера — быстрее первая отрисовка, особенно заметно на мобильном соединении.

14. Асинхронная загрузка сторонних скриптов. Метрика, чаты поддержки, виджеты соцсетей — всё это должно грузиться атрибутом async или defer, а не блокировать построение страницы. На одном проекте виджет онлайн-консультанта без async добавлял 900 мс к времени до интерактивности — просто потому что браузер ждал его загрузки, прежде чем показать остальной контент.

15. Оптимизация веб-шрифтов. Свойство font-display: swap плюс подключение только реально используемых начертаний вместо всего семейства шрифта целиком. Часто вижу на аудитах подключёнными 6-8 начертаний, когда сайт использует два.

что реально дают эти приёмы вместе — на цифрах

На упомянутом в начале интернет-магазине после композитного кеша, webp и перехода на PHP-FPM время отдачи главной страницы упало с 4,2 до 0,9 секунды. Больше половины эффекта дал именно композитный кеш — это всегда самый весомый пункт из пятнадцати, если он ещё не включён.

На другом проекте, каталоге на 15 тысяч товаров, где кеш уже стоял, а проблема была в фильтре без индексов — время отклика страницы категории с применённым фильтром снизилось с 2,8 секунды до 180 мс после добавления индексов на поля свойств. Здесь эффект от кеша был бы минимальным — узкое место было в другом слое, и диагностика через «Монитор производительности» это сразу показала.

Вывод простой: приёмы не равнозначны для конкретного сайта, и без диагностики можно оптимизировать не то, что тормозит на самом деле.

типичные ошибки при ускорении сайта на 1с-битрикс

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

Оптимизировали фронтенд при не включённом кеше на бэкенде. Минификация css/js и webp дают эффект в 10-20% от общего времени загрузки, если основная проблема — не закешированные тяжёлые SQL-запросы на бэкенде. Начинать нужно с кеша, а не с картинок.

Ускорили сайт, но не перепроверили после обновления модулей. Обновление 1С-Битрикс или маркетплейс-решения иногда сбрасывает часть настроек производительности или добавляет новый неоптимизированный компонент. Раз в квартал стоит заново открывать «Монитор производительности» и сверять цифры, а не полагаться на разовую настройку.

Если сайт разрабатывался давно и непонятно, что из пятнадцати пунктов уже включено, а что нет — я обычно начинаю такие проекты с технического аудита без потери SEO-показателей, чтобы ускорение не задело позиции в поиске.

Отдельный случай — когда сайт настолько старый и перегруженный лишним функционалом, что 15 приёмов дают лишь временное облегчение. Тогда честнее разобраться, что вообще должно быть на сайте: у меня есть разбор, когда нужен полноценный корпоративный сайт, а когда достаточно лендинга — иногда ускорение неправильной структуры менее выгодно, чем пересборка под реальные задачи.

частые вопросы