Адаптивный дизайн сайта - что проверить на телефоне, планшете и компьютере

Адаптивность проверяют сценариями, а не скриншотами

Страница может красиво выглядеть в макете 375 px и ломаться после открытия клавиатуры, длинного заголовка или меню. Поэтому адаптивный дизайн нужно тестировать в движении: скролл, ввод, поворот экрана, переходы и системные панели браузера.

Не проектируйте только под названия устройств

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

В Zero Block Tilda есть стандартные диапазоны для нескольких ширин и возможность добавлять собственные брейкпоинты. Это позволяет адаптировать композицию по реальной необходимости, а не только по пяти готовым размерам. См. справку Tilda по адаптивности Zero Block.

Что проверять на разных ширинах

1. Текст и типографика

• H1 не выпадает за экран;
• длина строки остается комфортной;
• основной текст читается без увеличения;
• интерлиньяж не схлопывается;
• длинные ссылки и слова не создают горизонтальный скролл;
• кнопки не получают случайные переносы.

Не уменьшайте шрифт до минимума только ради сохранения десктопной композиции.

2. Меню

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

3. Формы и клавиатура

Это один из самых частых источников проблем. На реальном телефоне проверьте:

• тип клавиатуры для телефона и email;
• автозаполнение;
• видимость активного поля;
• ошибки валидации;
• кнопку отправки после открытия клавиатуры;
• чекбоксы и ссылки на документы;
• сообщение об успешной отправке.

4. Изображения и видео

Фокус изображения может потеряться при кропе. В hero это особенно заметно: человек или объект оказывается за текстом либо полностью исчезает. Для разных соотношений сторон используйте осмысленное позиционирование, а не одинаковый background-position везде.

Видео не должно блокировать первый экран на слабой сети. Предусмотрите poster и адекватное поведение, если autoplay ограничен браузером.

5. Таблицы, карточки и длинный контент

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

Горизонтальный скролл карточек должен быть очевидным, иначе пользователь может не понять, что контент продолжается.

6. Fixed и sticky элементы

Чат, cookie-плашка, нижний CTA, браузерная панель и клавиатура могут одновременно занять половину мобильного экрана. Проверяйте систему целиком, а не каждый виджет отдельно.

7. Не забывайте промежуточные ширины

Частая ошибка - идеальные 1440 и 375 px при сломанном диапазоне 700-1000 px. Именно там две колонки становятся тесными, а десктопное меню уже не помещается.

8. Большие экраны тоже требуют ограничений

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

Тестовая матрица вместо трех красивых скриншотов

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

Высота экрана так же важна, как ширина

Мобильный браузер меняет доступную высоту при появлении адресной строки и клавиатуры. Поэтому full-screen hero, fixed CTA и меню нужно проверять не только в статичном DevTools. Элемент, который идеально стоит на макете 390×844, может перекрыть половину формы при вводе.

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

Какие устройства проверить

Минимальный практический набор: небольшой телефон, современный большой телефон, планшет или промежуточная ширина, ноутбук около 1366-1440 px и широкий экран. Добавьте Safari iOS и Chrome Android, потому что браузерное поведение отличается.

DevTools полезен, но не заменяет устройство

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

Тестируйте не только идеальный контент

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

Для CMS это критично: редактор будет добавлять записи после запуска, и каждая новая длина текста не должна требовать участия разработчика.

Проверьте поворот и изменение высоты

Мобильный браузер постоянно меняет доступную высоту из-за адресной строки и клавиатуры. Блоки с жестким 100vh, фиксированные меню и модальные окна могут вести себя неожиданно. Тестируйте вертикальную и горизонтальную ориентацию там, где она реальна для вашей аудитории.

Touch меняет поведение интерфейса

Hover на десктопе не имеет прямого аналога на сенсорном экране. Если подсказка, меню или карточка раскрывается только при наведении, на телефоне должен существовать явный сценарий касания. То же касается маленьких стрелок и зон клика вокруг иконок.

Адаптив считается готовым после прохождения сценариев

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

Для большого Tilda-проекта адаптивность лучше закладывать в общую дизайн-систему, а не исправлять по одному блоку перед релизом.