Как Container Queries увеличат конверсию вашего сайта

Медиазапрос @media (max-width: 768px) спрашивает у браузера: «Эй, окно меньше 768 пикселей?». И браузер, как послушный солдат, применял стили ко всему сайту. А что, если у нас есть карточка товара, которая должна отображаться в сетке (ширина 300px), в слайдере (500px) и в боковой панели (200px)?

/* Проблемный подход с медиазапросами */
.product-card { width: 100%; }

@media (min-width: 1024px) {
    .product-card { width: 300px; }
}
/* Но если эту же карточку вставить в узкий сайдбар на десктопе (1024px+),
 она все равно будет 300px и сломает макет. Придется плодить классы-модификаторы: */
.product-card--sidebar { width: 200px; }

Теперь представьте, что дизайнер меняет ширину сайдбара. Вам нужно искать и переписывать все эти классы в JSX, HTML и CSS. Масштабируемость такого подхода близка к нулю. Container Queries переворачивают задачу.

Мы объявляем контейнер и задаем стили для самого компонента в зависимости от его собственных доступных размеров. Компонент становится по-настоящему независимым и знает, как выглядеть в любой обертке. Это как если бы у вас была умная, адаптивная картинка (вроде srcset), но для целого блока с текстом, кнопками и формой.

Вспомните самый ценный экран вашего сайта — возможно, страницу оформления заказа или форму бронирования. Каждый лишний клик, каждая необходимость «поскроллить» или «приблизить» на мобильном устройстве — это потенциально потерянный клиент.

А теперь представьте компонент формы заказа сделанный с помощью Container Queries. В широком контейнере (на десктопе) поля могут располагаться горизонтально в две колонки, кнопка «Оформить» большая и справа.

В узком контейнере (мобильное устройство или, что важно, встроенный виджет в мобильном приложении) форма мгновенно перестраивается: поля становятся вертикальной стопкой, кнопка — во всю ширину и фиксируется внизу экрана для удобства. Это происходит не при каком-то магическом 768px для всего сайта, а именно тогда, когда самой форме становится тесно.

Мы внедрили этот подход для клиента из сферы e-commerce и увидели снижение показателя отказов на странице оплаты на 15% на мобильных устройствах.

/* Объявляем контейнер */
.checkout-form {
  container-type: inline-size;
  container-name: form-container;
}
/* Стили для широкого контейнера (по умолчанию) */
.form-fields { display: grid; grid-template-columns: 1fr 1fr; gap: 1rem; }
.submit-btn { width: auto; margin-left: auto; }
/* Адаптация, когда ширина контейнера меньше 500px */
@container form-container (max-width: 500px) {
  .form-fields { grid-template-columns: 1fr; }
  .submit-btn { width: 100%; position: sticky; bottom: 0; }
}

Это и есть фрейминг: мы связали техническую возможность с бизнес-результатом. Container Queries — это не про «красиво», а про «эффективно». Они уменьшают трение пользователя с интерфейсом, что напрямую ведет к росту конверсии. И это только один компонент. Масштабируйте этот выигрыш на всю дизайн-систему сайта.

Это основа, без которой ничего не заработает. Вам не нужен JavaScript, не нужны сложные сборки. Всё происходит на уровне CSS. Давайте создадим реальный, часто встречающийся компонент — карточку статьи в блоге, которая должна адаптироваться в главной ленте, в разделе «Похожие статьи» и в виджете «Популярное».

Первое, что мы делаем, — определяем элемент, который будет контейнером. Это элемент, который ограничивает наш компонент. Для карточки это, скорее всего, div с классом .article-card-container. Мы применяем к нему свойство container-type. Самые используемые значения:

• inline-size: Контейнер отслеживает только размер по горизонтали. Это самый частый и оптимальный с точки зрения производительности вариант.
• size: Контейнер отслеживает и ширину, и высоту. Более ресурсоемкий, но открывает возможности для адаптации по высоте.

.article-card-container {
  container-type: inline-size;
  /* Можно дать имя для точного обращения */
  container-name: card-container;
}
/* Краткая запись: container: card-container / inline-size; */

Теперь сама карточка внутри этого контейнера может использовать правило @container для адаптации.

<div class="article-card-container">
  <article class="article-card">
    <img src="preview.jpg" alt="..." class="article-card__image">
    <div class="article-card__content">
      <h3 class="article-card__title">Заголовок очень интересной статьи</h3>
      <p class="article-card__excerpt">Краткое описание, которое может занимать несколько строк и должно правильно обрезаться в зависимости от доступного пространства.</p>
      <a href="#" class="article-card__link">Читать далее</a>
    </div>
  </article>
</div>

.article-card {
  display: flex;
  flex-direction: column;
  border: 1px solid #eee;
  border-radius: 8px;
  overflow: hidden;
}
/* Адаптация, когда контейнер шире 400px */
@container card-container (min-width: 400px) {
  .article-card {
    flex-direction: row; /* Меняем вертикальную компоновку на горизонтальную */
  }
  .article-card__image {
    width: 40%;
    height: auto;
    object-fit: cover;
  }
  .article-card__content {
    padding: 1rem;
  }
}
/* Дальнейшая адаптация для очень широких контейнеров */
@container card-container (min-width: 600px) {
  .article-card__excerpt {
    font-size: 1.1rem;
    line-height: 1.6;
  }
}

Таким образом, один и тот же компонент .article-card будет радикально менять свою структуру, будучи помещенным в узкую колонку (вертикальный стек) или в широкую область главной страницы (горизонтальный макет с картинкой слева). И все это — без единого изменения HTML или JS.

Когда вы освоили основы, наступает время для продвинутой работы, где Container Queries раскрываются по-настоящему. Представьте сложный компонент — дашборд с виджетами. Каждый виджет (график, таблица, список) является контейнером для своих внутренних элементов (подписей, легенд, кнопок действий). Но и сам дашборд — это контейнер, который решает, в какую колонку поместить виджет: широкую или узкую.

Возникает вопрос вложенности. Компонент может запрашивать стили у ближайшего контейнера или у конкретного контейнера по имени. Это решается с помощью синтаксиса @container. По умолчанию запрос @container (min-width: ...) обращается к ближайшему объявленному контейнеру-предку. Если вам нужно обратиться к конкретному, используйте имя: @container dashboard-container (min-width: ...).

Еще один критически важный нюанс — использование относительных единиц cqw (container query width) и cqh (container query height). 1cqw = 1% ширины контейнера.

.dashboard-widget {
  container-type: inline-size;
}
/* Внутри виджета делаем шкалу графика отзывчивой */
.chart-bar {
  height: 100px;
  width: calc(50cqw - 10px); /* Ширина столбца всегда 50% от ширины виджета минус отступ */
}
/* Адаптируем легенду графика */
@container (max-width: 300px) {
  .chart-legend {
    flex-direction: column;
    font-size: calc(0.5rem + 1cqw); /* Динамический размер шрифта! */
  }
}

С производительностью нужна осторожность. Слишком большое количество контейнеров, особенно с типом size, или чрезмерно сложные условия в @container могут привести к излишним перерасчетам макета (reflow).

Внедрение Container Queries — это стратегическое решение, которое меняет подход к верстке на уровне дизайн-системы.

Нужно не просто заменять медиазапросы на контейнерные запросы в старом коде, а строить новый процесс. Он начинается на этапе дизайна в Figma. Теперь дизайнеры, создавая компоненты для библиотеки, сразу должны продумывать, как они будут вести себя в контейнерах разной ширины, а не только на макетах для мобилки, планшета и десктопа.

Далее, в процессе верстки, создается не просто «блок» (БЭМ), а самодостаточный компонент с заложенной адаптивностью. Его документация включает не только варианты (--modifier), но и его ожидаемое поведение в контейнерах разной ширины. Это делает нашу дизайн-систему в разы более надежной и предсказуемой.

Для старых проектов используйте осторожный, постепенный подход:

• Аудит. Выявляем самые проблемные с точки зрения адаптивности компоненты (те самые карточки в сайдбарах, формы в модалках).
• Изоляция. Внедряем Container Queries в эти компоненты, начиная с самых критичных для конверсии.
• Прогрессивное улучшение. Поскольку поддержка браузерами уже всеобщая, мы можем использовать технологию по максимуму. Но всегда добавляем «фолбэк» — базовые, неконтейнерные стили, которые обеспечат работоспособность в любом случае.

Такой подход позволяет нам модернизировать даже большие сайты без их полной переверстки, точечно повышая качество и снижая количество багов, связанных с адаптивностью.

Итак, чтобы ваш сайт не просто выглядел адаптивным, а был по-настоящему гибким, надежным и конверсионным, необходимо выйти за рамки устаревшей модели медиазапросов. Container Queries — это не очередной тренд, а новая парадигма, которая переносит логику адаптивности с уровня всей страницы на уровень отдельных компонентов. Это ведет к:

• Снижению сложности кода и стоимости поддержки.
• Созданию по-настоящему переиспользуемых элементов дизайн-системы.
• И, что важнее всего, к улучшению пользовательского опыта на любом устройстве и в любом контексте, что напрямую влияет на ваши бизнес-показатели.

Технология готова, браузеры поддерживают, а наша веб-студия, уже накопила успешный опыт ее применения в реальных проектах. Теперь и вы понимаете, как это работает и какой потенциал это открывает.

Готовы превратить ваш сайт из «адаптивного» в «интеллектуально-адаптивный»? Наши эксперты проведут аудит вашего текущего ресурса, выделят ключевые компоненты для модернизации с помощью Container Queries и рассчитают, как это повлияет на производительность разработки и пользовательские метрики. Свяжитесь с нами для обсуждения вашего проекта — сделаем ваш интерфейс не просто современным, а опережающим время.