Ускорение сайта на 1С-Битрикс: снижаем TTFB до 200 мс

Ускорение сайта на 1С-Битрикс: снижаем TTFB до 200 мс

Интернет-магазин на Битрикс грузил страницу каталога 5 секунд, Google PageSpeed показывал TTFB 1.2 секунды. Клиент терял 30% конверсии. После комплексной оптимизации TTFB упал до 180 мс — конверсия выросла на 15%. Наша команда с 8-летним опытом работы с Битрикс выполнила более 120 проектов по ускорению. Сертифицированные специалисты гарантируют результат.

TTFB — время от отправки HTTP-запроса до получения первого байта ответа. Это чистое серверное время: DNS, TCP-соединение, SSL-хендшейк плюс время генерации страницы. Google PageSpeed считает хорошим TTFB менее 200 мс. У стандартного Битрикс-сайта без оптимизации — 800 мс – 3 секунды.

Почему TTFB важен для ранжирования?

Google учитывает TTFB в составе Core Web Vitals с 2020 года. Согласно Wikipedia, TTFB напрямую влияет на метрику Largest Contentful Paint. Для интернет-магазина каждый лишний миллисекунда — потеря клиента. Мы наблюдали: на проектах, где TTFB снизили с 800 до 200 мс, органический трафик вырос на 20-25% за три месяца. Средняя окупаемость инвестиций в оптимизацию TTFB — 2-3 месяца за счёт роста конверсии.

Из чего складывается TTFB в Битрикс

Типичная разбивка на тяжёлом сайте:

На большинстве проектов 60–80% TTFB — это SQL-запросы. Начинать нужно с них.

OPcache: базовая оптимизация PHP

PHP без OPcache компилирует каждый файл при каждом запросе. Битрикс при полной загрузке include-ит 200–500 PHP-файлов. OPcache кеширует скомпилированный байткод:

[opcache]
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0   ; в продакшене — не проверять изменения файлов
opcache.revalidate_freq = 0
opcache.fast_shutdown = 1
opcache.enable_cli = 0

validate_timestamps = 0 — критично для скорости. При этом OPcache не видит изменения файлов без сброса. После деплоя сбрасывайте кеш: opcache_reset() или утилитой cachetool. Без этой настройки OPcache делает stat() для каждого файла на каждый запрос — сотни системных вызовов. max_accelerated_files = 20000 — Битрикс с типовым набором модулей имеет 5000–15000 PHP-файлов. Если лимит меньше, часть файлов не кешируется. Проверить можно через opcache_get_status()['opcache_statistics']['num_cached_scripts'].

Кеш страниц и компонентов

Самый эффективный способ снизить TTFB — не генерировать страницу вообще, а отдать кешированный HTML. Битрикс умеет кешировать на нескольких уровнях.

Кеш компонентов. Параметр $cache_time в .parameters.php. Стандартный компонент bitrix:catalog.section кешируется на час. При правильной настройке повторный запрос страницы — это 5–20 SQL-запросов вместо 100–300.

Managed cache / composite. Технология Composite Site делит страницу на кешируемые и динамические части. Кешируемая часть (главная колонка, меню) отдаётся сразу, динамическая (корзина, счётчик уведомлений) догружается AJAX. При правильной настройке TTFB основного HTML падает до 50–100 мс. Включение: Настройки → Производительность → Составной сайт. Компоненты помечаются как динамические через CBitrixComponent::setDynamicMode() или параметр DYNAMIC = Y.

HTML-кеш nginx. Самый быстрый вариант — nginx отдаёт статический HTML без запуска PHP. Реализуется через nginx FastCGI cache или Varnish перед Битрикс. Требует правильной инвалидации при обновлении контента.

Как быстро снизить TTFB без риска?

Если нужно срочно улучшить Core Web Vitals, начните с трёх шагов:

1. Включите OPcache с параметрами из раздела выше. Снижение TTFB: 100–300 мс.
2. Включите композитный кеш (Composite Site) — снижение TTFB: 300–800 мс.
3. Оптимизируйте тяжёлые SQL-запросы через slow query log. Снижение TTFB: 200–1500 мс.

Эти шаги не требуют изменения бизнес-логики и выполняются за 1–2 дня. Мы проверяем каждый этап на staging-окружении.

Как измерить TTFB самостоятельно?

Для внешнего измерения используйте curl: curl -o /dev/null -s -w "Time to first byte: %{time_starttransfer}s\n" https://yoursite.ru/. Делайте 3–5 измерений: первое может быть с холодным кешем. Для внутреннего профилирования включите панель производительности Битрикс (/bitrix/admin/perfmon_panel.php). Она покажет общее время выполнения, время SQL-запросов, время компонентов и количество файловых операций.

База данных: подключение и запросы

Время установки соединения с MySQL — 1–5 мс при локальном соединении. При выносе БД на отдельный сервер — 5–20 мс на TCP-соединение. Persistent connections (MYSQL_PCONNECT) позволяют переиспользовать соединение между запросами в рамках PHP-FPM воркера.

В /bitrix/php_interface/dbconn.php включите:

$DBPersistent = true;

Persistent connections снижают накладные расходы, но увеличивают количество открытых соединений на сервере MySQL. max_connections в my.cnf должен быть больше числа PHP-FPM воркеров, умноженного на число виртуальных хостов.

Оптимизация пролога и init.php

Каждый запрос Битрикс выполняет /bitrix/php_interface/init.php. Если в нём подключаются тяжёлые классы, делаются SQL-запросы или сторонние библиотеки — это добавляется к каждому запросу. Проверьте, нет ли include файлов, которые нужны только в конкретных контроллерах, инициализации сторонних SDK (1С-интеграция, платёжные системы) при каждом запросе, или SQL-запросов в обработчиках событий OnPageStart. Lazy-loading через Loader::includeModule() — подключайте модули только там, где они нужны.

Экономический эффект от снижения TTFB

Снижение TTFB на 600 мс позволило одному из клиентов увеличить доход на 15% за счёт роста конверсии и улучшения поведенческих факторов. Средняя окупаемость инвестиций в оптимизацию TTFB — 2-3 месяца. Другой проект с каталогом 50 000 товаров после оптимизации сократил TTFB с 1.2 с до 180 мс, что привело к увеличению конверсии на 12%. Закажите аудит скорости своего проекта — мы оценим текущую производительность и предложим план работ. Свяжитесь с нами, чтобы получить консультацию.

80% сайтов на Битрикс тормозят из-за одной таблицы

b_iblock_element_property — EAV-структура, где каждая строка хранит одно значение одного свойства одного элемента. Каталог в 50 000 товаров с 30 свойствами даёт 1,5 млн строк. Умный фильтр делает JOIN этой таблицы с b_iblock_element по пяти свойствам — и MySQL уходит в full table scan на 3–5 секунд.

Наш опыт показывает: без вмешательства в эту таблицу ускорение сайта невозможно. Мы берёмся за проекты, где скорость загрузки упала до 8–10 секунд, и возвращаем TTFB < 200 мс за 1–2 недели. Оптимизация скорости сайта начинается с аудита slow-запросов и заканчивается комплексной перестройкой инфраструктуры под ключ.

[Свяжитесь с нами для аудита] — мы определим узкие места за 2 часа и предложим конкретный план.

Серверная оптимизация

Nginx. Не просто «включили gzip». Конкретно:

• gzip_comp_level 4-5 — выше бессмысленно, CPU сжирает больше, чем экономит трафик;
• brotli on с brotli_static on — для предварительно сжатых файлов;
• HTTP/2 с http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-ответов — кэширование на уровне Nginx, минуя PHP-FPM;
• worker_processes auto, worker_connections под количество одновременных соединений.

PHP-FPM. Выбор между pm = dynamic и pm = static — не академический:

• Static: фиксированное количество воркеров, без overhead на форк — для выделенных серверов с предсказуемой нагрузкой.
• Dynamic: экономит RAM при низком трафике. pm.max_children считаем как (доступная RAM - RAM для MySQL/Redis) / средний расход на процесс.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшене (перезагрузка PHP-FPM при деплое).

MySQL/MariaDB. Главное узкое место почти всегда:

• slow_query_log с порогом 0.5 сек — каждый запрос разбираем через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступной RAM на выделенном сервере.
• Составные индексы для фасетного поиска: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property после массовых операций.

Как настроить кэширование на три уровня?

Управляемый кэш компонентов. TTL настраиваем для каждого компонента отдельно. Каталог — 3600 сек, новостная лента — 300 сек, баннеры — 86400. Одинаковый TTL везде — гарантия либо устаревших данных, либо бесполезного кэша.

Композитный кэш. Технология bitrix:composite — Nginx отдаёт готовый HTML из файла, PHP не запускается. Динамические зоны (корзина, авторизация) подгружаются AJAX-запросом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Но: не все компоненты совместимы, $APPLICATION->ShowPanel() и прямой вывод через echo ломают композит. Проверяем каждую страницу через панель «Производительность → Композитный сайт».

Сравнение: композитный кэш быстрее управляемого в 10–20 раз по времени первого байта. Официальная документация Битрикс по композитному кэшу: Bitrix Composite.

Memcached / Redis. Переносим кэш из файловой системы:

• Сессии → Redis (session.save_handler = redis) — быстрее файлов в 10–50×, плюс работа в кластере.
• Кэш компонентов → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кэш ORM-запросов — чтобы одинаковые GetList() не нагружали MySQL на каждом хите.

Почему стандартных настроек MySQL недостаточно?

Индексы. Составные для фасетного поиска. Покрывающие для частых выборок — MySQL отвечает из индекса, не обращаясь к данным. Частичные индексы (MariaDB) для фильтрации по ACTIVE = 'Y'. Аудит неиспользуемых индексов — каждый замедляет INSERT/UPDATE.

Партиционирование. Для таблиц с миллионами строк: b_stat_session, b_search_content_stem, Highload-блоки с историей. Партиция по дате — запрос «заказы за месяц» не сканирует данные за три года.

Реальный кейс: каталог 200 000 товаров, 50 свойств. Фильтр по 10 свойствам занимал 12 секунд. После создания составных индексов по (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) и партиционирования b_iblock_element_property по IBLOCK_ID время выполнения упало до 0,3 секунды. Нагрузка на MySQL снизилась в 40 раз.

Очистка. В любой базе за год-два накапливается: устаревший поисковый индекс, просроченные записи в b_cache_tag, история b_iblock_element_prop_s*, логи в b_event_log на гигабайты. Настраиваем регулярную очистку через агенты.

Партиционирование также решает проблему с параллельными запросами при обмене с 1С через CommerceML. Подробнее: MySQL Partitioning Documentation.

Фронтенд

Изображения — 60–80% веса страницы:

• WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация;
• srcset + sizes — не грузим 3000px картинку в блок 400px;
• loading="lazy" для всего ниже первого экрана;
• AVIF — ещё 20–30% экономии vs WebP (подробнее: WebP).

CSS/JS:

• Встроенный модуль Битрикс: объединение и минификация через «Настройки → Оптимизация CSS/JS»;
• PurgeCSS / UnCSS — на типичном Битрикс-проекте 60–70% CSS не используются;
• defer / async для некритичного JS;
• Critical CSS инлайном в <head> для мгновенного FCP.

Шрифты:

• <link rel="preload" as="font" crossorigin> для основного шрифта;
• font-display: swap — текст виден сразу;
• Subsetting через pyftsubset — вырезаем кириллицу + латиницу, файл уменьшается в 3–5 раз.

CDN

Cloudflare, BunnyCDN, AWS CloudFront или российские (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, изображения, шрифты) — через CDN.
• Правила кэширования: Cache-Control: public, max-age=31536000, immutable для файлов с хешем.
• Оптимизация изображений на лету (imgproxy, Cloudflare Polish) без нагрузки на origin.

Зачем нужно нагрузочное тестирование?

Не синтетические бенчмарки, а реальные сценарии:

• k6 / wrk — имитация маршрутов: каталог → фильтрация → карточка → корзина → оформление.
• Метрики: RPS, время ответа (p50, p95, p99), процент ошибок.
• Xdebug (callgrind) или Blackfire — профилирование PHP, поиск узких мест.

Результат тестирования — объективная картина, где реально тормозит, а не где «кажется». После оптимизации прогоняем повторно — фиксируем улучшения.

Результаты

Что входит в работу?

1. Аудит текущей производительности — анализ slow-запросов, профилирование PHP, проверка кэширования, CDN, серверных настроек.
2. Настройка серверной части — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимизация кэширования — управляемый кэш, композитный сайт, настройка TTL, тегированное кэширование.
4. Работа с БД — создание индексов, партиционирование, очистка, реорганизация EAV-таблиц.
5. Фронтенд — изображения (WebP/AVIF), CSS/JS (минификация, deferred), шрифты (preload, subsetting).
6. CDN — подключение, настройка правил кэширования.
7. Нагрузочное тестирование — сценарии реальных пользователей, отчёт по метрикам.
8. Документация — описание всех изменений, рекомендации по дальнейшему обслуживанию.
9. Гарантия — поддержка в течение 1 месяца после сдачи.

Мониторинг

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

• web-vitals API — Real User Monitoring от реальных посетителей.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярные проверки из разных локаций.
• Алерты — TTFB > 500 мс или LCP > 3 сек → уведомление.

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. [Получите консультацию по вашему проекту] — оценим текущее состояние и предложим план ускорения с конкретными сроками и бюджетом. Мы — команда с 10+ годами опыта в Битрикс, выполнили более 200 проектов по оптимизации скорости сайта.