Как сверстать адаптивный макет: инструкция от структуры до проверки

Как сверстать адаптивный макет: инструкция от структуры до проверки

Адаптивный макет — это не «дополнительная опция» и не этап, который можно отложить на потом. Если сайт нормально выглядит только на большом мониторе, вы теряете половину посетителей ещё до того, как они прочитают первый абзац. Хорошая новость в том, что адаптивность закладывается в самом начале работы, а не прикручивается в конце костылями из сотни медиазапросов.

В этой инструкции разберём весь путь: от продумывания структуры до финальной проверки на реальных устройствах. Материал рассчитан на тех, кто уже знаком с HTML и CSS и хочет делать вёрстку, которая честно работает на любом экране.

Что такое адаптивный макет

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

Не путайте адаптивность с «резиновостью» и с отдельной мобильной версией сайта:

  • Резиновый макет просто растягивается в процентах, но на узком экране часто превращается в кашу.
  • Отдельная мобильная версия (например, m.site.ru) — это два разных проекта, которые нужно поддерживать одновременно.
  • Адаптивный макет — единый код, который перестраивается по заданным правилам.

Шаг 1. Сначала структура, потом код

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

Определите приоритеты контента

Задайте себе вопрос: что пользователь должен увидеть первым на экране шириной 360 px? Обычно это заголовок, ключевое действие и основной текст. Всё второстепенное — баннеры, длинные меню, дополнительные виджеты — уходит ниже или скрывается. На широком экране те же блоки выстраиваются в несколько колонок.

Работайте по принципу mobile-first

Mobile-first означает, что базовые стили вы пишете для узкого экрана, а дальше расширяете их через min-width. Это проще, чем обратный подход: добавлять правила для маленьких экранов сложнее, чем убирать лишнее для больших. Плюс базовый CSS получается компактнее.

Шаг 2. Базовая настройка документа

Без метатега viewport вся адаптивность бессмысленна: мобильный браузер просто отмасштабирует десктопную страницу.

<meta name="viewport" content="width=device-width, initial-scale=1">

Дальше — минимальный набор правил, который избавит от классических проблем:

  • box-sizing: border-box для всех элементов — чтобы padding не ломал расчёты ширины.
  • Сброс отступов у body, h1–h6, ul, p.
  • img { max-width: 100%; display: block; } — картинки перестанут вылезать за границы.
  • Базовые переменные в :root для цветов, отступов и радиусов.

Шаг 3. Гибкая сетка: Flexbox и Grid

Основу адаптивного макета задают две технологии. Flexbox хорош для одномерных раскладок: меню, ряды карточек, выравнивание по центру. Grid — для двумерных: сложные сетки, где нужно контролировать и строки, и колонки.

Вместо фиксированной ширины используйте относительные единицы и функции:

  • %, fr, auto — вместо жёстких пикселей.
  • grid-template-columns: repeat(auto-fit, minmax(260px, 1fr)) — колонки сами перестраиваются под доступную ширину, без единого медиазапроса.
  • flex-wrap: wrap — ряды элементов переносятся на новую строку, когда места не хватает.
  • gap — аккуратные отступы между блоками вместо ручных margin.

Главное правило: контейнеры должны быть гибкими, а не рассчитанными на одну конкретную ширину окна.

Шаг 4. Брейкпоинты и медиазапросы

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

Типовая практика для mobile-first — несколько расширений базовых стилей:

  1. База: 0–600 px, одна колонка.
  2. @media (min-width: 600px) — две колонки, крупнее отступы.
  3. @media (min-width: 900px) — боковая панель, многоколоночная сетка.
  4. @media (min-width: 1200px) — ограничение максимальной ширины контента и центрирование.

Не забывайте про max-width для основного контейнера: на мониторе 2560 px строка текста должна оставаться читаемой, а не растягиваться на всю ширину.

Шаг 5. Изображения и медиа

Картинки — главный источник «поехавшей» вёрстки. Базовое правило max-width: 100% спасает, но не решает вопрос с весом страницы. Что стоит использовать:

  • srcset и sizes — браузер сам выберет подходящий размер файла.
  • Элемент picture — если для мобильных нужен другой кадр, а не просто уменьшенная версия.
  • aspect-ratio — фиксирует пропорции и защищает от «прыгающего» контента при загрузке.
  • object-fit: cover — обрезка внутри контейнера без искажения пропорций.

Видео и встраиваемые iframe оборачивайте в контейнер с относительным позиционированием или задавайте им width: 100%.

Шаг 6. Типографика и отступы

Размеры текста удобно задавать в rem — тогда пользователь, увеличивший шрифт в настройках браузера, получит нормальную страницу. Для плавного изменения размеров без медиазапросов используйте clamp():

font-size: clamp(1rem, 2.5vw, 1.5rem);

То же касается отступов между секциями: вместо жёстких 80 px ставьте плавное значение, которое на мобильном сжимается до 32–40 px.

Шаг 7. Проверка готового макета

Вёрстка готова не тогда, когда она «красиво выглядит у вас», а когда вы прошли по всем контрольным точкам:

  • DevTools. Режим адаптивного просмотра: 320, 360, 768, 1024, 1440, 1920 px. Проверяйте не только внешний вид, но и горизонтальную прокрутку.
  • Реальные устройства. Хотя бы один смартфон и один планшет — эмулятор не покажет особенности тач-скролла и реальных шрифтов.
  • Поворот экрана. Альбомная ориентация часто выявляет скрытые проблемы с высотой блоков.
  • Увеличение текста. Поставьте в браузере масштаб 200% — ничего не должно обрезаться и наезжать.
  • Тач-элементы. Кнопки и ссылки — не меньше 44×44 px, иначе по ним неудобно попадать пальцем.
  • Скорость. Прогоните страницу через PageSpeed Insights и убедитесь, что мобильная версия не грузит десктопные картинки.

Частые ошибки новичков

  • Фиксированная ширина блоков в пикселях — ломает всё на узких экранах.
  • Скрытие важного контента на мобильных «чтобы влезло».
  • Горизонтальная прокрутка из-за одного выступающего элемента.
  • Игнорирование промежуточных разрешений: проверили 375 и 1440 px, а на 800 px всё разъехалось.
  • Слишком мелкий текст: 12–13 px на смартфоне читаются плохо.

Что в итоге

Адаптивная вёрстка начинается не с медиазапросов, а с головы: с продуманной структуры, приоритетов контента и подхода mobile-first. Гибкие контейнеры на Flexbox и Grid снимают большую часть работы, медиазапросы остаются только для действительно серьёзных перестроек, а проверка на реальных устройствах закрывает последние дыры. Пройдите эти семь шагов — и макет будет одинаково уверенно выглядеть на любом экране, а не только на вашем мониторе.

Комментарии

  1. Полина Козлова

    Спасибо, что напомнили про mobile-first. Я раньше писала стили сначала для десктопа, потом мучилась с max-width и переписывала половину блоков. После вашего объяснения поняла, почему min-width реально удобнее.

    1. Юрий Журавлёв

      Я тоже пришёл к mobile-first после того, как дважды переделывал шапку на телефоне. Но у меня остался вопрос: если в макете есть таблица с широкими данными, её тоже прятать на 360 px или лучше сделать горизонтальный скролл внутри блока?

      1. Илья Казаков

        Таблицу обычно не прячу: на узком экране делаю контейнер с overflow-x: auto и подсказкой, что можно прокрутить. Скрывать стоит только второстепенные колонки, если они не нужны для понимания строки. Главное — не ломать базовую доступность.

  2. Виктория

    У меня был сайт, который на телефоне открывался как уменьшенная копия десктопа. Оказалось, я забыла метатег viewport. После добавления и пары медиазапросов стало нормально, но теперь всегда проверяю в DevTools на 360 и 768 px.

  3. алина

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

  4. артём

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

Комментарии закрыты.