Как проверить адаптивность сайта: от первого экрана до отправки заявки

Проверяйте весь путь посетителя по сайту

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

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

Этот порядок проверки подходит и для действующего сайта, и для приёмки новой вёрстки. По результатам можно составить список задач для разработчика. Автоматический отчёт поможет найти часть проблем, а ручная проверка покажет, мешают ли они посетителю выполнить задачу.

Составьте список страниц и действий для проверки

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

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

Проверьте диапазон ширин, а не список моделей телефонов

В инструментах разработчика браузера включите режим устройства и плавно меняйте ширину области просмотра. В качестве стартового набора можно взять 320, 375, 390, 768, 1024 и 1440 CSS-пикселей. Это пример набора для первой проверки. Дополните его размерами экранов, которыми пользуются ваши посетители. Особенно внимательно смотрите промежутки между ними: ошибка нередко появляется за несколько пикселей до переключения макета.

Физическое разрешение дисплея и ширина страницы в CSS-пикселях — разные величины. Не нужно вводить в эмуляторе полное аппаратное разрешение телефона, чтобы «точнее» повторить его экран. Для расположения блоков важна ширина viewport — области браузера, в которой показана страница. В документации MDN объясняется, как метатег viewport связывает мобильный экран с правилами адаптивной вёрстки.

Что проверить в коде

Разработчику следует проверить наличие <meta name="viewport" content="width=device-width, initial-scale=1">. Если сайт отрисовывается в широкой виртуальной области и затем целиком уменьшается, текст становится мелким, а мобильные стили могут не включиться. Однако один метатег не исправит жёстко заданную ширину блока: причины нужно проверять отдельно.

Найдите горизонтальную прокрутку и сломанные блоки

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

Безусловное overflow-x: hidden на всей странице может убрать полосу прокрутки и одновременно обрезать кнопку, текст или индикатор фокуса. Такое изменение нельзя считать исправлением без повторной проверки содержимого. Для таблицы характеристик часто разумнее оставить локальную прокрутку внутри подписанного контейнера, а для карточек изменить число колонок. Решение зависит от смысла данных.

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

Оцените текст, кнопки и навигацию

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

У кнопки важна вся активная область, а не только размер значка. Для основных кнопок удобно закладывать область касания от 48 × 48 CSS-пикселей и промежутки между соседними элементами. Такой ориентир предлагает web.dev при проверке форм. Его не следует путать с минимальным требованием WCAG 2.2 уровня AA: там указан размер 24 × 24 CSS-пикселя с оговорёнными исключениями. Соответствие минимуму ещё не гарантирует удобство на телефоне.

Меню и управление без мыши

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

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

Пройдите форму вместе с экранной клавиатурой

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

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

Что происходит после нажатия «Отправить»

Отдельно проверьте момент отправки: виден ли прогресс, защищена ли кнопка от случайного повторного нажатия, что происходит при временной ошибке сети. Сообщение «Спасибо» должно появляться после подтверждения приёма данных сервером. Простая смена надписи на кнопке ещё не доказывает, что обращение дошло.

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

Используйте автоматический аудит как начало проверки

Автоматический инструмент полезен для первого просмотра нескольких экранов, обнаружения подозрительно широких блоков и составления списка технических замечаний. В сервисе проверки адаптивности ШТАБ ИТ можно начать с URL нужной страницы, затем сопоставить отчёт с тем, что видно в браузере. Для диагностики выбирайте конкретную проблемную страницу, а не только главную.

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

Разделяйте адаптивность и производительность. Страница может правильно перестраиваться и медленно загружаться из-за тяжёлых изображений; другая — быстро открываться, но иметь недоступную кнопку. В отчёте это разные задачи с разными доказательствами. Для изображения проверяют объём файла и скорость загрузки, для кнопки — размер, положение и реакцию на нажатие.

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

Как описать найденные ошибки разработчику

Для каждого дефекта запишите адрес, размер окна, браузер, шаги воспроизведения, ожидаемый и фактический результат. Добавьте скриншот с проблемным местом. Если ошибка возникает только после определённого действия, короткая запись экрана полезнее набора статичных картинок. Не объединяйте разные проблемы в одну задачу «исправить адаптив»: её трудно оценить и принять.

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

Согласуйте, кто проверяет результат: разработчик воспроизводит и устраняет причину, ответственный за приёмку проходит исходный сценарий. Для изменений общих компонентов добавляйте проверку соседних страниц. Исправление меню на главной не должно сломать шапку внутри статьи или карточки товара.

Чек-лист перед приёмкой мобильной версии

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

• Основной сценарий выполняется на телефоне от входа до подтверждения действия.
• При плавном изменении ширины нет обрезанных элементов и общей горизонтальной прокрутки.
• Таблицы, изображения и длинные строки доступны целиком.
• Меню открывается и закрывается, ссылки ведут на нужные страницы, при переходе по якорям заголовки не скрываются под шапкой.
• Фокус виден, зоны касания разделены, увеличение текста не скрывает важные действия.
• Клавиатура не блокирует форму, ошибки понятны, повторная попытка сохраняет введённые данные.
• На реальном устройстве подтверждён хотя бы один важный сценарий.
• После исправлений повторно проверены общий шаблон и соседние страницы.

Для первой проверки выберите страницу, на которую приходят посетители из рекламы или поиска. Запустите её проверку адаптивности, затем вручную пройдите целевое действие и передайте воспроизводимые замечания в работу. Для комплексной доработки сайта можно обсудить задачу с командой ШТАБ ИТ: по списку ошибок и условиям приёмки проще оценить объём работ.