Что такое highload блоки в 1С-Битрикс и когда они нужны?

Каталог тормозит, в поиске "highload блок" смешивают облачную CRM и CMS, а в legacy-гайдах копируют полный CRUD вместо карты темы. Highload-блоки (HL) в "1С-Битрикс: Управление сайтом" - это плоские справочники в отдельных таблицах MySQL, не замена всего каталога. Ниже - что такое HL, когда выбрать его вместо инфоблока, как вывести записи стандартными компонентами и куда идти за пошаговой админкой или D7-кодом.

Highload-блоки (HL) в 1С-Битрикс: Управление сайтом - модуль для плоских справочников и больших таблиц данных. Каждый HL хранит записи в собственной таблице MySQL с собственными индексами, без иерархии инфоблока. Доступ - через D7 ORM (HighloadBlockTable::compileEntity, затем getDataClass) и компоненты bitrix:highloadblock.list / .view. Сегодня: сравните HL с инфоблоком по таблице ниже, выберите сценарий под задачу и откройте нужный гайд - создание в админке или CRUD в коде.

Речь только о коробочной CMS на вашем сервере. Bitrix24 - CRM и задачи, другой продукт; highload.ru и nginx highload к модулю highloadblock не относятся. Материал актуален на 2026-07-26 по документации dev.1c-bitrix.ru.

Это hub-статья: определение, сравнение, маршрут. Пошаговое создание полей UF_* и полный add/update/delete через ORM вынесены в отдельные материалы, чтобы не дублировать B26 и B78.

Что такое Highload-блок в 1С-Битрикс: Управление сайтом

Highload-блок (HL) - быстрый плоский справочник без разделов и SEO-полей элемента. Каждый блок получает свою таблицу в базе (префикс b_hlbd_ или заданный TABLE_NAME) и набор пользовательских полей UF_* - как колонки таблицы. D7 ORM - слой PHP-классов для чтения и записи в MySQL без ручного SQL в типовых задачах.

Когда HL уместен: бренды, цвета и размеры для торговых предложений, коды складов, логи событий, таблицы соответствий на десятки тысяч строк. Когда не нужен: новости, статьи, товары с карточкой и иерархией разделов - для этого инфоблок. HL не заменяет весь каталог, а разгружает "тяжёлые" справочники.

Сравните Highload-блок и инфоблок по задаче

Оба хранят структурированные данные, но архитектура разная. Инфоблок тянет разделы, свойства, детальные URL и шаблоны. HL - одна таблица, одна форма в админке, минимум накладных расходов на выборку.

Сделайте: вынесите в HL фильтруемые справочники от 5-10 тысяч значений и любые плоские логи. Не делайте: не копируйте карточки товаров в HL "ради скорости" - потеряете разделы, ЧПУ и привычную админку каталога.

Выберите сценарии, когда нужен Highload-блок

По официальному описанию модуля HL заточен под произвольные наборы данных под нагрузкой. На практике чаще всего встречаются пять сценариев.

1. Справочник брендов или цветов для каталога: в свойстве товара хранится UF_XML_ID из HL, а не тысячи значений в списке инфоблока.
2. Свойства торговых предложений (размер, оттенок): HL как источник значений для SKU без раздувания умного фильтра.
3. Логи и история (события, статусы заказов, аудит): пишете часто, на сайте почти не показываете.
4. Большие плоские таблицы (гео, склады, коды поставщиков) свыше 50 000 строк - отдельная таблица и индексы на поля фильтра.
5. Связь с пользователями через UF-тип "привязка к пользователю" - когда в справочнике нужен ID менеджера или автора записи.

HL сам по себе не ускоряет сайт: сначала найдите узкое место - свойства IB, индексы MySQL или компонент. Иногда хватает кэша без нового блока.

Сделайте: критерий "плоский справочник + большой объём". Не делайте: HL на каждую мелочь.

Выведите highload блок на сайт стандартными компонентами

Для публичной части в курсе "1С-Битрикс: Управление сайтом" (COURSE_ID=41) описаны два штатных компонента. Их хватает контент-менеджеру без кастомного PHP на первом этапе.

Схема вывода:
Страница списка (bitrix:highloadblock.list, BLOCK_ID) → ссылка на деталь → bitrix:highloadblock.view (тот же BLOCK_ID, ELEMENT_ID в URL)

bitrix:highloadblock.list - таблица или список записей. Ключевые параметры: BLOCK_ID (числовой ID из админки), DETAIL_URL (шаблон ссылки на деталь, например /spravochnik/#ELEMENT_ID#/), ROWS_PER_PAGE (пагинация), FILTER_NAME (имя массива $GLOBALS для фильтра). Подробности - в справке по компоненту.

bitrix:highloadblock.view - одна запись по ID из URL. Тот же BLOCK_ID, поля UF_* доступны в шаблоне как arResult. Для чистого справочника без "страницы бренда" деталька часто не нужна - достаточно list в админском режиме или своего шаблона.

Работа с хайлоад блоками битрикс на публичке не требует compileEntity: компоненты сами подключают модуль highloadblock. В коде шаблона проверьте, что модуль установлен и BLOCK_ID совпадает с созданным блоком.

Делайте: вынесите BLOCK_ID в constants.php проекта. Не делайте: не копируйте BLOCK_ID=1 с чужого туториала - на проде ID другой.

Разберите цепочку D7: от HighloadBlockTable до getDataClass

Когда компонентов мало и нужна гибкая выборка, подключают модуль и ORM. Минимальная цепочка без полного CRUD:

1. Loader::includeModule('highloadblock') - модуль должен быть установлен; иначе классы недоступны.
2. HighloadBlockTable::getById($hlId) - метаданные блока (NAME, TABLE_NAME), не сами записи справочника.
3. HighloadBlockTable::compileEntity($hlblock) - ядро собирает DataManager для таблицы HL и подтягивает UF_-поля.
4. $entity->getDataClass() - имя класса, у которого вызывают getList, add, update, delete для строк справочника.
5. $dataClass::getList([...]) - выборка с filter, select, order как у обычного D7 ORM.

<?php
use Bitrix\Main\Loader;
use Bitrix\Highloadblock\HighloadBlockTable;

Loader::includeModule('highloadblock');
$hlblock = HighloadBlockTable::getById(MY_HL_ID)->fetch();
if (!$hlblock) { return; }

$entity = HighloadBlockTable::compileEntity($hlblock);
$dataClass = $entity->getDataClass();
$rows = $dataClass::getList([
 'select' => ['ID', 'UF_NAME'],
 'filter' => ['=UF_ACTIVE' => 1],
 'limit' => 20,
])->fetchAll();

Типичная ошибка: вызывать add() на HighloadBlockTable - этот класс описывает блоки в b_highloadblock, а не строки в b_hlbd_*. Записи справочника пишут через getDataClass().

Не вызывайте API highloadblock до обработчика пользовательских свойств: compileEntity() тянет UF_-типы, на раннем init с кастомными UserType возможны сбои.

Полный разбор add/update/delete, кэша entity и ошибок UF_ - в гайде по работе с highload блоками битрикс D7. Здесь только карта, без дубля CRUD-справочника.

Делайте: кэшируйте $dataClass в static или Bitrix\Main\Data\Cache на боевом сайте. Не делайте: не вызывайте compileEntity на каждый HTTP-запрос без необходимости.

Перейдите к практическим гайдам по кластеру highload

Hub заканчивается на маршруте. Два следующих шага закрывают 90% реальных задач.

Создание в админке. Название сущности, TABLE_NAME, поля UF_*, права, импорт CSV - пошагово в материале как создать highload-блок на Битрикс. Там же чек-лист "когда HL вместо инфоблока" с привязкой к каталогу.

CRUD в коде. compileEntity, getList с фильтрами, add/update/delete, инвалидация кэша и типовые ошибки Invalid highloadblock description - в руководстве по D7 ORM для Highload-блоков. Читайте после того, как блок уже создан и ID известен.

Если каталог тормозит после HL, проверьте умный фильтр и индексы на UF_. Аудит справочников - напишите нам.

Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: api_help Highload-блоки, D7 HighloadBlockTable, курсы COURSE_ID=41 и 43 на dev.1c-bitrix.ru.

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