Аудит мобильной версии проверяет, сможет ли человек на телефоне прочитать предложение, найти нужный раздел и отправить заявку. Отсутствие горизонтальной прокрутки — только один пункт: проблемы часто появляются после открытия меню, клавиатуры или модального окна.
Этот чек-лист объединяет мобильные проверки из наших регламентов SEO и юзабилити. Проверяйте отдельные сценарии и шаблоны, а не только уменьшенную главную страницу.
Подготовьте матрицу устройств и страниц
По данным аналитики выберите распространённые браузеры и размеры экрана вашей аудитории. Для начала полезны узкий экран около 360–390 пикселей и более широкий около 430 пикселей. Затем пройдите сценарии на реальном телефоне: эмуляция не показывает все особенности клавиатуры и браузера.
Проверьте главную, услугу или категорию, карточку, статью, контакты и форму. Если есть корзина, личный кабинет или сторонний платёжный переход, включите их в маршрут с тестовыми данными и предусмотренным тестовым режимом.
Проверьте первый экран и навигацию
- Понятно, что предлагает страница и где следующий шаг.
- Заголовок не обрезан, текст читается без увеличения.
- Шапка и уведомления не перекрывают основное содержимое.
- Меню открывается, закрывается и позволяет выбрать раздел.
- Кнопки не стоят настолько близко, что легко нажать соседнюю.
- После возврата назад человек не теряет выбранный товар или данные формы.
Проверьте длинные заголовки, списки параметров, таблицы и адреса. Таблицу допустимо прокручивать внутри собственного контейнера; вся страница при этом не должна разъезжаться за пределы экрана.
Пройдите заполнение формы
Попробуйте заполнить форму одной рукой, исправить ошибку и отправить её повторно. Подписи должны оставаться понятными после ввода. Сообщение об ошибке должно объяснять, какое поле исправить, а введённые корректные значения — сохраняться.
Учебный сценарий: посетитель вводит телефон, нажимает «Отправить», но пропущенное обязательное поле находится выше за клавиатурой. Если система не показывает причину, пользователь видит молчание вместо результата. Воспроизведите ошибку, укажите устройство и приложите последовательность действий в задачу разработчику.
После успешной отправки проверьте подтверждение на экране и фактическое получение заявки. Зафиксируйте событие аналитики на успехе, а не только на клике. Подробнее этот подход описан в алгоритме юзабилити-аудита.
Проверьте скорость важных шаблонов
Откройте проверку скорости страницы ITSEO, укажите публичный URL и выберите мобильное устройство. Начните со страниц, на которые приходит трафик. Повторите замер, если результат нестабилен, сохранив условия проверки.
Не назначайте «50 баллов» универсальным критерием готовности. Балл лабораторного теста помогает найти проблемы в условиях конкретного запуска. Реальные пользовательские данные и наблюдение за рабочими сценариями дают другую часть картины.
| Метрика | Что отражает | Ориентир хорошего результата |
|---|---|---|
| LCP | Появление основного содержимого | Не более 2,5 секунды. |
| INP | Отзывчивость при взаимодействии | Не более 200 миллисекунд. |
| CLS | Неожиданные сдвиги элементов | Не более 0,1. |
Для Core Web Vitals эти ориентиры оценивают на 75-м процентиле реальных посещений. Один лабораторный запуск не подтверждает выполнение всех требований, а отсутствие полевых данных не означает провал. При нехватке данных используйте лабораторную диагностику и собственное наблюдение, явно отмечая ограничение.
Разделите причины и исправления
При медленном LCP проверьте главное изображение, ответ сервера и ресурсы, блокирующие отображение. При сдвигах — размеры изображений и резервирование места под виджеты. При задержках взаимодействий — тяжёлые обработчики и объём работы JavaScript.
Для изображений пригодится конвертер изображений, но смена формата сама по себе не решает все проблемы. После изменения проверьте качество, размеры, загрузку первого экрана и сценарий заявки.
Матрица проверок: ширина экрана не заменяет устройство
Для каждого сценария запишите браузер, операционную систему, ориентацию, размер экрана и состояние сети. Начните с устройств, которые действительно используются вашей аудиторией. Эмуляция помогает быстро найти разъезд блока на заданной ширине, но реальный телефон показывает поведение клавиатуры, адресной строки, жестов и переключения приложений. Сочетайте оба подхода, фиксируя, что именно проверено.
Учитывайте не только стартовую страницу, но и состояния интерфейса. Карточка без выбранного варианта может помещаться на экран, а после выбора показывать длинное название и ломать кнопку. Пустая форма выглядит аккуратно, а при ошибке увеличивает высоту и скрывает действие за клавиатурой. Матрица должна включать нормальное состояние, ошибку, загрузку и успешное завершение.
| Сценарий | Состояния | Что записать |
|---|---|---|
| Меню | Открытие, выбор, закрытие | Прокрутка фона, доступность ссылок, возврат к странице. |
| Каталог | Фильтр, пустая выдача, возврат | Выбранные значения и сохранение позиции. |
| Форма | Ввод, ошибка, повтор, успех | Тип клавиатуры, сообщения и фактическая отправка. |
| Статья | Оглавление, таблица, изображение | Читаемость, переходы и локальная прокрутка. |
| Контакт | Телефон, сообщение, адрес | Правильная цель перехода и понятный результат. |
Меню, закреплённые элементы и всплывающие окна
Откройте меню в начале и середине длинной страницы. Проверьте, не остаётся ли часть пунктов за экраном и можно ли добраться до последнего раздела. Затем закройте меню несколькими предусмотренными способами. Фон не должен незаметно прокручиваться вместо самого меню, а после закрытия посетитель должен продолжить работу в ожидаемом месте. Запишите конкретную последовательность при обнаружении сбоя.
Закреплённая шапка, баннер cookie, нижняя кнопка и чат могут одновременно занимать значительную часть экрана. Проверяйте их вместе, а не по одному. Откройте форму с клавиатурой и убедитесь, что поле и сообщение видны. Если перекрывается основное действие, в задаче нужно указать сочетание элементов и состояние экрана, иначе разработчик не воспроизведёт проблему на статическом макете.
Модальное окно проверьте с длинным текстом и увеличенными системными шрифтами. Должны оставаться доступными закрытие, необходимые поля и кнопка. Если предусмотрена прокрутка, она должна работать в нужной области. Переходы клавишей назад и жестом браузера также стоит проверить в реальном сценарии: пользователь может ожидать закрытие окна, а приложение неожиданно уводит его со страницы.
Формы: тестируйте ввод, а не только внешний вид
Клавиатура и тип поля
Для телефона и адреса электронной почты полезно соответствующее поле ввода, которое предлагает подходящую клавиатуру. Но удобство нельзя подтвердить одним атрибутом: попробуйте вставить номер из буфера, исправить символ в середине, указать код другой страны и очистить значение. Слишком жёсткая маска иногда мешает корректному вводу, хотя красиво показывает пустой шаблон.
Проверьте автозаполнение и повторное открытие формы. Данные браузера могут подставляться иначе, чем ручной набор. Подписи не должны исчезать вместе с placeholder, если это единственное объяснение поля. После ошибки сохраните уже введённые корректные значения. Пользователь не должен заново заполнять всю форму из-за одного пропущенного обязательного пункта.
Отправка и повторная попытка
Используйте согласованные тестовые данные и пройдите успешную отправку. Затем проверьте медленный ответ и повторное нажатие. Интерфейс должен объяснять, что действие выполняется, и не создавать неожиданно несколько обращений. При сбое сообщение должно быть понятным и сохранять возможность исправить или повторить действие. В приёмке подтвердите результат на стороне системы, которая получает заявку.
Если форма передаёт человека в мессенджер, это другой сценарий. Проверьте, открывается ли нужный адресат, передаётся ли ожидаемый текст и что происходит, когда приложение не установлено. Аналитика клика описывает переход, но не подтверждает отправленное сообщение. Такие ограничения нужно учитывать при сравнении завершения разных способов обращения.
Контент на маленьком экране
Просмотрите длинные названия услуг, цену с пояснением, адрес, таблицы и списки характеристик. Перенос текста должен сохранять читаемость и не вытеснять важное действие. Отдельные технические строки можно прокручивать локально, если это оправдано содержанием. Для обычного текста горизонтальная прокрутка мешает чтению и часто указывает на неверную ширину элемента.
Изображение должно помогать понять предложение, а не только занимать первый экран. Для схем и скриншотов предусмотрите возможность рассмотреть исходный размер. Текст, встроенный в картинку, плохо читается при сильном уменьшении; важные условия лучше оставить обычным текстом страницы. Проверьте также, что альтернативное описание соответствует назначению содержательного изображения.
Оглавление длинной статьи должно вести к существующим разделам, а закреплённая шапка не должна закрывать заголовок после перехода. Для таблиц проверьте собственный контейнер прокрутки и возможность понять, что есть дополнительные колонки. Эти элементы часто забывают, потому что основное тестирование ограничивается коммерческими страницами, хотя информационный трафик также приходит с телефонов.
Как читать отчёт скорости и назначать задачи
Полевые данные и лабораторная диагностика
Полевые показатели описывают накопленный опыт реальных пользователей в определённых условиях. Лабораторный тест воспроизводит контролируемый запуск и помогает найти причины. Они не обязаны совпадать. Если полевых данных недостаточно, не подменяйте их одним числом лабораторного балла. Запишите источник и область измерения: конкретный URL или более широкую группу, если отчёт показывает именно её.
Сравнивайте повторные тесты с одинаковыми параметрами. Один быстрый и один медленный запуск могут отличаться из-за сети, ответа сервера и сторонних ресурсов. Для оценки исправления полезно посмотреть несколько сопоставимых наблюдений и конкретную изменённую причину. Если заменили главное изображение, подтвердите его размер и порядок загрузки, а не только любое изменение итоговой оценки.
Приоритет зависит от страницы и сценария
Тяжёлый первый экран услуги и медленная редко посещаемая архивная страница требуют разного порядка работ. Сначала определите, где проблема затрагивает входы и важные действия. Затем выясните, принадлежит ли причина одному шаблону или общему ресурсу. Один общий скрипт может влиять на весь сайт, а одно большое изображение — только на отдельную посадочную.
Разработчику нужны наблюдение, ресурс или действие, ожидаемый результат и способ повторной проверки. Формулировка «сделать мобильную скорость хорошей» не задаёт объём. Укажите, что задерживает появление содержимого, какой элемент сдвигается или какое нажатие отвечает медленно. Если причина пока не определена, задача должна быть исследовательской, а не обещать конкретное исправление без диагностики.
Учебный пример: три независимые проблемы одной страницы
Представим услугу с большим главным изображением, нижней закреплённой кнопкой и формой в модальном окне. Изображение появляется медленно, кнопка перекрывает пояснение о цене, а сообщение об ошибке формы скрывается за клавиатурой. Это три разных дефекта. Замена фотографии не исправит форму; изменение расположения кнопки не подтвердит ускорение загрузки.
| Проблема | Проверяемое изменение | Приёмка |
|---|---|---|
| Большой ресурс первого экрана | Подходящий размер и корректная загрузка | Контент остаётся качественным, замеры сопоставимы. |
| Перекрытое пояснение | Согласованное размещение закреплённого элемента | Цена и действие доступны на узком экране. |
| Невидимая ошибка формы | Сообщение рядом с полем и сохранение ввода | Ошибка понятна при открытой клавиатуре. |
После технической приёмки можно изучать завершение заявки. Если одновременно изменилась рекламная аудитория, количественный результат требует осторожной интерпретации. Учебный разбор показывает декомпозицию задачи, а не заявляет о реальном росте обращений. Гипотезы о бизнес-эффекте остаются частью отдельного анализа пути пользователя и измерения конверсии.
Минимальный набор приёмки после мобильного релиза
Повторите основные пути на реальном устройстве, узкой и широкой эмуляции, с длинными данными и ошибочным вводом. Проверьте меню, закреплённые блоки, прямой вход на посадочную и возврат назад. Подтвердите загрузку изображений, отсутствие общего горизонтального разъезда и работу ссылок. Для изменённых форм сопоставьте события и фактическое получение тестовой заявки.
Сохраните исходные условия, контрольные URL и краткую последовательность действий. Следующий релиз можно проверить тем же набором, расширив его для новых компонентов. Мобильный аудит здесь сосредоточен на состоянии интерфейса и производительности; общий отчёт о поведении пользователей, работа с гипотезами и статистикой раскрываются в отдельной статье о юзабилити.
Критерий готовности мобильного аудита
Все выбранные сценарии пройдены на реальных устройствах, блокирующие ошибки исправлены, скорость проверена по важным шаблонам, а аналитика корректно фиксирует успех. Гипотезы о росте конверсии вынесены отдельно от технических дефектов и имеют способ оценки результата.
Повторяйте короткую проверку после релизов меню, форм и карточек. Для более широкой оценки используйте технический SEO-аудит и аудитор сайта.
Поворот экрана, увеличение текста и возвращение в сценарий
После основной проверки измените ориентацию телефона и увеличьте доступный пользователю размер текста. Важные элементы должны оставаться понятными и доступными. Проверьте, что длинная подпись не исчезает, кнопка не оказывается за пределами окна, а цена не накладывается на соседний текст. Эти состояния помогают обнаружить жёсткие размеры блоков, которые случайно работают только в одном стартовом сочетании настроек.
Пройдите возврат из другого приложения. Посетитель может открыть мессенджер, посмотреть код подтверждения или перейти к карте, затем вернуться на сайт. Убедитесь, что сценарий сохраняет ожидаемое состояние и не показывает ложное подтверждение отправки. Если сессия закончилась или данные не сохранены, интерфейс должен объяснить, что произошло. Такой контроль отличается от простой проверки первого экрана после загрузки.
Для многошагового заказа проверьте переходы между этапами и редактирование предыдущего шага. Изменение адреса или товара может менять стоимость и доступность. На маленьком экране эти изменения должны быть видны до подтверждения. Пользователь не должен обнаруживать новые условия только после действия. В тестовой приёмке используйте предусмотренный проектом режим, чтобы проверить путь без создания реальной покупки.
Проверьте элементы, которыми трудно управлять пальцем: маленькие крестики, плотные списки, горизонтальные карусели и выпадающие поля. Запишите конкретный ошибочный переход или невозможность выбрать значение. Общая формулировка «сделать удобнее» не объясняет дефект. Для приёмки повторите действие в тех же условиях и убедитесь, что соседние элементы сохранили работу после изменения размеров или расположения.
Не забывайте доступность обычных способов взаимодействия. Понятные подписи и видимый фокус помогают разным пользователям, включая тех, кто использует дополнительные средства ввода. Порядок элементов должен соответствовать сценарию, сообщения — объяснять результат. Полная оценка доступности требует отдельной методики, но выявленные очевидные препятствия стоит фиксировать уже в мобильном аудите и не откладывать как косметические пожелания.
После обнаружения сложного состояния сохраните последовательность: устройство, открытая страница, действие, изменение ориентации или масштаба и фактический результат. По одному статическому снимку разработчик часто не понимает источник сбоя. Краткое воспроизводимое описание и контрольный кадр позволяют проверить исправление быстрее и уменьшают риск, что дефект будет закрыт после просмотра страницы в другом состоянии.
Этот дополнительный набор расширяет покрытие сценария, не заменяя основные проверки скорости и форм. В отчёте укажите, какие состояния проверены и какие требуют следующего исследования. Если все важные маршруты проходят, а отдельная гипотеза о конверсии ещё не подтверждена, разделите их статусы. Так техническая приёмка остаётся конкретной, а дальнейшая аналитика не выдаётся за уже достигнутый результат.
Частые вопросы
Достаточно ли открыть сайт в режиме телефона в браузере?
Это хороший начальный шаг. Реальное устройство нужно для проверки клавиатуры, нажатий, прокрутки и поведения конкретного браузера.
Хорошие метрики гарантируют позиции?
Нет. Они описывают часть пользовательского опыта. Содержание, соответствие запросу и техническая доступность тоже влияют на итоговую картину.
