Проверка сайта на адаптивность: как протестировать мобильную версию

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

Что такое проверка сайта на адаптивность

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

Например, на компьютере интернет-магазин показывает каталог в четыре колонки, а на телефоне — в одну. Основное меню превращается в компактную кнопку, изображения уменьшаются, а поля формы располагаются друг под другом. Так работает адаптивная вёрстка: содержимое подстраивается под доступное пространство.

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

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

Как проверить адаптивность сайта в Google Chrome

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

Ничего устанавливать не придётся. Вы сможете выбрать условное мобильное устройство, изменить ширину страницы и проверить, не исчезают ли важные элементы.

Откройте сайт в мобильном режиме

Перейдите на нужную страницу в Chrome. Например, откройте лендинг, на который собираетесь направлять рекламный трафик.

Затем нажмите F12 или Ctrl + Shift + I в Windows и Linux. На macOS используйте Cmd + Option + I. Откроется панель DevTools — обычно справа или снизу от страницы.

В верхней части панели найдите значок телефона и планшета. При наведении на него появится название Toggle device toolbar. Нажмите на значок: Chrome переключится в режим проверки мобильной версии.

Его также можно включить сочетанием Ctrl + Shift + M в Windows и Linux или Cmd + Shift + M на macOS, когда DevTools уже открыт.

Установите ширину экрана

Над страницей появится панель настроек. В списке Dimensions выберите Responsive — режим, в котором ширину и высоту можно менять вручную.

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

Здесь используются CSS-пиксели — единицы, в которых браузер измеряет размеры элементов страницы. Они не обязательно совпадают с физическими пикселями экрана телефона. Для проверки вёрстки вам пока достаточно ориентироваться на значение ширины в DevTools.

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

Пройдите страницу от начала до конца

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

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

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

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

Меняйте ширину постепенно

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

Например, при ширине 425 пикселей форма помещается целиком, при 400 кнопка наезжает на поле ввода, а при 375 блоки перестраиваются и снова выглядят нормально.

Такие изменения часто связаны с брейкпоинтами (breakpoints) — значениями ширины, при которых сайт переключается на другой вариант расположения элементов.

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

Проверьте горизонтальную прокрутку

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

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

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

В стандарте доступности WCAG 2.2 есть критерий Reflow. Для большинства обычного содержимого он предусматривает возможность просмотра при ширине, эквивалентной 320 CSS-пикселям, без потери информации и прокрутки в двух направлениях. Исключения допускаются для элементов, которым двумерное расположение необходимо по смыслу, например некоторых таблиц, карт и схем.

Сохраните найденную ошибку

Если кнопка, изображение или форма вышли за границу экрана, сделайте скриншот. В Chrome Device Mode откройте меню с тремя точками и выберите Capture screenshot. Для сохранения всей страницы есть пункт Capture a full size screenshot.

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

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

На каких разрешениях проверять адаптивность сайта

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

В качестве стартового набора можно использовать:

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

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

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

Что проверить на мобильной версии: меню, кнопки и формы

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

Чтобы ничего не пропустить, удобно проверять страницу по элементам.

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

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

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

Адаптивность и правильность рекламной аналитики — разные задачи. Проверка сохранения UTM-меток, событий конверсии и данных трекера тоже полезна перед запуском трафика, но её лучше проводить отдельно от проверки вёрстки.

Больше о том, как организовать ручные проверки и выбирать важные сценарии, рассказываем в статье «Тестирование сайтов: как находить баги до релиза».

Как проверить отправку формы заявки

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

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

На тестовом стенде пройдите такой сценарий:

1. Откройте лендинг при мобильной ширине и перейдите к форме.
2. Нажмите «Отправить», не заполняя обязательные поля. Проверьте, появились ли понятные сообщения об ошибках.
3. Введите тестовые данные. Убедитесь, что текст не обрезается и поля удобно заполнять.
4. Отправьте форму. Посмотрите, появилось ли подтверждение или открылась нужная страница благодарности.
5. Если у вас есть доступ к тестовой CRM или серверной части, проверьте, что заявка действительно создана.

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

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

Как проверить сайт на настоящем смартфоне

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

Если есть возможность, откройте сайт на Android-смартфоне в Chrome и на iPhone в Safari. Начните с самого важного действия: например, перехода на лендинг и заполнения формы.

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

Для рекламных страниц имеет смысл отдельно проверить переходы из приложений.

Проверка лендинга во встроенном браузере Telegram и VK

Если посетитель переходит по ссылке из Telegram, VK или другого приложения, страница может открыться во встроенном браузере, а не в привычном Chrome или Safari.

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

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

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

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

Как проверить адаптивность сайта в Firefox

Помимо Chrome, для бесплатной проверки можно использовать Firefox. В нём есть встроенный режим Responsive Design Mode, который позволяет менять размер страницы, выбирать устройства и проверять некоторые особенности мобильного отображения.

Откройте сайт в Firefox и нажмите Ctrl + Shift + M в Windows или Linux. На macOS используйте Cmd + Option + M.

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

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

Онлайн-сервисы для проверки адаптивности сайта

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

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

BrowserStack Responsive Testing

BrowserStack Responsive Testing позволяет посмотреть, как одна страница отображается при нескольких размерах экрана.

Для работы используется расширение BrowserStack Testing Toolkit для Chrome. После установки и входа в аккаунт откройте нужную страницу, запустите расширение и выберите Responsive Testing.

На экране появятся варианты страницы с разными размерами области просмотра. Можно добавить свои значения ширины, сравнить расположение элементов и сохранить скриншоты.

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

Но здесь используется эмуляция. Она подходит для сравнения вёрстки, а для проверки особенностей настоящего мобильного браузера понадобится другой инструмент.

BrowserStack Live

BrowserStack Live предназначен для интерактивного тестирования сайтов на удалённых реальных устройствах.

В интерфейсе можно выбрать устройство и браузер, открыть нужный сайт и взаимодействовать с ним. Например, проверить лендинг в Safari на iPhone или Chrome на Android, даже если у вас нет такого телефона под рукой.

В отдельных конфигурациях сервис поддерживает параллельные проверки на нескольких устройствах. Доступ к этим возможностям зависит от тарифа и условий аккаунта.

Есть важное ограничение для арбитража трафика: обычный BrowserStack Live не предназначен для проверки сайтов внутри встроенных браузеров сторонних приложений. Для тестирования WebView внутри приложений у BrowserStack есть отдельный продукт App Live, который предполагает работу с установленным приложением.

Поэтому, если нужно проверить обычную мобильную страницу, BrowserStack Live подойдёт. А для проверки конкретного перехода из Telegram или VK проще начать с настоящего телефона и нужного приложения.

Можно ли проверить адаптивность через PageSpeed Insights?

PageSpeed Insights помогает оценить производительность страницы на мобильных устройствах и компьютерах. Он показывает данные о скорости загрузки, стабильности интерфейса и других характеристиках.

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

Но хорошая оценка PageSpeed Insights не подтверждает, что меню открывается правильно, кнопки доступны на всех размерах и форма работает после появления клавиатуры. Эти действия нужно проверять вручную.

Старый Google Mobile-Friendly Test, который можно встретить в инструкциях прошлых лет, больше не работает: Google прекратил поддержку инструмента в декабре 2023 года.

Как найти ошибку адаптивной вёрстки

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

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

Если нужно разобраться глубже, в DevTools есть вкладка Elements. Она позволяет выбрать элемент страницы и посмотреть связанные с ним CSS-правила — настройки, которые отвечают за размеры и расположение блоков.

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

Например, на учебном лендинге при ширине 390 CSS-пикселей кнопка «Отправить заявку» уходит за правый край формы. На компьютере она помещается нормально, поэтому проблему легко пропустить, если проверять только десктопную версию.

Как оформить баг-репорт об ошибке адаптивности

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

Возьмём условный пример с кнопкой заявки. Баг-репорт может выглядеть так:

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

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

Подробнее о структуре отчёта и правилах его заполнения читайте в материале «Баг-репорт: что это, как правильно составить и пример оформления».

Можно ли автоматизировать проверку адаптивности

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

Для этого используют Playwright и Selenium. Они управляют браузером по заранее написанному сценарию и помогают регулярно повторять проверки после изменений на сайте.

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

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

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

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

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

• Проверить мобильные размеры 320, 375, 390 и 425 CSS-пикселей.
• Проверить планшетную и десктопную ширину, а также промежутки между брейкпоинтами.
• Убедиться, что текст читается без боковой прокрутки всей страницы.
• Открыть и закрыть меню, всплывающие окна и баннер cookies.
• Проверить, что изображения, кнопки и формы не выходят за экран.
• Заполнить форму с ошибками и правильными тестовыми данными.
• Проверить подтверждение отправки и, при наличии доступа, создание тестовой заявки.
• Пройти путь от прелендинга до целевого действия.
• Открыть страницу на настоящем смартфоне.
• Для трафика из приложений проверить переход во встроенном браузере Telegram, VK или другой нужной платформы.
• Зафиксировать дефекты и повторить проверки после исправлений.

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

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

FAQ