Сайт спортивного клубу: від розкладу до мерчу на 1С-Бітрікс

Сайт спортивного клубу: від розкладу до мерчу на 1С-Бітрікс

Уявіть: уболівальник хоче купити квиток на матч, вибрати конкретне місце на схемі стадіону, а заодно замовити футболку з прізвищем гравця — все на одному сайті. І все це має працювати без гальм при пікових навантаженнях. Ми будуємо такі сайти на 1С-Бітрікс, де одночасно живуть розклад тренувань, турнірні таблиці, квиткова система з вибором місць і мерч-магазин. Кожен блок потребує окремої архітектури даних, а разом — грамотного кешування та тегування. Наш досвід показує, що стандартні компоненти справляються тільки при кастомному налаштуванні інфоблоків та Highload-блоків. Вартість проекту розраховується індивідуально — зв'яжіться з нами для оцінки.

Як спроектувати структуру даних для спортивного клубу?

Для спортивного клубу вибудовується ієрархія з кількох пов'язаних інфоблоків:

• Команди — основний інфоблок із прив'язкою до виду спорту, ліги, сезону. Властивості: склад (прив'язка до інфоблоку «Спортсмени»), тренерський штаб, логотип, кольори форми.
• Спортсмени — інфоблок з деталізованими профілями: ПІБ, амплуа, номер, антропометрія, фото у формі, статистика по сезонах (голи/очки/передачі винесені в окремий Highload-блок для швидкої вибірки).
• Матчі та тренування — Highload-блок (b_hlblock_schedule), тому що записів за кілька сезонів набираються тисячі. Поля: дата/час, тип (тренування/матч/товариський), команда-господар, команда-гість, стадіон, статус (заплановано/триває/завершено/перенесено), рахунок.
• Турніри — інфоблок із прив'язкою до сезону. Турнірна таблиця формується кастомним компонентом на основі результатів матчів з Highload-блоку.

Прив'язки між інфоблоками реалізуються через властивість типу «Прив'язка до елементів» (E) або через Highload-довідники, якщо потрібна продуктивність на вибірках.

Чому для розкладу використовують Highload-блоки?

Розклад тренувань і матчів — найгарячіший розділ сайту. Уболівальники заходять перевірити найближчі ігри, тренери дивляться розклад занять, адміністратори оновлюють результати в реальному часі.

Highload-блок обраний не випадково: при 300+ матчах за сезон і 5-6 командах у клубі звичайний інфоблок починає гальмувати на складних фільтраціях. Highload-блок зберігає дані в окремій таблиці MySQL, запити йдуть напряму без overhead інфоблочного API. Порівняння: Highload-блоки обробляють запити в 5 разів швидше за інфоблоки при вибірках по 10 000 записів.

Фільтрація на фронті: по команді, по типу події, по місяцю. Компонент рендерить календарну сітку з кольоровою індикацією — тренування сірим, домашні матчі зеленим, виїзні синім. Для SEO кожен матч отримує свою детальну сторінку з ЧПУ виду /matches/2024-25/spartak-vs-dinamo-12-10/.

Кеш — тегований, прив'язаний до тегу schedule_updated. При оновленні будь-якого елемента Highload-блоку через обробник події HighloadBlockOnAfterUpdate скидається саме цей тег, а не весь кеш сайту.

Як працює квиткова система з вибором місця?

Це ключова і найтехнічніше складна частина проекту. Стандартний модуль sale в Бітріксі заточений під товари в кошику — додав, оформив, оплатив. Квиток на конкретне місце в конкретному секторі — зовсім інша механіка.

Архітектура рішення: Кожен стадіон (зал, арена) описується SVG-файлом, в якому кожне місце — окремий елемент <rect> або <circle> з атрибутами data-sector, data-row, data-seat. SVG завантажується в браузер, JavaScript-обробник відповідає за інтерактив: підсвічування при наведенні, вибір місця кліком, відображення зайнятих місць сірим кольором.

Зберігання місць і станів: Створюється Highload-блок hl_stadium_seats з полями:

Для кожного матчу створюється таблиця бронювань — ще один Highload-блок hl_ticket_bookings:

Процес покупки покроково:

1. Користувач відкриває сторінку матчу, завантажується SVG-схема.
2. AJAX-запит до REST-контролера отримує масив зайнятих місць для даного матчу. JavaScript зафарбовує їх сірим і прибирає обробник кліку.
3. Користувач клікає на вільне місце — воно позначається як reserved у hl_ticket_bookings з таймштампом. Резерв живе 15 хвилин, потім cron-агент (CTicketReserveAgent) обнуляє прострочені.
4. Вибрані місця додаються до кошика модуля sale як товарні позиції. Для цього кожна цінова зона представлена торговою пропозицією в каталозі. Властивість кошика SEAT_INFO зберігає серіалізовані дані про конкретне місце.
5. Оформлення замовлення стандартне — sale.order.ajax з кастомізованим шаблоном. При успішній оплаті статус змінюється на sold, генерується PDF-квиток з QR-кодом через бібліотеку TCPDF.
6. QR містить підписаний токен (HMAC-SHA256), який перевіряється на вході сканером.

Конкурентний доступ — критичний момент. Два вболівальники не повинні забронювати одне місце. Рішення: UPDATE ... WHERE UF_STATUS = 'free' з перевіркою affected rows. Якщо повернулося 0 — місце вже зайняте, фронт показує сповіщення та перемальовує SVG.

Чому варто підключити турнірні таблиці через кастомний компонент?

Кастомний компонент custom:tournament.table агрегує дані з Highload-блоку матчів: рахує очки (3 за перемогу, 1 за нічию), різницю забитих/пропущених, сортує. Результат кешується з тегом tournament_{ID}, скидається при оновленні рахунку будь-якого матчу в цьому турнірі.

Для командних видів спорту з плей-оф компонент вміє рендерити сітку play-off (bracket) через SVG — пари, переможці, лінії зв'язків між раундами.

Профілі спортсменів

Детальна сторінка спортсмена включає: фото, біографію, кар'єрні досягнення (таймлайн через властивість інфоблоку «множинне» — клуб, роки, досягнення), статистику поточного сезону з Highload-блоку, галерею фото/відео з прив'язкою через CIBlockElement::GetProperty.

Для SEO — мікророзмітка schema.org/Person з athlete у полі jobTitle, прив'язка до schema.org/SportsTeam.

Фан-зона та мерч-магазин

Новинний розділ реалізується стандартним компонентом news.list / news.detail з доопрацьованим шаблоном. Фото- та відеогалерея — інфоблок з прив'язкою до матчів і спортсменів.

Мерч-магазин — повноцінний інтернет-магазин на модулі catalog + sale: футболки, шарфи, атрибутика. Торгові пропозиції за розміром і кольором, інтеграція з 1С для обліку залишків. Працює паралельно з квитковою системою, але в окремому типі інфоблоку, щоб каталог товарів не перетинався з квитками.

Інтеграція з квитковими операторами

Якщо клуб продає квитки не тільки через свій сайт, але й через Ticketland, Kassir.ru або аналогічні системи — потрібна синхронізація. Реалізується через REST API квиткового оператора: при бронюванні/продажу на стороні оператора webhook оновлює статус у hl_ticket_bookings. І навпаки — продаж на сайті відправляє дані оператору.

Cron-агент синхронізації запускається кожні 2 хвилини, щоб підтягнути зміни, які могли не дійти через webhook (мережеві збої, таймаути).

Етапи розробки

Що входить у роботу

• Повна документація щодо структури інфоблоків, HL-блоків, налаштувань кешування.
• Вихідний код усіх кастомних компонентів і агентів у репозиторії.
• Навчання редакторів: як додавати матчі, оновлювати статистику, завантажувати SVG-схеми.
• Гарантійна підтримка протягом 1 місяця після запуску — виправлення помилок, консультації.

Ми гарантуємо коректну роботу системи при пікових навантаженнях до 10 000 одночасних відвідувачів. Зв'яжіться з нами для оцінки проекту — ми підготуємо комерційну пропозицію. Отримайте консультацію з архітектури вашого спортивного сайту.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.