Почему адаптив нельзя проверять только на одном телефоне

Проверка адаптива на одном телефоне успокаивает, но часто ничего не доказывает. Открыли сайт на своем iPhone, первый экран не развалился, кнопка видна, можно запускать. А потом оказывается, что на другом размере заголовок переносится в кашу, форма уезжает за край, меню перекрывает кнопку, а длинный email ломает карточку.

Проблема не в том, что кто-то плохо старался. Просто "телефон" — это не одно устройство. Это десятки ширин, браузеров, масштабов текста, плотностей экрана и сценариев. Если проверять только свой аппарат, можно случайно протестировать самый удобный вариант и пропустить все остальное.

Что именно ломается на разных мобильных

Чаще всего адаптив едет не в больших эффектных местах, а в скучных бытовых деталях.

Например:

• длинный заголовок занимает почти весь первый экран;
• две кнопки становятся слишком узкими;
• телефон или email не помещается в строку;
• карточки разной высоты ломают сетку;
• форма становится длиннее, чем ожидалось;
• меню открывается, но закрывает CTA;
• таблица или прайс не получает горизонтальный скролл;
• попап нельзя нормально закрыть пальцем;
• sticky-блок съедает полезную высоту экрана.

На одном телефоне это может выглядеть нормально. На другом — уже нет. Особенно если дизайнер смотрел макет на ширине 390 пикселей, разработчик проверил 430, а реальный клиент открыл сайт на старом Android шириной 360.

Почему ширина важнее модели телефона

Я бы не начинал проверку с вопроса "какие модели устройств взять". Практичнее думать ширинами и сценариями.

Минимальный набор для обычного сайта услуг:

Ширина	Что имитирует	Что смотреть
320 px	очень узкий экран	переносы, кнопки, меню, формы
360 px	небольшой Android	первый экран, карточки, CTA
390 px	массовый современный телефон	общий ритм страницы
430 px	крупный телефон	сетки, отступы, иллюстрации
768 px	планшет или узкий desktop	промежуточные состояния

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

Одного браузера тоже мало

На мобильном нельзя полагаться только на desktop-режим в Chrome DevTools. Он полезен, но это не вся реальность.

Стоит отдельно проверить:

• Safari на iOS, если есть доступ к iPhone;
• Chrome на Android;
• встроенные браузеры из мессенджеров, если трафик часто приходит из Telegram, VK или рекламы;
• поведение клавиатуры при вводе в форму;
• кликабельность телефонов, email и мессенджеров.

Встроенный браузер особенно любит сюрпризы. Человек нажал ссылку в рекламе или сообщении, попал не в идеальный Chrome, а в вебвью внутри приложения. Если там форма неудобна или кнопка закрывается панелью, лид теряется без красивой технической ошибки.

Проверять надо не макет, а путь пользователя

Адаптив — это не только "ничего не вылезло за экран". Сайт может быть технически ровным, но неудобным.

Я обычно смотрю короткими сценариями:

1. Открыть главную и понять предложение за первые секунды.
2. Перейти на страницу услуги.
3. Прочитать ключевые блоки без увеличения.
4. Открыть меню и вернуться назад.
5. Нажать основной CTA.
6. Заполнить форму тестовыми данными.
7. Проверить сообщение после отправки.
8. Позвонить или открыть мессенджер с телефона.

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

Длинный контент надо тестировать отдельно

Многие мобильные поломки появляются не на коротких демо-текстах, а на реальном контенте. Особенно на сайтах услуг, каталогах и блогах.

Нужно проверять:

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

Идеальный макет с коротким словом "Услуга" почти ничего не говорит. Настоящая жизнь начинается, когда в карточку приезжает "Комплексное сопровождение сайта после запуска" и внезапно занимает четыре строки.

Что можно автоматизировать, а что проверять руками

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

Я бы делил так:

Проверка	Чем удобно ловить
Горизонтальный скролл страницы	DevTools, Playwright, ручной просмотр
Сломанные переносы	ручной просмотр на ширинах
Некликабельные кнопки	реальный телефон
Поведение клавиатуры	реальный телефон
Скорость и вес	Lighthouse, WebPageTest, DevTools
Ошибки форм	ручной тест с отправкой

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

Минимальный чеклист адаптива

Перед запуском я бы проверил хотя бы это:

1. Нет горизонтального скролла на 320, 360, 390 и 430 пикселях.
2. Заголовки не превращаются в стену переносов.
3. Основной CTA виден и нажимается пальцем.
4. Меню открывается, закрывается и не перекрывает важное навсегда.
5. Формы помещаются на экране и нормально работают с клавиатурой.
6. Телефон, email и мессенджеры кликаются.
7. Таблицы, прайсы и широкие блоки получают скролл или нормальную мобильную версию.
8. Карточки не ломаются от длинных названий.
9. Попапы можно закрыть на маленьком экране.
10. Страница остается понятной без desktop-контекста.

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

Итог

Проверять адаптив на одном телефоне — примерно как проверять замок одним ключом и считать, что вся дверь в порядке. Может повезти, а может нет.

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