Адаптивная вёрстка

Адаптивная вёрстка — это не отдельная «мобильная версия на поддомене», а один HTML, который перестраивается через медиазапросы, fluid-типографику и гибкие сетки. Подход mobile-first означает: базовые стили пишутся для узкого экрана, а расширения добавляются через min-width. Так меньше шансов забыть мобильный сценарий и меньше переопределений в CSS.

Брейкпоинты: не копировать Bootstrap вслепую

Точки перелома должны следовать макету и контенту, а не шаблонным 768/992/1200, если макет ломается раньше. Смотрите, где сетка из трёх колонок становится нечитаемой, где таблица требует горизонтального скролла в обёртке, где меню перестаёт помещаться. Обычно для лендингов хватает 3–4 брейкпоинтов плюс clamp() для размеров шрифта между ними.

• 320–400px: минимальная ширина, проверка форм и кнопок
• 600–768px: планшет-портрет, часто второй ряд карточек
• 1024px: планшет-ландшафт и небольшие ноутбуки
• 1280px и выше: десктоп по макету, ограничение max-width контейнера

Навигация и жесты

1. Бургер-меню открывается и закрывается с фокусом внутри модалки
2. Кликабельная зона не меньше 44×44px по рекомендациям доступности
3. Нет hover-only подсказок — на тач-устройствах они недоступны
4. Свайп-слайдеры не блокируют вертикальный скролл страницы
5. Телефон и email — кликабельные ссылки tel: и mailto:

Типографика и читаемость

Размер основного текста на мобильном редко должен быть меньше 16px — иначе браузеры зумят поля ввода. Межстрочный интервал 1.5–1.6 улучшает чтение длинных статей. Заголовки сжимайте через clamp, а не отдельным макетом на каждый брейкпоинт, если дизайнер согласовал шкалу.

Медиа и производительность на мобильных

• Не грузить десктопное hero 2500px на телефон — используйте picture/source
• Отключать или упрощать тяжёлые декоративные видео на слабых сетях
• Проверять LCP и CLS в Lighthouse mobile, не только desktop
• Избегать position: fixed на полэкрана — на iOS это влияет на viewport

Чек-лист приёмки адаптива

1. Пройти все ключевые страницы на iPhone и Android среднего сегмента
2. Заполнить форму с автокоррекцией и проверить клавиатуру
3. Повернуть экран на странице с таблицей или широкой галереей
4. Открыть сайт при медленном 3G в DevTools — контент не должен «прыгать»
5. Сверить с макетом только там, где макет реально есть для mobile

Зафиксируйте в акте приёмки список протестированных устройств и браузеров. Это снимает споры, когда на редком Xiaomi всплывает баг в старом WebView — можно отдельно оценить, входит ли поддержка в договор.

Типичные баги адаптива в продакшене

Фиксированная шапка перекрывает якорные ссылки к разделам — лечится scroll-padding-top на html. Модальное окно не блокирует скролл body на iOS — нужен overflow: hidden на body и аккуратность с position. Видео в фоне hero съедает трафик — на узком экране показывайте статичное изображение. Sticky-блоки в сайдбаре на длинной статье «наезжают» на подвал — ограничьте sticky родителем или отключайте на мобильном.

• 100vh на мобильном без учёта адресной строки — используйте dvh/svh где поддерживается
• Мелкий текст в подвале с десятком ссылок — увеличьте интерлиньяж и отступы
• Две колонки формы на планшете, которые на деле узкие — переключайте в одну колонку раньше
• Карта на весь экран без кнопки «закрыть» на мобильном

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