Адаптивный дизайн сайта: подходы, брейкпоинты, сетка и проверка

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

Хороший адаптив закладывается на этапе проектирования, а не верстки, и касается всех, кто делает сайт: дизайнера, который описывает правила перестройки, разработчика, который переносит их в CSS, и менеджера, который принимает работу. Если вы планируете новый сайт силами подрядчика, на старте стоит договориться, что адаптивность входит в объём работ, а не оплачивается отдельной строкой: когда вы решаете заказать создание адаптивного сайта, просите показать не только десктопные макеты, но и описание поведения ключевых экранов на узкой ширине, а также порядок тестирования на устройствах.

Ниже — практическое руководство: какие бывают подходы к адаптивности, как выбрать брейкпоинты, как устроить сетку и что делать с навигацией, таблицами и формами, как подготовить макет в Figma и проверить результат. Материал дополняет наши разборы сетки и системы отступов 4/8 pt и типографической шкалы интерфейса — без них адаптив превращается в набор случайных исключений.

Что такое адаптивный дизайн и чем он отличается от отзывчивого

Адаптивный дизайн сайта — это подход, при котором одна и та же страница корректно отображается и удобна в использовании на экранах любой ширины: от 320 пикселей у компактного смартфона до 2560 и больше у широкого монитора. Контент, адреса и код остаются общими, а раскладка, размеры и порядок блоков меняются по заранее описанным правилам.

В русскоязычной практике под словом «адаптив» смешивают несколько технически разных подходов. Их полезно различать, потому что от выбора зависит, сколько макетов рисовать и как верстать.

На практике почти все современные сайты делают комбинированно: гибкая сетка с ограничением максимальной ширины контента и несколько брейкпоинтов, на которых меняется раскладка. Именно это сегодня и называют адаптивным дизайном, а разница между «adaptive» и «responsive» важна скорее для обсуждения конкретных блоков: например, карточки каталога тянутся, а шапка переключается между двумя состояниями.

С чего начинать: mobile first или desktop first

Mobile first — это порядок проектирования, при котором сначала решается самый узкий экран, а затем интерфейс расширяется. Подход популяризировал Люк Вроблевски ещё в начале 2010-х, и с тех пор аргументы в его пользу только окрепли.

• Узкий экран заставляет расставить приоритеты. На 360 пикселях помещается один главный блок, и команда вынуждена договориться, что действительно важно. На широком экране эти решения просто масштабируются.
• Добавлять проще, чем убирать. Расширяя раскладку, вы добавляете колонки и вторичную информацию. Сужая — начинаете прятать контент, и пользователь телефона получает урезанную версию.
• Поисковики оценивают мобильную версию. Google индексирует сайты по мобильной версии страницы, поэтому скрытый на телефоне текст фактически теряет вес.
• CSS получается чище. Базовые стили описывают мобильную раскладку, а медиазапросы с min-width только добавляют усложнения для широких экранов.

Desktop first оправдан, когда основная работа идёт на больших экранах: сложные админки, аналитические дашборды, редакторы, B2B-системы, где на телефоне нужен лишь просмотр статусов. Но и в этом случае полезно сразу зафиксировать, какие сценарии обязаны работать на мобильном, а какие можно упростить, — иначе мобильную версию придётся проектировать заново.

Какие брейкпоинты выбрать

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

Тем не менее стартовый набор нужен, чтобы дизайнер и разработчик говорили на одном языке. Ориентиры для большинства сайтов в 2026 году:

Такая разбивка близка к классам размеров окна, которые описывает Material Design 3: компактный до 600 dp, средний до 840 dp, расширенный до 1200 dp и большие классы выше. Ориентируйтесь на ширину окна, а не на тип устройства: планшет в режиме разделённого экрана ведёт себя как телефон, а телефон в горизонтальной ориентации — как маленький планшет.

Помимо основных точек допустимы локальные: если таблица тарифов ломается на 880 пикселях, поставьте для неё отдельное правило, не трогая всю сетку. Ещё удобнее — контейнерные запросы (@container), которые поддерживаются всеми основными браузерами: компонент перестраивается в зависимости от ширины своего контейнера, а не всего окна, и одна карточка одинаково работает в узкой боковой колонке и в широкой ленте.

Как устроить сетку, отступы и типографику

Колоночная сетка — скелет адаптивного макета. Число колонок растёт вместе с шириной: 4 на телефоне, 8 на планшете, 12 на десктопе. Блоки описываются не в пикселях, а в колонках: карточка занимает 4 колонки из 4 на телефоне, 4 из 8 на планшете и 3 из 12 на десктопе — так в ряду оказывается одна, две и четыре карточки.

Три параметра сетки, которые нужно зафиксировать для каждого диапазона:

1. Поля (margins) — отступ контента от краёв экрана. На телефоне 16–20 пикселей, дальше больше. Слишком узкие поля делают текст неудобным для чтения у края экрана, особенно на устройствах со скруглёнными углами.
2. Промежутки (gutters) — расстояние между колонками. Обычно 16 пикселей на мобильном и 24–32 на десктопе.
3. Максимальная ширина контейнера — без неё на мониторе 2560 пикселей строки текста растягиваются на всю ширину и читать их невозможно. Для текстовых блоков держите длину строки в пределах 60–80 знаков.

Отступы между блоками тоже масштабируются, но не пропорционально. Удобно завести шкалу на базе 4 или 8 пикселей и для каждого диапазона выбирать шаг: например, секции разделяются 48 пикселями на телефоне и 96 на десктопе. Значения стоит оформить как токены, чтобы дизайн и код ссылались на одни и те же имена, — подробно об этом в статье о дизайн-токенах.

Типографика в адаптиве меняется в первую очередь в заголовках: H1 в 56 пикселей, уместный на десктопе, на телефоне займёт полэкрана. Основной текст обычно держат в 16–18 пикселях на всех экранах. Для плавного масштабирования заголовков используют функцию clamp() в CSS, задавая минимальный, предпочтительный и максимальный размер, — тогда шрифт растёт вместе с окном без резких скачков на брейкпоинтах. Размеры шрифта задавайте в rem, чтобы интерфейс уважал настройки размера текста в браузере.

Как адаптировать навигацию, таблицы, формы и изображения

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

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

Таблицы. Сравнительную таблицу с пятью колонками на телефоне можно превратить в карточки, где каждая строка — отдельный блок с подписями, или оставить горизонтальную прокрутку только внутри таблицы, закрепив первую колонку. Прокрутка всей страницы вбок недопустима.

Формы. На узком экране поля встают в одну колонку на всю ширину, подпись — над полем, а не слева. Указывайте правильный тип поля и inputmode, чтобы открывалась нужная клавиатура, и помните, что экранная клавиатура закрывает до половины экрана: сообщение об ошибке и кнопка отправки не должны оказаться под ней. Подробные правила — в статье о формах, которые заполняют.

Касание вместо курсора. На сенсорных экранах нет наведения, поэтому всё, что появляется по hover — подсказки, кнопки в карточке, подменю, — должно быть доступно иначе. Интерактивные элементы делайте достаточно крупными: WCAG 2.2 требует минимум 24 на 24 CSS-пикселя, а гайдлайны Apple и Material рекомендуют 44 pt и 48 dp. Разбор критериев — в нашей статье о WCAG 2.2 на практике.

Изображения. Отдавайте браузеру несколько размеров через srcset и sizes, чтобы телефон не скачивал картинку для 4K-монитора. Если на узком экране важна другая композиция — например, крупный план вместо широкого кадра, — используйте элемент picture с разными источниками. Всегда указывайте width и height, чтобы страница не прыгала при загрузке.

Как собрать адаптивный макет в Figma

Адаптивный макет — это не три независимых файла, а набор компонентов, которые корректно растягиваются и перестраиваются. Порядок работы, который экономит больше всего времени:

1. Настройте сетки для каждого диапазона. Создайте фреймы 360, 768 и 1440 пикселей с колоночными сетками: 4, 8 и 12 колонок с нужными полями и промежутками. Сохраните их как стили сетки.
2. Собирайте всё на Auto Layout. Карточки, кнопки, списки и секции должны тянуться по ширине контейнера (Fill container) и сами пересчитывать высоту. Проверка простая: потяните фрейм за край — ничего не должно наезжать и обрезаться.
3. Используйте переменные и режимы. Отступы, размеры заголовков и поля сетки оформите как переменные с режимами для мобильного, планшетного и десктопного вида. Переключение режима фрейма тогда меняет все значения сразу.
4. Делайте варианты компонентов под диапазоны. Шапка с бургером и шапка с горизонтальным меню — два варианта одного компонента, а не два разных компонента.
5. Покажите поведение между точками. Для ключевых экранов добавьте промежуточную ширину — например, 1024 или 600 пикселей — и аннотации: что тянется, что переносится, что меняет представление.
6. Проверьте на телефоне. Откройте прототип в мобильном приложении Figma: на реальном экране сразу видно, что текст мелковат, а кнопки слишком близко друг к другу.

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

Что передать в разработку

Большинство расхождений между макетом и вёрсткой адаптива возникает не из-за небрежности разработчика, а из-за того, что поведение просто не было описано. В пакет передачи стоит включить:

• список брейкпоинтов и параметры сетки для каждого: колонки, поля, промежутки, максимальная ширина контейнера;
• токены отступов и типографики с значениями для каждого диапазона или с параметрами clamp();
• для каждого ключевого компонента — какие приёмы применяются: что переносится в колонку, что меняет представление, что уходит в меню;
• порядок блоков на мобильном, если он отличается от визуального порядка на десктопе, — с оглядкой на то, что порядок в разметке должен оставаться логичным для клавиатуры и скринридера;
• требования к изображениям: соотношения сторон, кадрирование, набор размеров;
• минимальную поддерживаемую ширину — обычно 320 пикселей.

Со стороны вёрстки проверьте базовые вещи: на странице есть мета-тег viewport с width=device-width, initial-scale=1, масштабирование пользователем не запрещено, размеры заданы в относительных единицах, а раскладка строится на CSS Grid и Flexbox, а не на абсолютном позиционировании. Полный список того, что ещё должно быть в пакете передачи, — в нашем чек-листе handoff.

Как проверить адаптивность

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

1. Плавное сужение окна. Медленно сожмите окно браузера от максимальной ширины до 320 пикселей. Ищите не только точки брейкпоинтов, но и промежутки между ними: там чаще всего появляются наезды и обрезки.
2. Реальные устройства. Как минимум один компактный Android-смартфон, один iPhone и планшет. Пройдите на них ключевые сценарии целиком: найти услугу, заполнить форму, оформить заказ.
3. Горизонтальная ориентация. Телефон, повёрнутый горизонтально, — это экран высотой около 360 пикселей. Липкая шапка и баннер cookies могут занять почти всю высоту.
4. Масштаб 200 и 400 %. Критерий WCAG 1.4.10 «Перекомпоновка» требует, чтобы контент читался при ширине 320 CSS-пикселей без горизонтальной прокрутки — это эквивалент масштаба 400 % на экране шириной 1280 пикселей. Увеличьте масштаб и убедитесь, что ничего не обрезано.
5. Увеличенный системный шрифт. Включите крупный текст в настройках телефона: кнопки с фиксированной высотой и подписи в одну строку часто ломаются первыми.
6. Скорость на мобильной сети. Проверьте страницу в PageSpeed Insights и в режиме замедленной сети: тяжёлые изображения и видео на фоне — частая причина плохого LCP на телефонах.

Частые ошибки

1. Мобильную версию делают в конце. Десктопный макет ужимают, и на телефоне получается перегруженный экран со скрытыми блоками.
2. Контент прячут на мобильном. Текст, таблицы и характеристики, скрытые через display: none, недоступны пользователю и теряют вес в поиске.
3. Брейкпоинты под конкретные модели. Точки 375 и 414 пикселей устаревают с каждым новым поколением смартфонов. Ориентируйтесь на диапазоны и контент.
4. Горизонтальная прокрутка страницы. Обычно её вызывает один элемент: широкая таблица, изображение без ограничения ширины, длинный адрес или слово без переноса.
5. Функции только по наведению. Подсказки и кнопки, появляющиеся по hover, на сенсорном экране недоступны.
6. Мелкие цели касания. Ссылки в тексте и иконки размером 16 пикселей, стоящие вплотную друг к другу.
7. Запрет масштабирования. user-scalable=no в мета-теге лишает слабовидящих пользователей возможности увеличить текст.
8. Липкие элементы съедают экран. Шапка, нижняя панель, чат и баннер cookies вместе оставляют для контента треть высоты.
9. Одна картинка на все экраны. Телефон скачивает изображение на 3 мегабайта, а важная часть кадра обрезается.
10. Проверка только в эмуляторе. Проблемы с клавиатурой, касаниями и ориентацией находят пользователи, а не команда.

Чек-лист адаптивного дизайна

1. Определено, какой контент и какие сценарии обязательны на любом экране.
2. Выбраны диапазоны ширины и брейкпоинты, локальные точки поставлены по контенту.
3. Для каждого диапазона заданы колонки, поля, промежутки и максимальная ширина контейнера.
4. Отступы и типографика оформлены токенами, заголовки масштабируются через clamp(), шрифты в rem.
5. Для навигации, таблиц, форм и карточек описаны приёмы перестройки.
6. Все функции доступны без наведения, цели касания не меньше 24 на 24 CSS-пикселя, лучше 44.
7. Изображения отдаются в нескольких размерах, у всех указаны width и height.
8. Компоненты в Figma собраны на Auto Layout, переменные имеют режимы для диапазонов.
9. Ключевые шаблоны проработаны, промежуточные ширины и поведение описаны аннотациями.
10. В вёрстке есть viewport, масштабирование не запрещено, горизонтальной прокрутки нет при 320 пикселях.
11. Сайт проверен на реальных устройствах, в горизонтальной ориентации, при масштабе 200–400 % и с крупным системным шрифтом.
12. Скорость мобильной версии проверена в PageSpeed Insights.

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.