Адаптивный дизайн: как сайт подстраивается под телефон

Раньше для телефонов часто делали отдельную мобильную версию сайта на поддомене вроде m.site.kz. Сегодня стандартный подход — адаптивный дизайн (responsive design): один сайт, один адрес, один код, а раскладка меняется в зависимости от ширины экрана. Меню сворачивается в бургер, три колонки карточек становятся одной, крупные иллюстрации заменяются более лёгкими.

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

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

Первое, без чего адаптивность не заработает, — тег viewport в коде страницы: <meta name="viewport" content="width=device-width, initial-scale=1">. Без него мобильный браузер отрисовывает страницу на виртуальном холсте шириной с компьютерный экран (MDN приводит пример в 980px) и уменьшает её — текст становится мелким, а правила для узких экранов не срабатывают.

Брейкпоинт (breakpoint, точка перелома) — ширина экрана, на которой раскладка меняется. Хорошая практика — ставить брейкпоинты там, где «ломается» контент, а не под конкретные модели телефонов: устройств слишком много, и их размеры постоянно меняются. Между брейкпоинтами работает гибкая (резиновая) сетка: ширины задаются в процентах и долях, а не в фиксированных пикселях.

Курсор мыши точный, палец — нет. Поэтому у кнопок и ссылок на телефоне должна быть достаточная площадь нажатия (touch target) и расстояние между ними. Ориентиры дают официальные руководства:

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

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

• Атрибуты srcset и sizes дают браузеру несколько версий одной картинки разной ширины — он скачивает подходящую
• Элемент <picture> позволяет показать на телефоне другую кадрировку: например, крупный план вместо широкой панорамы
• Современные форматы WebP и AVIF при том же качестве обычно легче JPEG и PNG
• У каждой картинки указаны ширина и высота — тогда страница не «прыгает», пока изображение грузится
• Картинки ниже первого экрана загружаются лениво (loading="lazy")
• Текст набран размером, который читается без увеличения, а строки не уходят за край экрана

С текстом действует похожее правило. Размеры шрифта и отступы удобнее задавать в относительных единицах (rem, проценты, единицы ширины экрана) — тогда они масштабируются вместе с экраном и уважают настройки пользователя, если тот увеличил шрифт в системе. Заголовок, который на компьютере выглядит эффектно в 72 пикселя, на телефоне должен уменьшаться, иначе одно слово займёт целую строку и начнёт переноситься по слогам.

Режим устройств в Chrome DevTools удобен для быстрой проверки, но он не заменяет реальный телефон: эмулятор не передаёт ощущение от нажатия пальцем, поведение экранной клавиатуры, особенности мобильного Safari и медленную мобильную сеть. Перед запуском страницу стоит пройти руками хотя бы на одном iPhone и одном Android.

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