Проверка мобильной версии сайта: viewport, касания и форма заявки

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

Что именно нужно проверить

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

Мобильное взаимодействие следует отделять от общей доступности, скорости загрузки и Core Web Vitals. Эти направления связаны, но отвечают на разные вопросы. Например, страница может быстро загружаться и при этом иметь горизонтальную прокрутку, перекрытую кнопку или неудобное поле телефона. В этой статье рассматриваются именно компоновка на узком экране, касания и форма заявки.

Диагностический алгоритм

1. Зафиксируйте проверяемый сценарий

Выберите публичный URL и сформулируйте конкретную цель: открыть страницу, понять предложение, перейти к форме, заполнить обязательные поля, отправить заявку и увидеть результат. Если на странице несколько форм или CTA-кнопок, проверяйте каждый путь отдельно. Запишите начальное состояние, введённые данные и ожидаемую реакцию интерфейса.

2. Проверьте несколько ширин экрана

Начните примерно с 320, 360, 390 и 430 CSS-пикселей. Важна не модель телефона, а поведение интерфейса в диапазоне узких ширин. Затем изменяйте ширину плавно: ошибка нередко появляется между заранее заданными контрольными точками.

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

3. Найдите источник горизонтальной прокрутки

Если страницу можно сдвинуть вбок, не маскируйте дефект глобальным overflow-x: hidden. Сначала найдите элемент, который шире области просмотра. Частые причины: фиксированная ширина контейнера, изображение без ограничения max-width, длинная строка без переноса, таблица, отрицательный отступ или блок с width: 100vw внутри контейнера с боковыми отступами.

Для первичной проверки в консоли браузера можно выполнить:

[...document.querySelectorAll('*')].filter(
  el => el.getBoundingClientRect().right > document.documentElement.clientWidth
)

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

4. Пройдите страницу пальцем

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

Проверьте фиксированные шапки, нижние панели, виджеты и кнопки связи. Они не должны закрывать заголовок, последнее поле, текст ошибки или основную кнопку. Если интерфейс учитывает вырезы экрана, безопасные отступы можно задавать через env(safe-area-inset-*).

5. Полностью заполните форму

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

Проверяемые критерии

Область Критерий Как проверить
Viewport Задан корректный метатег viewport В исходном HTML присутствует width=device-width, initial-scale=1
Компоновка Нет нежелательной прокрутки по горизонтали Провести страницу от верха до низа на минимальной ширине
Контент Текст, изображения и таблицы не обрезаются Проверить длинные слова, подписи, карточки и встроенные материалы
Касания Активные зоны достаточно крупные и разделены Нажать элементы большим пальцем на реальном устройстве
Форма Метки, обязательность и ошибки понятны Отправить пустую форму, затем исправить каждое поле
Клавиатура Тип клавиатуры соответствует данным Проверить type, inputmode и автозаполнение
Отправка Состояние запроса и результат видимы Проверить успешный ответ, ошибку и повторное нажатие

Форма заявки на узком экране

Поля и экранная клавиатура

Для электронной почты используйте type="email", для телефона — подходящий type или inputmode="tel", для числовых данных — соответствующий режим ввода. Это не заменяет проверку данных, но помогает вызвать удобную клавиатуру. Автозаполнение следует настраивать стандартными значениями autocomplete, а не отключать без причины.

У каждого поля должна быть видимая метка. Placeholder может показывать пример, но не должен быть единственным названием поля: после ввода он исчезает. Ошибка должна располагаться рядом с проблемным полем, описывать способ исправления и оставаться видимой после появления клавиатуры.

Кнопка и результат отправки

Основная кнопка должна оставаться доступной после заполнения последнего поля. Во время запроса интерфейс обязан показывать состояние обработки и предотвращать непреднамеренные повторные отправки. После ответа пользователь должен увидеть однозначный результат: заявка принята либо возникла ошибка и действие можно повторить.

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

Типовые мобильные ошибки

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

Границы метода

Проверка публичной страницы позволяет оценить то, что доступно обычному посетителю: структуру viewport, адаптацию блоков, видимые элементы управления и открытый конверсионный путь. Она не раскрывает настройки CMS, внутреннюю серверную логику, доставку заявки в CRM или обработку обращения сотрудниками.

Автоматическая диагностика также не заменяет ручной проход на нескольких устройствах. Она помогает обнаружить технические, SEO/GEO и конверсионные сигналы, но удобство касания, поведение конкретной экранной клавиатуры и понятность сообщения после отправки требуют проверки человеком. Скорость, общая доступность и Core Web Vitals следует анализировать отдельно, не смешивая их с выводами о мобильной компоновке.

Итоговый чек-лист

  1. Открыть публичный URL на ширине от 320 CSS-пикселей.
  2. Проверить viewport и отсутствие горизонтальной прокрутки.
  3. Просмотреть весь контент в двух ориентациях.
  4. Нажать меню, ссылки, переключатели и CTA на реальном устройстве.
  5. Убедиться, что фиксированные элементы ничего не перекрывают.
  6. Заполнить форму с экранной клавиатурой и автозаполнением.
  7. Проверить пустые, ошибочные и допустимые значения.
  8. Проверить успешную отправку, сбой и защиту от повторного нажатия.
  9. Зафиксировать URL, ширину экрана, шаги и снимок каждого дефекта.
  10. После исправлений повторить весь сценарий, а не только проблемный экран.

Такая проверка мобильной версии сайта даёт воспроизводимый результат: для каждой ошибки известны условия появления, ожидаемое поведение и способ повторной проверки. Это полезнее общей оценки «на телефоне выглядит нормально».