Как проверить мобильную версию и адаптивность сайта
Чтобы проверить адаптивность сайта, недостаточно уменьшить окно браузера и убедиться, что блоки поместились по ширине. Посетитель должен прочитать предложение, открыть меню, выбрать товар или услугу, заполнить форму и получить понятное подтверждение. Проверка считается полезной, когда она показывает, на каком устройстве и на каком шаге человек теряет возможность продолжить.
Ниже — практический порядок проверки для владельца сайта, дизайнера и вебмастера. Он помогает собрать проверяемые требования, найти проблемы мобильного интерфейса и принять исправления. Основное внимание уделено отображению и взаимодействию: скорость загрузки требует отдельного исследования и не заменяет тест адаптивности.
Что означает «мобильная версия работает»
Адаптивный интерфейс перестраивается под доступное пространство: колонки становятся последовательными блоками, меню меняет форму, изображения сохраняют пропорции. Однако аккуратный внешний вид ещё не доказывает, что сайт удобен. Кнопка может находиться под плавающим виджетом, фильтр — открываться только при наведении, а поле адреса — исчезать за экранной клавиатурой.
Сформулируйте результат через действия посетителя. Для магазина это поиск товара, выбор варианта, проверка доставки и оформление заказа. Для сайта услуг — понимание предложения и отправка заявки. Для информационного проекта — чтение, переход по оглавлению и поиск связанных материалов. Во всех случаях важны доступные контакты, условия и понятный выход из открытых окон.
Сравните содержание на компьютере и телефоне. Уменьшать визуальную плотность можно, но удаление характеристик, ограничений или существенных условий способно помешать выбору. Google использует мобильную версию содержимого для индексирования и ранжирования; рекомендации по mobile-first indexing предусматривают эквивалентность основного контента. Допустимы разные способы его представления, например вкладки и раскрывающиеся блоки. Устранение ошибок адаптации само по себе не гарантирует рост позиций.
Шаг 1. Составьте матрицу страниц, состояний и устройств
Начните со списка шаблонов, а затем выберите реальные страницы с разным наполнением. Главная не представляет весь сайт: карточка с длинным названием или форма с ошибкой могут использовать другие правила вёрстки. Укажите точные адреса, необходимые действия и ожидаемый результат. Такой список позволяет повторить проверку после исправления.
| Тип страницы | Что включить в проверку | Критичный результат |
|---|---|---|
| Главная и посадочная | Первый экран, меню, баннер согласия, контакты | Предложение понятно, нужный раздел доступен |
| Каталог и поиск | Фильтры, сортировка, пустая выдача, длинные названия | Можно выбрать параметры и открыть результат |
| Товар или услуга | Галерея, варианты, цена, таблица, основной призыв | Условия видны, выбор сохраняется |
| Статья и справка | Оглавление, изображения, таблицы, длинные ссылки | Материал читается и навигация работает |
| Форма и оформление | Ошибки, автозаполнение, клавиатура, подтверждение | Сценарий завершается без потери данных |
Добавьте состояния первого и повторного посещения, входа в аккаунт и выхода из него, пустой и заполненной корзины. Для одинакового шаблона возьмите как короткое, так и предельно длинное содержимое: название услуги, адрес, промокод, список характеристик. Если есть несколько языков, включите вариант с более длинными подписями.
Устройства и браузеры выбирайте по собственной аналитике, обращениям пользователей и значимости сценариев. Запишите модель, операционную систему, версию браузера, ориентацию и размер области просмотра. При отсутствии статистики разумно начать с доступного телефона Android и iPhone, проверить разные браузерные среды, затем уточнить охват по фактическим данным. Это начальная матрица, а не доказательство поддержки всех моделей.
Чтобы распределить работу, свяжите окружение с конкретным маршрутом. Ниже пример матрицы: замените общие названия своими моделями и версиями, укажите адреса страниц и ответственного. Столбец приоритета определяет очередность проверки, а не предполагаемое качество браузера.
| Устройство и среда | Страницы и состояния | Приоритет проверки |
|---|---|---|
| Телефон Android, Chrome | Посадочная → товар или услуга → форма; ввод и ошибка | Основной, если среда представлена в аудитории |
| iPhone, Safari | Тот же маршрут; клавиатура, поворот, галерея | Основной, если среда представлена в аудитории |
| Компьютер, Responsive в DevTools | Все шаблоны; длинное содержимое и промежуточные ширины | Предварительный поиск дефектов вёрстки |
| Телефон, браузер внутри приложения | Входная страница → форма → внешний шаг → возврат | По источникам переходов и известным обращениям |
Для каждого сочетания отметьте результат: пройдено, найдена ошибка или не проверено. Последнее состояние не приравнивайте к успешному тесту. Если команда ограничена во времени, это даст владельцу сайта понятную картину покрытия и поможет выбрать следующий сценарий без повторения уже выполненной работы.
Приоритет задавайте сочетанию страницы и действия. Основная заявка на распространённом среди посетителей устройстве требует более ранней проверки, чем декоративная галерея на редко используемой конфигурации. Отдельно включите устройства, на которых уже поступали жалобы, даже если их доля невелика.
Шаг 2. Проверьте адаптивность в браузере
Как использовать Chrome DevTools
Откройте нужный адрес в Chrome, затем инструменты разработчика и режим устройств через кнопку Toggle device toolbar. В списке размеров выберите Responsive, чтобы менять ширину и высоту вручную. Профиль конкретного телефона удобен как начальная точка, но проверять следует и значения между готовыми профилями.
- Откройте страницу заново в выбранном режиме и пройдите её сверху вниз.
- Плавно изменяйте ширину: фиксируйте момент, когда элементы начинают перекрываться.
- Проверьте соседние значения до и после проблемного перехода.
- Поменяйте ориентацию, затем повторите действия с меню, формой и модальным окном.
- Запишите размеры и последовательность действий, при которых обнаружена ошибка.
В документации Chrome Device Mode прямо описан как приближение к мобильному устройству. Страница продолжает работать на компьютере. Выбор профиля iPhone не запускает настоящий Safari на iOS, а имитация касаний не воспроизводит все свойства сенсорного экрана. Изменение user agent также не заменяет устройство. Поэтому результаты эмуляции нужно подтвердить на реальном телефоне для важных сценариев.
Можно ли проверить адаптивность сайта онлайн
Онлайн-просмотр полезен, если позволяет увидеть страницу в нескольких размерах. Перед использованием выясните, что именно предоставляет инструмент: картинку, встроенную страницу, эмулятор или доступ к реальному устройству. По снимку можно заметить обрезанный заголовок, но нельзя проверить открытие клавиатуры, порядок фокуса и успешную отправку формы.
Не стройте процесс вокруг устаревших инструкций: Google Mobile-Friendly Test, его API и отчёт Mobile Usability в Search Console закрыты 1 декабря 2023 года. Для текущей проверки используйте доступные инструменты браузера и реальные устройства. Один автоматический отчёт в любом сервисе не подтверждает исправность всех страниц и пользовательских действий.
Шаг 3. Проверьте viewport, промежуточные ширины и поворот
Настройка области просмотра
Если сайт плохо отображается на телефоне и выглядит как уменьшенная компьютерная страница, проверьте настройку viewport. Типовой вариант метатега, который разработчик размещает в разделе head страницы:
<meta name="viewport" content="width=device-width, initial-scale=1">MDN объясняет, как этот тег управляет областью просмотра. Наличие правильного тега не исправляет жёсткую ширину таблиц или блоков, поэтому проверку нужно продолжить. Не запрещайте масштабирование через user-scalable=no и не ограничивайте его ради внешнего вида: посетителю может требоваться увеличение текста.
CSS-пиксели и плотность экрана
Ширину интерфейса оценивают в CSS-пикселях. Разрешение дисплея в физических пикселях не равно ширине страницы: высокая плотность экрана не означает, что на телефоне следует показывать компьютерную сетку. Показатель devicePixelRatio, или DPR, описывает отношение физических пикселей к CSS-пикселям в соответствующих условиях. Фиксируйте его отдельно, если исследуете чёткость изображений; не подменяйте им ширину viewport.
Как рабочий пример можно взять ширины 320, 360, 390, 412 и 768 CSS-пикселей, затем добавить размеры из своей матрицы. Это набор контрольных точек, а не универсальные обязательные размеры устройств. Между ними медленно меняйте ширину, проверяя текст, кнопки и сетку. Проблема часто появляется там, где длинная подпись уже не помещается, а следующий вариант компоновки ещё не включился.
Проверьте портретную и альбомную ориентацию, включая поворот с уже открытым меню, галереей и формой. В широком, но низком окне особенно заметны слишком высокие шапки и недоступные кнопки в модальных окнах. Основы гибких макетов и медиазапросов собраны в курсе web.dev по адаптивному дизайну; точки перестроения стоит выбирать по потребностям содержимого.
Шаг 4. Найдите переполнение и перекрытия
Текст, изображения и горизонтальная прокрутка
Прокрутите страницу до конца и попробуйте сместить её вбок. Если весь документ уезжает за границу экрана, найдите источник: фиксированную ширину блока, длинную непрерывную строку, изображение, таблицу или встроенный виджет. Скрытие переполнения всего документа может замаскировать обрезанный контент, поэтому принимать исправление следует по доступности информации.
Проверьте длинные заголовки, цену с валютой, хлебные крошки, адреса и ссылки. Текст не должен наезжать на соседние элементы, исчезать за многоточием там, где нужен полный смысл, или сливаться с изображением. Убедитесь, что крупный системный шрифт не обрезает подписи в кнопках с фиксированной высотой.
Изображения проверяйте по смыслу: видно ли товар целиком, не обрезана ли существенная часть схемы, можно ли открыть увеличенную фотографию. Для таблиц допустимо продуманное отдельное прокручивание, когда важно сохранить связи между столбцами. Посетитель должен понимать, что данные продолжаются справа; остальные блоки страницы при этом не должны растягиваться вслед за таблицей.
Шапка, баннеры и плавающие элементы
Проверьте закреплённую шапку, нижнюю панель, уведомление о cookies, кнопку чата и рекламные блоки одновременно. Каждый элемент может выглядеть нормально по отдельности, но вместе они закрывают полезную область или перекрывают основную кнопку. Снимок первого экрана делайте в состоянии нового посетителя, пока обязательные уведомления ещё открыты.
Перейдите по ссылке оглавления и убедитесь, что заголовок не оказался под закреплённой шапкой. Прокрутите до последнего поля, примечания и кнопки внизу страницы. В галерее проверьте подписи, переключатели и выход из полноэкранного просмотра. При открытии модального окна должны оставаться доступными его содержимое, прокрутка и закрытие, в том числе после поворота телефона.
Шаг 5. Проверьте управление пальцем и с клавиатуры
Размеры целей и соседние действия
Проверяйте область нажатия, а не только нарисованную иконку. Маленький крестик может иметь удобную большую активную область; крупная картинка, наоборот, иногда реагирует только на тонкую подпись. Пройдите меню, переключатели количества, чекбоксы, выбор вариантов и ссылки рядом с удалением товара. Случайное соседнее нажатие — повод изменить расстояния или расположение.
У WCAG разные уровни требований. Критерий 2.5.8 уровня AA задаёт минимум 24 × 24 CSS-пикселя для целей указателя, но содержит исключения, в том числе для достаточного расстояния между небольшими целями и ссылок внутри текста. Критерий 2.5.5 уровня AAA использует 44 × 44 CSS-пикселя и также имеет исключения. Размер 44 × 44 можно выбрать практическим ориентиром для основных кнопок, но нельзя объявлять его безусловным требованием AA.
Наведение, жесты и окна
Проверьте, открывается ли подменю понятным касанием и не выполняется ли вместо этого неожиданный переход. Существенная информация не должна существовать только в подсказке при наведении мыши. Для карусели или сложного жеста предусмотрите доступное управление, например явные кнопки перехода. Проверьте повторное нажатие, закрытие и возврат к предыдущему состоянию.
На компьютере пройдите тот же интерфейс клавишей Tab и обратным переходом Shift+Tab. Фокус должен быть видимым, порядок — понятным, элементы — доступными без мыши. Для модального окна проверьте перемещение фокуса внутрь, управление его содержимым и возврат к вызвавшей кнопке после закрытия. Эти принципы описаны в паттерне модального диалога WAI. Настольная проверка клавиатурой дополняет мобильный тест, поскольку узкий экран не означает единственный способ ввода.
Шаг 6. Пройдите форму с настоящей экранной клавиатурой
Ввод и автозаполнение
Возьмите реалистичный набор тестовых данных и заполните форму на телефоне. Проверьте имя с пробелом, длинный адрес, почту, телефон с международным префиксом, необязательный комментарий. Используйте вставку из буфера, автозаполнение и редактирование уже введённого значения. Маски не должны мешать исправлению ошибки или неожиданно удалять часть данных.
Сверьте типы полей и подсказки клавиатуре. Атрибут inputmode помогает браузеру выбрать подходящий способ ввода, но сам по себе не проверяет корректность значения. Подходящие значения autocomplete помогают автозаполнению; фактический результат следует проверять в используемых браузерах. У телефона или кода ведущий ноль может быть значимой частью данных, поэтому обычная числовая обработка не всегда уместна.
У каждого поля должна быть понятная подпись, сохраняющая смысл после начала ввода. Placeholder не заменяет постоянно доступную подпись. Проверьте нажатие по тексту возле чекбокса и радиокнопки, пояснение обязательных полей и формат даты. Прикладные рекомендации по связям полей и подписей есть в руководстве WAI по формам.
Что меняется при открытии клавиатуры
Экранная клавиатура может уменьшить видимую область, не меняя область, по которой рассчитана компоновка страницы. Разницу между ними описывает MDN VisualViewport. Поведение зависит от браузера и настроек, поэтому проверяйте конкретный телефон: видно ли активное поле, подсказку и сообщение об ошибке; можно ли дойти до кнопки отправки; не запирает ли прокрутку закреплённая панель.
Перейдите к следующему полю кнопкой клавиатуры, закройте клавиатуру, снова откройте её и поверните устройство. Повторите сценарий внутри модального окна, если форма расположена там. После автозаполнения убедитесь, что подпись не наложилась на значение, а выбранные доставка и способ связи остались прежними.
Ошибки и завершение сценария
Отправьте пустую форму, затем форму с одной неверной записью. Сообщение должно объяснять, что исправить, и быть связано с нужным полем. Не ограничивайтесь красной рамкой. После исправления проверьте повторную отправку и сохранность остальных данных. В рекомендациях WAI по уведомлениям разобраны доступные сообщения об ошибках и результате.
Для заказа заранее согласуйте тестовый товар, аккаунт и безопасный сценарий оплаты. Используйте тестовую среду или предусмотренный платёжной системой тестовый режим; не нажимайте реальную оплату наугад. Подтвердите результат в разрешённом контуре: запись заявки или заказа и понятное сообщение посетителю. Для теста на рабочем сайте заранее определите, кто обработает и удалит тестовые записи, чтобы они не попали в обычное исполнение.
Шаг 7. Проверьте увеличение и доступность
Масштаб и перестроение содержимого
Увеличьте текст и проверьте заголовки, поля, кнопки и ошибки. У WCAG это несколько разных проверок. Критерий 1.4.4 Resize Text требует возможности увеличить текст до 200% без потери содержимого и функций, с указанными в нём исключениями для субтитров и изображений текста. Это не то же самое, что проверка обычного мобильного размера.
Критерий 1.4.10 Reflow касается перестроения: для вертикально прокручиваемого содержимого рассматривается ширина, эквивалентная 320 CSS-пикселям, без потерь и необходимости прокручивать в двух направлениях. Пример эквивалента — исходный viewport шириной 1280 CSS-пикселей при увеличении 400%. Для содержимого, которому действительно нужна двумерная компоновка, предусмотрены исключения, например для таблиц данных. Не переносите это исключение на всю страницу.
Практический результат проверки прост: текст читается, элементы не перекрываются, действия доступны. Дополнительно включите увеличенный системный размер текста на телефоне и повторите важную форму. Записывайте способ увеличения, поскольку масштаб всей страницы, размер текста и настройки операционной системы могут давать разное поведение.
Короткий проход со скринридером
Используйте VoiceOver на iPhone или TalkBack на Android, если эти среды входят в матрицу. Прослушайте заголовки, названия кнопок, подписи полей, состояние раскрытого меню и сообщение о результате. «Кнопка без названия» не помогает понять действие; иконка удаления должна иметь понятное назначение. Проверьте, что после открытия окна чтение не уходит в недоступный фон.
Для первой проверки выберите один короткий маршрут: найти услугу, открыть форму, обнаружить ошибку и исправить её. Такой проход выявляет конкретные препятствия, но не подтверждает соответствие всем требованиям WCAG. Если требуется формальная оценка доступности, её объём и критерии нужно определять отдельно.
Шаг 8. Повторите ключевые действия на реальных телефонах
Чтобы проверить адаптивность сайта под мобильные устройства, откройте те же адреса и воспроизведите те же действия на выбранных телефонах. Запишите точные версии среды: названия «Android» или «iPhone» недостаточно для воспроизведения. Сначала пройдите основной маршрут в обычном состоянии браузера, затем — сценарий нового посетителя, когда видны уведомления и ещё нет сохранённых значений.
Проверьте экран с вырезом и системную область у нижнего края, если такие устройства есть в охвате. Важная кнопка не должна попадать в неудобную зону или перекрываться системными элементами. Оцените экран после появления и скрытия панелей браузера: видимая высота меняется, поэтому красивый первоначальный снимок не гарантирует корректного поведения при прокрутке.
Если пользователи переходят из мессенджеров или социальных приложений, проверьте соответствующие встроенные браузеры. Включите открытие внешнего платёжного шага, возврат обратно, загрузку фотографии и переход по контакту, если они нужны вашему сайту. Фиксируйте конкретное приложение и его версию; не распространяйте результат одной проверки на все встроенные браузеры.
Особое внимание уделите возврату назад. Фильтр, вариант товара и введённые данные должны сохраняться там, где этого ожидает пользователь. Для обнаруженного отличия повторите сценарий в обычном браузере того же телефона: сравнение поможет локализовать проблему, а не списывать её сразу на модель устройства.
Шаг 9. Оформите ошибки так, чтобы их можно было исправить
Фраза «на телефоне всё съехало» не даёт разработчику условий для воспроизведения. Одна задача должна описывать одну проблему, её влияние и конкретное ожидаемое поведение. Снимок полезен для обрезанного текста, запись экрана — для исчезающего меню, клавиатуры или последовательности переходов. Удаляйте из вложений реальные персональные и платёжные данные.
Страница: https://example.com/order
Среда: модель, ОС и версии браузера; портретная ориентация
Условия: новый посетитель, тестовый аккаунт, открыта клавиатура
Шаги: открыть форму → перейти в последнее поле → показать ошибку
Фактически: сообщение и кнопка скрыты за нижней панелью
Ожидается: ошибку можно прочитать, поле исправить, форму отправить
Влияние: оформление не завершается без обходного действия
Вложения: запись экрана, размеры viewport, время проверкиЭто шаблон описания, а не результат проверки конкретного сайта. Добавьте частоту воспроизведения, затронутые страницы и сведения о версии проекта. Не смешивайте наблюдение с предполагаемой причиной: «кнопка закрыта панелью» — факт, «виноват z-index» — гипотеза, которую ещё нужно проверить.
| Приоритет | Пример влияния | Что делать |
|---|---|---|
| Критичный | Нельзя отправить заявку, оформить заказ или закрыть блокирующее окно | Исправить до приёмки соответствующего сценария |
| Высокий | Недоступны существенные условия, фильтр или важные элементы управления | Проверить все страницы с тем же компонентом |
| Средний | Есть обходной путь, но ввод или чтение заметно затруднены | Назначить срок и проверить влияние на соседние действия |
| Низкий | Декоративное отличие не мешает содержимому и работе | Исправлять после препятствий основному маршруту |
Приоритет зависит от последствий и охвата, а не от размера дефекта на снимке. Небольшая неработающая иконка закрытия может блокировать весь сайт. Отступ в большом баннере иногда остаётся косметической проблемой. Согласуйте критерии с владельцем продукта до передачи списка исполнителю.
Как принять исправления и не потерять результат
Повторите исходные шаги в той же среде, затем проверьте соседние ширины, другое наполнение и страницы с общим компонентом. Исправление одного CSS-правила может затронуть весь шаблон. Отдельно повторите основной маршрут целиком: локально исправленная кнопка ещё не означает, что оформление снова работает.
- Нет непредусмотренного горизонтального переполнения страницы и потери существенного содержимого.
- Меню, галереи, окна и основные кнопки работают касанием и доступным способом управления.
- Форма сохраняет данные, показывает понятные ошибки и завершается в тестовом сценарии.
- Клавиатура, баннеры и закреплённые панели не блокируют нужные действия.
- Увеличение текста и проверенные вспомогательные технологии не выявляют прежних препятствий.
- Для каждой задачи записаны повторная проверка, среда и результат; оставшиеся ограничения названы явно.
Сохраните матрицу как рабочий чек-лист для следующих изменений меню, форм, баннеров и шаблонов. После выпуска проверьте важные страницы на рабочем сайте в согласованном объёме.
После проверки на телефонах важно продолжать следить за доступностью ключевых страниц и работой форм между выпусками. Познакомьтесь с SiteGuard и оцените возможности мониторинга страниц и форм, через которые посетители обращаются к вам.
Частые вопросы о проверке мобильной версии сайта
Как быстро проверить мобильную версию сайта бесплатно?
Начните с режима устройств в браузере и собственного телефона. Проверьте главную, важную внутреннюю страницу и основной сценарий обращения или заказа. Затем расширьте матрицу по шаблонам и устройствам. Быстрый проход помогает найти заметные препятствия, но его результат нельзя распространять на непроверенные разделы.
Почему в эмуляторе всё хорошо, а на телефоне есть ошибка?
Эмулятор не воспроизводит полностью конкретный браузер, экранную клавиатуру и работу операционной системы. Разница может проявиться при прокрутке, касании, автозаполнении или открытии внешнего приложения. Зафиксируйте среду и шаги, затем сравните поведение в обычном браузере этого же телефона.
Нужно ли тестировать каждую существующую модель?
Полный перебор устройств непрактичен. Проверяйте диапазоны ширин, характерные браузерные среды и важные состояния компонентов, а реальные устройства выбирайте по аудитории и известным проблемам. Указывайте охват проверки: это позволяет расширять его осмысленно и понимать, какие сочетания пока не проверены.
Достаточно ли убрать горизонтальную прокрутку?
Нет. Сайт может помещаться на экран, но оставаться неудобным из-за мелких целей, скрытых условий, недоступной формы или перекрытий. Полезный итог проверки — возможность пройти нужный маршрут с доступным содержимым и понятной обратной связью. Поэтому визуальный просмотр всегда дополняют действиями.