Как проверить адаптацию адаптивного сайта для внешней торговли на мобильных устройствах?

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

Сначала определите область проверки: устройства, страницы и языковые версии

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

Не ограничивайтесь главной страницей. Для B2B-сайта необходимо как минимум проверить список товаров, страницу товара, форму запроса и страницу контактов; для трансграничного интернет-магазина также следует проверить корзину, оформление заказа и переход к оплате. Отдельно проверьте целевые страницы рекламных кампаний, многоязычные страницы и страницы с фильтрами: их макет и взаимодействие могут отличаться от главной страницы.

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

Проверка макета: страница должна не только помещаться на экране, но и оставаться читаемой

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

Затем проверьте изменение ориентации экрана и масштабирование страницы. Остаются ли навигация и всплывающие окна закрываемыми в альбомной ориентации? Не перекрывается ли и не исчезает ли контент при увеличении текста? Не запрещайте пользователю масштабировать страницу ради того, чтобы она «как раз поместилась». Цель адаптивного макета — подстраивать контент под доступное пространство, а не просто уменьшать страницу для компьютера целиком.

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

Проверка взаимодействия: пройдите реальный путь конверсии

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

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

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

Проверка производительности: отличайте результаты лабораторных тестов от реального опыта посетителей

Адаптация для мобильных устройств — это не только вопрос внешнего вида. Изображения, видео, сторонние скрипты отслеживания и компоненты чата могут замедлять отображение страницы или задерживать отклик на нажатия. Для выявления проблем с ресурсами и отрисовкой можно использовать Chrome DevTools, имитируя медленную сеть и ограниченную производительность устройства, а также анализировать результаты Lighthouse. Если есть возможность, изучите данные мониторинга реальных пользователей, чтобы оценить опыт посетителей целевых рынков.

При оценке производительности обратите внимание на Core Web Vitals — LCP, INP и CLS: эти показатели характеризуют загрузку основного контента, реакцию на взаимодействие и визуальную стабильность макета соответственно. Используйте показатели и диагностические сведения инструментов проверки скорости страницы как ориентиры для поиска проблем, одновременно учитывая данные реальных пользователей, чтобы определить масштаб их влияния. Результат одного лабораторного теста отражает только условия конкретного тестирования и не характеризует опыт всех зарубежных пользователей.

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

При технической приемке не упустите проверку поисковой доступности и согласованности контента

Доступность мобильной страницы еще не означает, что поисковые системы правильно понимают ее содержимое. Проверьте, сохранены ли в мобильной версии основной текст, информация о товарах, описания изображений и структурированные данные, соответствующие версии для компьютеров; важный контент не должен присутствовать только на компьютерах или пропадать из-за сбоя загрузки скриптов. С помощью инструмента проверки URL в Google Search Console можно просмотреть сведения о сканировании и индексировании страницы, а затем сопоставить их с результатом фактической отрисовки в браузере.

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

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

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

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