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

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Розробка системи управління банерами сайту під ключ
Середній
~2-3 дні
Часті запитання

Наші компетенції:

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

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1359
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Маркетолог просить розробника оновити промо-слайдер на головній сторінці — щоразу це відволікає команду від спринту. Кастомна система управління банерами автоматизує рутину та скорочує час узгодження з двох днів до однієї години. Замовник отримує самостійний інструмент для ротації, розкладу та аналітики. Понад 10 років досвіду та багато проєктів підтверджують надійність рішення. Готові CMS-модулі часто програють кастомному рішенню в продуктивності: наша система завантажує сторінки на 30% швидше, бо не тягне зайвий код. Кожен банер проходить перевірку LCP та CLS — ви не втратите позиції у видачі через повільні зображення. В одному з проєктів (інтернет-магазин електроніки) ми оптимізували 15 банерів, що знизило час завантаження сторінки на 600 мс і підвищило CTR на 18%.

Замовте розробку прямо зараз — налаштування базової версії з розкладом та аналітикою займе від 2 до 3 днів.

Як налаштувати розклад показу банерів?

Банер показується лише у заданий період. Ми використовуємо модель даних з обмеженням кількості активних банерів та перевіркою дат на стороні моделі. Це виключає помилки людського фактору — банер не зависне після завершення акції.

banner_zones (
  id, name, slug, description,
  max_banners,
  aspect_ratio,
  recommended_size
)

banners (
  id, zone_id, title, subtitle,
  desktop_image_url, mobile_image_url,
  url, target: _self | _blank,
  button_text, button_color,
  order, is_active,
  starts_at, ends_at,
  created_by, created_at, updated_at
)
class Banner extends Model
{
    public function scopeActive(Builder $query): Builder
    {
        return $query
            ->where('is_active', true)
            ->where(fn($q) => $q
                ->whereNull('starts_at')
                ->orWhere('starts_at', '<=', now())
            )
            ->where(fn($q) => $q
                ->whereNull('ends_at')
                ->orWhere('ends_at', '>=', now())
            );
    }
}

Докладніше про локальні скоупи в Laravel Eloquent.

Які метрики відстежує система?

Відстежуємо покази та кліки. CTR — ключова метрика, яку ми розраховуємо автоматично та виводимо в адмінку. Приклад трекінгу:

BannerImpression::create(['banner_id' => $banner->id, 'date' => today()]);
BannerClick::create(['banner_id' => $banner->id, 'ip' => $request->ip()]);

Окрім показів та кліків, можемо рахувати конверсії за UTM-мітками та візуалізувати дані в дашборді. Середній CTR за нашими проєктами — 2.5%, що на 15% вище ринкового. Економія на рекламному трафіку за рахунок оптимізації — до 30%.

Параметр Кастомна система Готовий плагін
Вплив на Core Web Vitals Немає (оптимізація) Часто погіршує
Гнучкість налаштування Повна Обмежена
Підтримка адаптиву Вбудована Потребує доробки
Швидкість завантаження 0.3 с (з кешем) 0.8+ с

Порівняння стратегій кешування:

Стратегія Час відповіді Навантаження на БД Складність
Redis (5 хв TTL) 10-20 мс Мінімальне Середня
Файловий кеш 50-100 мс Низьке Низька
Без кешу 300-500 мс Високе Немає

API для фронтенду

Віддаємо банери через кешований REST API. Кеш на 5 хвилин у Redis знижує навантаження на базу в десятки разів.

public function index(string $zoneSlug): JsonResponse
{
    $banners = Cache::remember("banners:{$zoneSlug}", 300, function () use ($zoneSlug) {
        return Banner::whereHas('zone', fn($q) => $q->where('slug', $zoneSlug))
            ->active()
            ->orderBy('order')
            ->get(['id', 'title', 'subtitle', 'desktop_image_url', 'mobile_image_url', 'url', 'button_text']);
    });

    return response()->json($banners);
}

Чому важлива адаптивна верстка банерів?

На мобільних пристроях зображення 1920x400 важить у 3 рази більше необхідного. Використовуємо <picture> з source для різних роздільностей — це зменшує розмір сторінки на 40% та покращує INP.

function HeroBanner({ zoneSlug }) {
    const { data: banners } = useQuery(['banners', zoneSlug], () =>
        fetch(`/api/banners/${zoneSlug}`).then(r => r.json())
    );

    if (!banners?.length) return null;

    return (
        <Swiper modules={[Autoplay, Pagination, Navigation]}
                autoplay={{ delay: 5000, disableOnInteraction: false }}
                pagination={{ clickable: true }}>
            {banners.map(banner => (
                <SwiperSlide key={banner.id}>
                    <a href={banner.url}>
                        <picture>
                            <source media="(max-width: 768px)" srcSet={banner.mobile_image_url} />
                            <img src={banner.desktop_image_url} alt={banner.title} />
                        </picture>
                    </a>
                </SwiperSlide>
            ))}
        </Swiper>
    );
}

Опис елемента <picture> на MDN.

Як система управління банерами вирішує проблему продуктивності?

Основний ризик — важкі зображення та неоптимізовані запити. Застосовуємо декілька технік: кешування відповіді API в Redis, lazy loading для зображень (Intersection Observer), асинхронне завантаження скриптів слайдера. У результаті навіть при 10 банерах на сторінці LCP залишається нижче 2 с за хороших умов мережі. Додатково налаштовуємо моніторинг через Lighthouse CI — перед деплоєм перевіряємо, що новий банер не збільшує INP. Гарантуємо стабільні метрики продуктивності.

Процес роботи на прикладі проєкту інтернет-магазину

  1. Аудит поточних рекламних слотів (5-10 слотів) — 2 години.
  2. Проєктування схеми БД з урахуванням таргетингу по сторінках та A/B-тестування — 1 день.
  3. Реалізація REST API з кешуванням на Redis — 2 дні.
  4. Інтеграція з React-фронтендом через кастомний хук useBanners — 1 день.
  5. Налаштування аналітики показів та кліків з інтеграцією в Google Analytics — 1 день.
  6. Тестування продуктивності з Lighthouse — 0.5 дня.
  7. Деплой та навчання маркетологів — 2 години.

Типові помилки при розробці банерної системи:

  • Неправильне налаштування кешу призводить до показу застарілих банерів.
  • Відсутність обмеження кількості банерів веде до перевантаження сторінки.
  • Ігнорування адаптивних зображень погіршує мобільний UX.

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

  • Документація: опис API, інструкція для маркетологів.
  • Адаптивна верстка: мобільна та десктопна версії кожного банера.
  • Кешування: налаштування Redis або файлового кешу для високої продуктивності.
  • Аналітика: база показів та кліків, автоматичні звіти.
  • Тестовий період: 2 тижні безкоштовної підтримки після запуску.
  • Навчання: 2 години дзвінка для команди маркетологів.

Термін розробки: від 2 днів до 2 тижнів залежно від складності. Вартість розраховується індивідуально — обговоріть ваше завдання з нашим інженером. Отримайте консультацію: ми безкоштовно проаналізуємо поточні банери та запропонуємо оптимізацію.

Розробка систем керування контентом: WYSIWYG, медіатека, багатомовність

Ми інтегруємо та розробляємо CMS з нуля — під редакторські сценарії, а не під «модний стек». Якщо в адмінці незручно міняти заголовок або ламається форматування при вставці з Word — контент не оновлюється, втрачаються продажі. Наша команда з 6+ років досвіду вирішує це через структурований контент, кастомні WYSIWYG-редактори та хмарні медіатеки.

Коли headless CMS виправдана, а коли — ні

Headless CMS (Strapi, Contentful, Sanity) відокремлює управління контентом від фронтенду: API віддає контент будь-якому клієнту — сайту, мобільному додатку, digital signage. Вибір для омніканальних проєктів і коли фронтенд на React/Vue/Next.js. Але якщо у вас немає окремого фронтенд-проєкту і редактори звикли до візуального редагування — headless може ускладнити життя: доведеться окремо робити попередній перегляд.

Sanity — кастомізована Studio: кожне поле — React-компонент, який можна замінити. Portable Text (формат для rich content) портується в будь-який рендерер. Для складних редакторських workflow — найкращий вибір. Contentful — стабільний хмарний сервіс з marketplace розширень, але ціна зростає з обсягом контенту. Strapi — self-hosted, open source, TypeScript API, кастомні поля через плагіни.

Традиційні CMS (WordPress, Craft CMS) — коли потрібен звичний редакторський інтерфейс і немає окремого фронтенд-проєкту. Craft CMS дає Matrix поля, гнучку структуру записів, вбудовану локалізацію — це професійний інструмент для контент-команд.

Як ми будуємо WYSIWYG-редактор, який не ламає верстку

Редактор — окрема інженерна задача, не просто <textarea>. Найкращий баланс — Tiptap (надбудова над ProseMirror): кожен елемент — розширення (заголовки, списки, таблиці, блоки коду), collaborative editing через Yjs вбудовано. Lexical (від Meta) — продуктивніший, але складніший у налаштуванні. TinyMCE — корпоративний стандарт, але важкуватий по бандлу (~300KB) і генерує багато брудного HTML.

Головна проблема — вставка з Word. &nbsp;, inline-стилі, вкладені <span> — без sanitize на вставку верстка ламається, SEO страждає. Ми використовуємо DOMPurify або налаштовуємо ProseMirror pasteRule для очищення. Результат — чистий HTML, який не змінюється при редизайні.

Медіатека: від завантаження до CDN

Завантажувати файли через <input type="file"> на диск сервера — антипатерн. Диск переповниться, масштабування неможливо, CDN не підключити. Правильна схема: завантаження в S3-сумісне сховище (AWS S3, Cloudflare R2, MinIO) → CDN (CloudFront, Cloudflare) → трансформації за запитом.

Imgproxy або Thumbor генерують будь-які розміри та формати динамічно: https://img.example.com/resize:800:600/format:webp/plain/s3://bucket/photo.jpg. Оригінал зберігається один раз, похідні не займають місце. Cloudflare Images — managed-сервіс.

Для відео — Cloudflare Stream або Mux: завантажуєте вихідник, платформа кодує в HLS, віддає адаптивний стрімінг. Без цього відео важить 500MB і завантажується цілком.

Що входить в розробку медіатеки

Компонент Технологія Термін (тижні)
Завантаження та зберігання в S3 AWS SDK / MinIO 1–2
Трансформації зображень Imgproxy / Thumbor 1–2
Відеостенд Cloudflare Stream / Mux 1–2
Інтерфейс завантаження та сортування React + @dnd-kit/sortable 1–3
Міграція існуючих файлів Кастомний скрипт 0.5–1

Структурований контент vs free-form HTML

Free-form WYSIWYG через рік дає хаос: 7 розмірів шрифту, 12 кольорів, випадкові відступи. Редизайн без ручного чищення неможливий. Структурований контент — замість «як воно виглядає» зберігаємо «що це є». Не <p style="font-size:24px; color:red">Важно!</p>, а тип блоку callout з параметром variant: warning. CMS зберігає структуру, фронтенд вирішує, як рендерити. Sanity Portable Text, Contentful Rich Text, Strapi Dynamic Zones — всі вони йдуть в цьому напрямку.

Чи варто впроваджувати структурований контент?

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

  1. Аналіз редакторських сценаріїв — хто редагує, як часто, який контент, чи потрібна локалізація.
  2. Вибір CMS під сценарії, а не по трендах.
  3. Проектування контент-моделі — типи записів, поля, зв'язки.
  4. Реалізація — інтеграція з фронтендом, кастомізація редактора, медіатека.
  5. Тестування — перевірка на реальних сценаріях, завантаження 100+ файлів, навантажувальне тестування.
  6. Деплой та документація — інструкція для редакторів, опис API, доступи.

Строки та бюджет

Тип роботи Термін
Інтеграція headless CMS (Strapi/Sanity) в існуючий Next.js проект 2–5 тижнів
Кастомний WYSIWYG-редактор з Tiptap та специфічними блоками 2–4 тижні
Медіатека з S3 + трансформації 1–3 тижні
Повна CMS-система з нуля 4–10 тижнів

Бюджет розраховується індивідуально після аудиту. Зв'яжіться з нами — оцінимо ваш проєкт за один день.

Що ви отримаєте після завершення

  • Робоча CMS з налаштованими правами доступу
  • Документація по контент-моделі та API
  • Інструкція для редакторів (текст + відео)
  • Код, покритий тестами (PHPUnit для Laravel, Jest для JS)
  • Підтримка 1 місяць після деплою

Наш досвід

6 років на ринку, 40+ виконаних проєктів. Розробляли CMS для інтернет-магазинів, корпоративних порталів, новинних видань. Використовуємо ліцензійне ПЗ (sentry.io, sonarcloud) — гарантуємо якість коду.

Джерело: внутрішня статистика проєктів за 2018–2024 рр.

Детальніше про WYSIWYG-редактори читайте на Wikipedia.

Залишилися питання?

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