Услуги по оптимизации производительности 1С-Битрикс

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Предлагаемые услуги
Показано 30 из 62 услугВсе 1626 услуг
Простая
~1 рабочий день
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1163
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Разработка веб-сайта для компании ФИКСПЕР
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    563
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    743
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    653
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    976

Оптимизация производительности сайтов на 1С-Битрикс

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

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

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 на выделенном сервере
  • query_cache_type = 0 на MySQL 8.x (query cache удалён) или MariaDB с query_cache_size под профиль нагрузки
  • Составные индексы для фасетного поиска: (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 ломают композит. Проверяем каждую страницу через панель «Производительность → Композитный сайт».

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

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

Фронтенд

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

  • WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация
  • srcset + sizes — не грузим 3000px картинку в блок 400px
  • loading="lazy" для всего ниже первого экрана
  • AVIF для браузеров с поддержкой — ещё 20-30% экономии vs 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, поиск конкретных узких мест. Видим, что CIBlockElement::GetList() с пятью PROPERTY_* фильтрами занимает 2 сек — оптимизируем именно этот вызов

Оптимизация БД: глубже стандартных настроек

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

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

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

Результаты

Метрика До После
TTFB 800-2000 мс 50-200 мс
Полная загрузка 4-8 сек 1.5-2.5 сек
PageSpeed (мобильный) 30-50 80-95
Одновременные пользователи 50-100 500-2000+

Мониторинг

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

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

Хостинг

Тип Для кого Предел
Shared Визитки, до 500 визитов/день Нет контроля над PHP-FPM, Redis, Nginx
VPS/VDS Большинство проектов До 30K визитов/день при правильной настройке
Dedicated Крупные магазины Полный контроль, NVMe, много RAM
Облако (Yandex Cloud, VK Cloud, AWS) Неравномерная нагрузка Автоскейлинг на распродажах, отказоустойчивость

Стоимость

Тип работ Сроки Стоимость
Базовая оптимизация (кэш, изображения, минификация) 2-3 дня от 25 000 руб.
Оптимизация БД (индексы, slow queries, настройка) 3-5 дней от 40 000 руб.
Серверная инфраструктура (Nginx, PHP-FPM, Redis) 2-3 дня от 30 000 руб.
Комплексная (сервер + БД + фронтенд + CDN) 1-3 недели от 80 000 руб.
Нагрузочное тестирование и профилирование 2-3 дня от 20 000 руб.
Кластерная архитектура (балансировка, репликация) 1-2 недели от 120 000 руб.

Сокращение TTFB на 1 секунду даёт около +7% к конверсии. Для магазина с оборотом 5 млн/мес — это 350K дополнительной выручки ежемесячно.