Адаптивная и резиновая вёрстка: в чём разница

01

Почему «мобильный макет есть» ещё не означает адаптивность

Когда сайт называют адаптивным, часто имеют в виду только наличие отдельного макета для телефона. Это неполное требование. Пользователь приходит не на абстрактный «мобильный сайт», а на страницу с конкретной шириной, высотой, плотностью пикселей, настройками масштаба и скоростью сети. Между экраном 390 px и ноутбуком 1440 px лежит множество состояний, в которых интерфейс может сломаться: карточки становятся слишком узкими, фильтр перекрывает каталог, заголовок не помещается, а кнопка отправки формы уезжает за пределы экрана.

Адаптивная вёрстка описывает, как страница меняет композицию при заданных условиях. В нужный момент сетка из четырёх карточек становится двумя, горизонтальное меню превращается в кнопку, второстепенная колонка переносится ниже основного контента. Резиновая вёрстка решает другую задачу: элементы получают относительную ширину и плавно расширяются или сужаются внутри допустимых границ. На современном сайте эти подходы обычно работают вместе, но заменять один другим нельзя.

Для владельца сайта на 1С-Битрикс это вопрос не терминологии, а результата. Если на телефоне нельзя открыть меню, выбрать вариант товара, заполнить обязательное поле или увидеть ошибку формы, теряются обращения и заказы. Если контент на промежуточной ширине выходит за границу контейнера, растёт число отказов и появляются проблемы при обновлении шаблона или подключении нового компонента.

Поэтому задача подрядчику должна описывать не фразой «сделайте адаптив», а набором экранов, страниц и действий. Отдельно зафиксируйте, какие блоки перестраиваются, что скрывается, что остаётся доступным и какие данные нельзя потерять при смене ширины окна.

03

Адаптивная и резиновая вёрстка: отличия на реальном интерфейсе

Резиновая сетка строится на относительных размерах: процентах, единицах fr, ограничениях min-width и max-width. Контейнер может занимать 100% доступной области до заданного максимума, а две колонки — делить свободное место в пропорции. Такой подход хорошо работает для текста, галереи, карточек и таблиц, если содержимое способно сжиматься без потери смысла. Но при сильном уменьшении ширины сама по себе сетка не решает, что делать с длинным меню, несколькими фильтрами или сложной формой.

Адаптивная вёрстка вводит правила переключения. На одной ширине фильтр расположен слева, на другой открывается в панели; в десктопной шапке видны контакты и разделы, на телефоне остаются логотип, поиск и меню. Важно, что изменяется не только размер, но и приоритет информации. Именно поэтому дизайнеру, маркетологу и разработчику нужно согласовать сценарий, а не ограничиться значениями ширины.

В проектах ICONICA особенно внимательно проверяют формы: поле телефона, согласие на обработку данных, UTM-параметры и сообщение об успешной отправке должны оставаться доступными на каждом целевом экране. Если скрыть блок ради компактности, но не перенести его функцию в другой маршрут, пользователь не оставит заявку, а CRM не получит источник обращения.

04

Где заканчивается резиновая сетка и начинается адаптивный сценарий

Проще всего увидеть разницу на типовых блоках коммерческого сайта. Текстовый контейнер можно сделать резиновым: он будет расширяться до разумного максимума, а длина строки останется удобной для чтения. Но каталог с фильтрами требует решения о структуре. Если просто сжимать три колонки, у товара исчезает место для цены, статуса и кнопки. На телефоне лучше показать одну или две карточки в ряд, а фильтры собрать в выезжающую панель с понятными кнопками «Применить» и «Сбросить».

Отдельное внимание — компонентам Битрикс, которые подключены из разных шаблонов. Хлебные крошки, умный фильтр, корзина, личный кабинет и формы могут использовать собственные стили. Локально аккуратный блок способен сломать страницу на ширине 768 px, потому что его минимальная ширина не учитывает соседние элементы. Проверять нужно готовую страницу с реальными названиями товаров, ошибками валидации и заполненными полями, а не пустой демонстрационный макет.

Ниже — ориентир, какой тип решения ожидать от команды. Это не фиксированный набор брейкпоинтов: их выбирают по моменту, когда контент перестаёт помещаться, а не по названию конкретной модели телефона.

05

Какие брейкпоинты согласовать до начала разработки

Не стоит требовать от команды произвольное число состояний: это увеличивает стоимость и не гарантирует удобство. Сначала определите реальные маршруты и устройства аудитории. Данные можно посмотреть в Яндекс Метрике или другой системе аналитики: долю мобильного трафика, популярные разрешения, страницы входа и действия перед отправкой формы. Но аналитика не отменяет базовой проверки на малых, средних и широких экранах — новые устройства и нестандартные окна браузера всё равно появятся.

Обычно достаточно согласовать диапазоны для маленького телефона, крупного телефона, планшета, небольшого ноутбука и широкого desktop. В каждом диапазоне фиксируют не только ширину контейнера, но и поведение конкретных узлов: шапки, первого экрана, карточек, таблиц, формы, попапов, корзины и футера. Для интернет-магазина обязательно добавьте страницу оформления заказа: ошибки здесь дороже, чем дефект в информационной статье.

Брейкпоинт нужен в тот момент, когда текущая композиция перестаёт выполнять задачу. Например, меню уже не читается или карточка товара вынуждает пользователя горизонтально прокручивать страницу. Разработчик может реализовать правила через CSS media queries, а в некоторых случаях — дополнить их скриптом для сложного меню. Техническая реализация вторична: критерием остаётся работоспособный маршрут.

06

Как принять адаптивную вёрстку без знания CSS

Приёмка не должна сводиться к визуальному сравнению двух скриншотов. Откройте тестовый контур в браузере, включите режим устройства и последовательно пройдите путь посетителя. Начните не с главной, а со страниц, которые приводят деньги или обращения: рекламный лендинг, каталог, карточка, форма, корзина. Затем повторите ключевые действия на реальном телефоне: эмулятор удобен для ширины, но не всегда показывает поведение клавиатуры, прокрутки и системных окон.

Маркетологу важно проверить данные, а не только пиксели. Откройте форму по рекламной ссылке с UTM-метками, отправьте тестовую заявку и убедитесь, что в CRM есть контакт, источник, страница, метки и корректное время создания. Если при адаптации форма переехала в попап, разработчик мог изменить обработчик, идентификатор или скрытые поля. Такой дефект внешне незаметен, но ломает отчётность и обработку лидов.

Для технических деталей по шаблонам и компонентам можно ориентироваться на документацию 1С-Битрикс по разработке, однако владельцу сайта не нужно оценивать код. Его задача — зафиксировать маршрут, условия и наблюдаемый результат. Все найденные замечания оформляйте со ссылкой на страницу, шириной экрана, браузером, шагами и фактическим поведением.

1. 1

   Соберите маршруты. Выберите пять-семь действий, влияющих на заявку, заказ или поиск информации.

2. 2

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

3. 3

   Заполните интерфейс. Используйте длинные тексты, ошибки формы, пустые состояния и несколько товаров в корзине.

4. 4

   Отправьте тестовую заявку. Проверьте создание сущности в CRM, UTM, страницу входа и ответ пользователю.

5. 5

   Зафиксируйте дефекты. Укажите URL, ширину, устройство, шаги воспроизведения и ожидаемый результат.

07

Ошибки, которые появляются после публикации

Распространённая ошибка — тестировать только новый дизайн, но не проверить существующие сценарии CMS. После обновления шаблона могут некорректно отобразиться новости, страницы с длинными заголовками, результаты поиска, системные сообщения и формы, которые добавлялись отдельно от основного дизайна. На Битрикс это особенно заметно, когда у компонентов есть локальные шаблоны, а стили подключаются из нескольких файлов.

Вторая проблема — невидимый горизонтальный скролл. Иногда он создаётся одним широким элементом: таблицей, слайдером, промокодом, изображением или блоком с фиксированной минимальной шириной. Пользователь не всегда замечает причину, но кнопка может оказаться за экраном. Проверяйте страницу прокруткой вправо на каждом диапазоне и смотрите, не обрезаются ли тени, подсказки и выпадающие списки.

Третья ошибка связана с производительностью. Нельзя компенсировать неудобную мобильную структуру загрузкой тяжёлого desktop-баннера и последующим скрытием через CSS. Изображения, шрифты и скрипты всё равно могут загрузиться. После вёрстки проверьте скорость ключевых страниц и размер медиафайлов, особенно если рекламный трафик идёт преимущественно со смартфонов.

08

Когда достаточно доработки, а когда нужен новый адаптивный дизайн

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

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

Не принимайте решение только по возрасту сайта. Даже свежий проект может быть неудобным, если его проверяли лишь по статичным макетам. И наоборот, старый сайт иногда достаточно привести в порядок точечными изменениями. Полезный входной материал для подрядчика — выгрузка популярных устройств, перечень проблемных страниц, данные по конверсии и примеры замечаний от отдела продаж или клиентов.

09

Какое решение принять

Резиновая вёрстка полезна там, где контенту достаточно плавно менять ширину. Адаптивная вёрстка необходима там, где при уменьшении экрана меняется сам способ взаимодействия: навигация, каталог, фильтры, форма или оформление заказа. Практически любой коммерческий сайт использует оба подхода, поэтому спорить, какой из них «лучше», не нужно. Важно определить, какой элемент и при каких условиях должен перестроиться.

Начните с проверки ключевых маршрутов на реальных ширинах, а не с обсуждения технологий. Зафиксируйте страницы, действия, контрольные диапазоны, передачу данных в CRM и критерии отсутствия визуальных дефектов. Если проблема ограничена несколькими компонентами, подготовьте список точечных доработок. Если мобильный путь не складывается в понятный сценарий, сначала нужен адаптивный дизайн и прототип.

Подключайте подрядчика, когда нужно связать аудит интерфейса с шаблонами 1С-Битрикс, не сломать формы и аналитику, а также проверить изменения на тестовом контуре. Это снижает риск ситуации, когда обновлённая страница выглядит аккуратно на макете, но теряет заявки после публикации.