Как проверить адаптивность сайта: метод, который находит настоящие баги

Чтобы как следует проверить адаптивную вёрстку, сделайте три прохода: медленно проведите ширину viewport примерно от 320 px до 1920 px, чтобы найти места, где ломается раскладка; проверьте конкретные модели устройств с их настоящим user agent и плотностью пикселей; нагрузите раскладку длинным контентом и масштабом 200%. Большинство багов адаптивности живёт между брейкпоинтами и в контенте, под который дизайн не рассчитывали. Поэтому проверка трёх фиксированных размеров («телефон, планшет, десктоп») их пропускает.

Почему проверки трёх размеров недостаточно

Раскладку рисуют на нескольких ширинах, а пользуются ею на всех. Заголовок, который помещается на 375 px, может некрасиво переноситься на 344 px (так бывает у некоторых складных телефонов в сложенном виде). Навигация, которая помещается на 1024 px, может вылезать на 1100 px, когда какой-нибудь пункт меню станет длиннее. Баги скапливаются:

• сразу ниже и выше каждого брейкпоинта;
• на ширинах, под которые никто не рисовал, например 600–700 px (маленькие планшеты, окна в режиме разделённого экрана);
• в реальном контенте, который длиннее, чем в макете.

Проход 1: по всем ширинам

1. Откройте Chrome DevTools, включите панель устройств (Ctrl + Shift + M или Cmd + Shift + M на Mac) и выберите Responsive.
2. Поставьте ширину 320 px и медленно тяните правый край до самой большой поддерживаемой ширины.
3. Следите за горизонтальной прокруткой, наложением текста, кнопками, которые переносятся на две строки, растянутыми картинками, сетками с одной осиротевшей карточкой и элементами, которые прыгают при переключении брейкпоинта.
4. Когда что-то ломается, запишите точную ширину, которую показывает панель.

Включите Show media queries в меню панели устройств, чтобы видеть брейкпоинты цветными полосами над viewport. Клик по полосе переключает на эту ширину. Пошаговая помощь по режиму устройства есть в статье эмулятор мобильных устройств в Chrome.

Полезная привычка: проверяйте каждый брейкпоинт ровно на его значении и на пиксель меньше. Ошибки на единицу между max-width: 768px и min-width: 768px встречаются постоянно.

Проход 2: профили реальных устройств

Ширина — только часть того, что сообщает телефон. Устройства ещё отправляют мобильный user agent, у них плотность пикселей 2 или 3, и на них может срабатывать другое поведение на сервере или в JavaScript. Проверьте ключевые страницы на конкретных профилях:

• маленький телефон (около 360–375 px в ширину);
• актуальный iPhone (393–402 px) и большой iPhone (430–440 px); значения есть в таблице разрешений экранов iPhone;
• телефон на Android (360–412 px);
• планшет в обеих ориентациях (инструкция для iPad и планшетов).

Для этого подойдут пресеты устройств в DevTools. Когда нужно прокликать много страниц, быстрее работает расширение для проверки адаптивности Mobile View Extension: оно перезагружает вкладку с user agent, размером экрана и плотностью пикселей устройства, сохраняет выбранное устройство при переходах и позволяет сравнить разные виды одной страницы рядом.

Проход 3: нагрузите контент

В макетах идеальный контент, на реальных сайтах — нет. Попробуйте:

• Длинные слова и строки: длинное название товара, немецкий перевод, email или URL в узкой колонке. Где нужно, добавьте overflow-wrap: anywhere.
• Больше или меньше элементов: меню из восьми пунктов вместо пяти, сетка из семи карточек вместо шести.
• Отсутствующие изображения: как выглядит карточка, если картинка не загрузилась или ещё грузится?
• Крупный текст: поставьте в браузере размер шрифта по умолчанию 20 px или больше. Раскладка на rem должна масштабироваться, а блоки фиксированной высоты начнут обрезать текст.
• Масштаб 200% и 400% на десктопе: масштабирование сужает CSS-viewport, поэтому при 400% окно шириной 1280 px ведёт себя как экран шириной 320 px. WCAG 2.2 требует, чтобы при таком размере контент перестраивался без прокрутки в двух направлениях, за исключением карт, таблиц с данными и подобного.

Проход 4: автоматизируйте скриншоты

Ручные проходы находят баг один раз, а скриншот мобильной версии, приложенный к задаче, показывает точную ширину, на которой всё сломалось. Автоматические скриншоты ловят баги, когда те возвращаются. С инструментом вроде Playwright короткий скрипт может открывать ключевые страницы, например на 360, 768, 1024 и 1440 px в Chromium, Firefox и WebKit, и сравнивать скриншоты с предыдущей версией на каждом pull request. Такое визуальное регрессионное тестирование хорошо подходит для дизайн-систем и маркетинговых страниц, которые часто меняются.

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

Сайты, которые показывают ваш URL сразу в нескольких рамках, удобны для быстрого обзора. Но у них есть ограничения: они загружают страницу со своих серверов или в iframe, поэтому не достают до localhost и страниц за авторизацией; многие сайты запрещают показ себя во фрейме; а рамки обычно меняют только ширину, но не user agent. Используйте их, чтобы взглянуть, а не чтобы принимать работу.

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

Для более широкой проверки перед запуском, помимо вёрстки (формы, скорость, SEO), используйте чек-лист тестирования мобильной версии сайта.

Частые вопросы

Как быстро проверить адаптивность сайта?

Откройте Chrome DevTools, выберите режим Responsive на панели устройств и тяните ширину вверх от 320 px. Всё, что вылезает за край или накладывается, — это баг адаптивности.

Какие размеры экрана проверять при адаптивной вёрстке?

Пройдите все ширины от 320 px, затем проверьте 360, 375, 390–402, 412 и 430–440 px для телефонов, примерно 768–834 px и 1024 px для планшетов и 1280–1920 px для десктопа.

Считается ли изменение размера окна браузера проверкой адаптивности?

Это нормальная проверка CSS-брейкпоинтов, но десктопные браузеры перестают сужаться примерно на 500 px и не отправляют мобильный user agent. Для ширины телефонов используйте режим устройства или расширение для мобильного просмотра.