Чтобы мобильная версия сайта работала предсказуемо, используйте адаптивную верстку сайта как базовый подход и проверяйте не только внешний вид, но и скорость (LCP/TTI/TBT), кликабельность тач‑элементов, медиа‑оптимизацию, работу в слабой сети и доступность. Ниже — практичный чек‑лист PASS/FAIL, таблицы проверок и пошаговая настройка ключевых UX‑моментов.
Короткий чек‑лист обязательных требований
- PASS/FAIL: страница быстро становится полезной — LCP, TTI, TBT в пределах целевых значений вашей команды и устройства.
- PASS/FAIL: сетка и типографика не «ломаются» на ключевых ширинах и ориентациях; нет горизонтального скролла.
- PASS/FAIL: элементы управления доступны большим пальцем, тапы не промахиваются, состояния видимы.
- PASS/FAIL: изображения/видео не «взрывают» вес и не блокируют рендер; шрифты не вызывают скачки.
- PASS/FAIL: в 3G/плохом Wi‑Fi контент появляется постепенно; критическое кешируется, тяжёлое — лениво.
- PASS/FAIL: базовая доступность соблюдена (контраст, фокус, размеры целей, семантика), локаль и платформенные нюансы учтены.
Критерии производительности и время до интерактивности
Кому подходит: большинству проектов, где мобильный трафик значим и важна конверсия/поиск. Когда не стоит начинать с «отдельной мобилки»: если нет ресурсов поддерживать две кодовые базы, если контент и функциональность одинаковые — обычно выгоднее усиливать адаптив и производительность. Если вы планируете аудит мобильной версии сайта, начинайте со снятия метрик и карты «узких мест».
| Параметр | Критерий (PASS/FAIL) | Метод тестирования | Приоритет |
|---|---|---|---|
| LCP | PASS: LCP укладывается в целевое значение для вашего «среднего» мобильного устройства; FAIL: систематически выше цели | Chrome DevTools → Lighthouse / Performance; WebPageTest; RUM (если есть) | Обязательное |
| TTI / INP (если измеряете) | PASS: интерактивность достигается быстро, клики не «залипают»; FAIL: заметная задержка ввода | DevTools Performance (Long tasks), Lighthouse; RUM | Обязательное |
| TBT | PASS: нет длительных блокировок main-thread; FAIL: частые long tasks | Lighthouse (TBT), Performance профилирование | Обязательное |
| Критический CSS/JS | PASS: минимальный критический путь; FAIL: рендер блокируется большими бандлами | Coverage в DevTools; анализ waterfall | Рекомендуемое |
| Тяжёлые third-party | PASS: скрипты аналитики/виджетов не ломают TBT; FAIL: деградация метрик | Performance → Bottom-Up/Call Tree; блокировка доменов для сравнения | Рекомендуемое |
| Перф-бюджеты | PASS: есть бюджеты по весу/метрикам; FAIL: изменения без контроля | Lighthouse CI / Webpack budgets / bundle analyzer | Опциональное |
Команды/сниппеты для быстрой диагностики:
npx lighthouse https://example.com --preset=desktopи отдельно прогон с мобильной эмуляцией в DevTools (важно сверять с реальными устройствами).- DevTools → Performance: ищите Long task и источники (скрипты, рендер, layout).
Адаптивная сетка, точки перелома и поведение макета
Что понадобится: доступ к репозиторию и сборке, макеты/компонентная библиотека (Figma/Storybook), список поддерживаемых устройств/браузеров, доступ к аналитике (хотя бы топ‑разрешения), тестовый стенд. Если вы хотите заказать адаптивный дизайн сайта, заранее зафиксируйте сетку, типографическую шкалу, состояния компонентов и правила для контента переменной длины.
| Параметр | Критерий (PASS/FAIL) | Метод тестирования | Приоритет |
|---|---|---|---|
| Точки перелома | PASS: брейкпоинты основаны на контенте/компонентах, а не на «моделях телефонов»; FAIL: частые переломы без причины | Responsive mode в DevTools; ручной ресайз; визуальные регресс‑тесты | Обязательное |
| Горизонтальный скролл | PASS: нет горизонтального скролла на типовых экранах; FAIL: появляется из‑за таблиц/картинок/слайдеров | DevTools → Rendering; CSS audit (overflow) | Обязательное |
| Контент переменной длины | PASS: длинные заголовки/цены/адреса не ломают сетку; FAIL: налезания и обрезания без правил | Тестовые данные (max-length), pseudo‑localization | Обязательное |
| Изображения в сетке | PASS: нет «прыжков» при загрузке; FAIL: CLS из‑за отсутствия размеров | Lighthouse/Performance; проверка атрибутов width/height | Рекомендуемое |
| Container queries / fluid-типографика | PASS: компоненты адаптируются внутри контейнеров; FAIL: завязка только на viewport | Проверка в современных браузерах; деградация для старых | Опциональное |
Мини‑сниппеты для контроля адаптива:
- Проверка опасных ширин: временно добавьте
*{outline:1px solid rgba(255,0,0,.05)}на стенде и ресайзьте. - Базовая защита от «вылетов» медиа:
img, video { max-width: 100%; height: auto; }(если не конфликтует с layout‑компонентами).
Тач‑жесты, зона досягаемости и элементы управления
- PASS/FAIL: основное действие доступно в нижней/средней зоне, не требует «акробатики» пальцем.
- PASS/FAIL: все цели тапа достаточно крупные и с нормальными отступами; нет «двойных» кликов по соседним ссылкам.
- PASS/FAIL: скролл не блокируется ненужными обработчиками, жесты не конфликтуют со свайп‑галереями/картами.
- PASS/FAIL: состояния (нажатие/фокус/disabled/loading) видимы; не полагаются только на hover.
Подготовка перед правками (быстрый список):
- Согласуйте карту критических пользовательских путей на мобильном (поиск → карточка → корзина → оплата).
- Соберите список интерактивных компонентов (меню, фильтры, карусели, модалки, поля ввода).
- Включите запись сессии/логирование ошибок на стенде (если доступно) или хотя бы консоль‑логирование на время теста.
- Проверьте на реальном устройстве: iOS Safari и Android Chrome (минимум по одному).
- Подготовьте тестовые данные: длинные названия, большие числа, пустые состояния, ошибки в формах.
-
Нормализуйте зоны тапа и расстояния между целями.
Проверьте, чтобы рядом стоящие элементы (иконки, ссылки, чек‑боксы/переключатели) не конкурировали за один тап и имели понятный «попадательный» прямоугольник.- Инструмент: DevTools → Elements → Box model; инспекция hit‑area.
- Практика: увеличивайте hit‑area через padding/псевдоэлементы, не меняя визуальный размер и не ломая сетку.
-
Уберите зависимость от hover и добавьте явные состояния.
На тач‑устройствах hover либо отсутствует, либо ведёт себя нестабильно; критические подсказки и действия должны быть доступны по тапу и иметь состояния pressed/focus/expanded.- Проверка: пройдите сценарий без мыши; в эмуляции включите «Emulate a focused page».
-
Проверьте жесты и конфликты скролла.
Свайпы, карусели и карты часто перехватывают скролл и ухудшают TTI/INP из‑за обработчиков.- Проверка: Performance профилирование при быстром скролле; ищите обработчики touchmove/scroll.
- Правило: ставьте
passive: trueдля scroll/touch слушателей, где это безопасно.
-
Оптимизируйте формы для мобильного ввода.
Подберитеinputmode,autocomplete, правильные типы полей и маски; минимизируйте количество обязательных полей и переключений раскладки.- Пример:
- Проверка: автопрокрутка к ошибке, понятные сообщения, сохранение введённых данных.
- Пример:
-
Проверьте модальные окна и нижние панели.
Модалки должны закрываться предсказуемо, не перекрывать системные элементы, не «прыгать» при появлении клавиатуры.- Проверка: iOS Safari с открытой клавиатурой; ориентация portrait/landscape.
| Параметр | Критерий (PASS/FAIL) | Метод тестирования | Приоритет |
|---|---|---|---|
| Размеры целей тапа | PASS: цели достаточно крупные и разнесены; FAIL: частые промахи по соседним элементам | Тест на реальном устройстве; инспекция hit‑area | Обязательное |
| Состояния компонентов | PASS: есть active/focus/disabled/loading; FAIL: состояние неочевидно | Клавиатурная навигация + тач; визуальная проверка | Обязательное |
| Скролл/жесты | PASS: скролл плавный, обработчики не блокируют; FAIL: дергания и задержки | Performance профилирование; отключение скриптов для A/B | Рекомендуемое |
| Формы и клавиатуры | PASS: корректные клавиатуры, автозаполнение, ошибки видны; FAIL: лишние шаги ввода | iOS Safari/Android Chrome; тест автозаполнения | Рекомендуемое |
| Сенсорные улучшения | PASS: уместные touch-action/scroll-behavior; FAIL: ломают UX |
Ручной тест; A/B на стенде | Опциональное |
Оптимизация изображений, шрифтов и медиаконтента
- PASS/FAIL: изображения отдаются в современных форматах (где возможно) и в нужных размерах, без лишнего веса.
- PASS/FAIL: у изображений заданы размеры (или аспект‑соотношение), нет заметных скачков макета (CLS).
- PASS/FAIL: критические изображения не откладываются, некритические — грузятся лениво.
- PASS/FAIL: шрифты не блокируют рендер и не вызывают сильные «переезды» текста.
- PASS/FAIL: видео не автозапускается без необходимости; есть постер и адекватное качество по сети.
- PASS/FAIL: карусели/галереи не тянут весь медиаконтент сразу.
- PASS/FAIL: inline‑SVG/иконки не дублируются тяжёлыми спрайтами без контроля кеша.
| Параметр | Критерий (PASS/FAIL) | Метод тестирования | Приоритет |
|---|---|---|---|
| Responsive images | PASS: используются srcset/sizes или эквивалент в вашем фреймворке; FAIL: всегда грузится «максимум» |
DevTools → Network (Img); сравнение на разных ширинах | Обязательное |
| Lazy-load | PASS: ниже фолда грузится лениво; FAIL: всё грузится сразу | Network waterfall; отключение кеша, throttling | Обязательное |
| Размеры и CLS | PASS: у медиа есть размеры/ratio; FAIL: заметные сдвиги при загрузке | Lighthouse (CLS), Performance, визуальный тест | Обязательное |
| Шрифты | PASS: разумная стратегия загрузки и fallback; FAIL: FOIT/FOUT мешает чтению | DevTools → Network (Fonts); наблюдение при cold load | Рекомендуемое |
| Видео | PASS: адаптивные источники/качества; FAIL: тяжёлый autoplay | Network; тест в 3G | Рекомендуемое |
| CDN/преобразование изображений | PASS: есть пайплайн трансформаций; FAIL: ручная загрузка «как есть» | Проверка заголовков/URL; сравнение форматов | Опциональное |
Быстрые примеры:
- HTML:
<img src="img-640.jpg" srcset="img-320.jpg 320w, img-640.jpg 640w, img-1024.jpg 1024w" sizes="(max-width: 640px) 100vw, 640px" width="640" height="360" loading="lazy" decoding="async" alt=""> - DevTools: включите Network throttling и посмотрите, не забивается ли канал медиаконтентом до появления текста.
Сети, кеширование, ленивый рендер и офлайн‑режим
Надёжная мобильная версия сайта должна деградировать аккуратно: сначала отдавать полезный контент, потом улучшения. Кеширование и ленивый рендер помогают, но чаще всего ломаются из‑за неверных заголовков, агрессивных prefetch и ошибок в Service Worker.
- Ошибка: кешируете HTML «намертво» — пользователи видят устаревшие страницы (FAIL: нет стратегии инвалидации).
- Ошибка: Service Worker перехватывает запросы без fallback — при сбое сети пустой экран.
- Ошибка: слишком ранний prefetch/prerender — забивает сеть на мобильном и ухудшает LCP.
- Ошибка: «ленивый» рендер ломает SEO/доступность — контент не появляется без JS или появляется слишком поздно.
- Ошибка: отсутствуют таймауты/повторы — запросы «висят», UI не сообщает о состоянии.
- Ошибка: не учитываете сохранение трафика — тяжёлые ресурсы грузятся даже при Data Saver.
- Ошибка: критические API без кеша/стабилизации — повторный заход такой же медленный, как первый.
| Параметр | Критерий (PASS/FAIL) | Метод тестирования | Приоритет |
|---|---|---|---|
| Throttling профили | PASS: сайт остаётся пригодным на медленной сети; FAIL: «белые экраны», долгие блокировки | DevTools Network throttling; тест на реальном 3G/плохом Wi‑Fi | Обязательное |
| HTTP кеш | PASS: статические ассеты кешируются с версионированием; FAIL: кеш не работает или не обновляется | DevTools → Network → Headers; повторные загрузки с отключенным/включенным кешем | Обязательное |
| Code splitting | PASS: загружается минимум для первого экрана; FAIL: один крупный бандл | Bundle analyzer; Coverage; Network | Рекомендуемое |
| Ленивые компоненты | PASS: ниже фолда/редкие блоки подгружаются по событию; FAIL: JS тянется заранее | Performance/Network; наблюдение таймингов | Рекомендуемое |
| Офлайн/плохая сеть | PASS: есть понятный fallback/страница ошибки; FAIL: непредсказуемое поведение | DevTools → Application (offline); ручная проверка | Опциональное |
Подсказка по безопасным настройкам: начинайте с корректного HTTP‑кеша и разделения бандлов. Service Worker включайте только когда есть тест‑план и стратегия обновления (иначе вы «закешируете» баги).
Доступность, локализация и особенности платформ
Альтернативы и расширения зависят от продукта и команды. Если обсуждаете разработка мобильной версии сайта цена, учитывайте, что доступность, локализация и платформенные особенности увеличивают объём тестирования и поддержки — но снижают риски и повышают качество.
- Только адаптив + прогрессивное улучшение — уместно для большинства контентных и e‑commerce проектов: один код, предсказуемая поддержка, меньше расхождений.
- Отдельная мобильная версия (m.site) или отдельный фронтенд — уместно, когда мобильные сценарии радикально отличаются и есть ресурсы поддерживать параллельно (иначе долг растёт).
- PWA (installable) как усиление — уместно, если важны повторные визиты, офлайн‑часть, быстрый запуск; требует дисциплины кеша и обновлений.
- Нативное приложение — уместно при сложных онлайновых сценариях, пушах, доступе к устройству; дороже в разработке и поддержке, но даёт лучший контроль UX.
| Параметр | Критерий (PASS/FAIL) | Метод тестирования | Приоритет |
|---|---|---|---|
| Фокус и навигация | PASS: фокус видим, порядок логичен; FAIL: «ловушки» и пропуски | Клавиатурный проход; DevTools Accessibility | Обязательное |
| Контраст и читаемость | PASS: текст читается на улице/низкой яркости; FAIL: низкий контраст | Проверка тем/состояний; Accessibility audit | Обязательное |
| Размер текста и масштаб | PASS: масштабирование не ломает UI; FAIL: фиксированные размеры, обрезания | Увеличение текста/масштаба в ОС; проверка в Safari iOS | Рекомендуемое |
| Локализация | PASS: строки расширяются, форматы дат/чисел корректны; FAIL: «выпирание» текста | Псевдолокаль; тест длинных строк | Рекомендуемое |
| Платформенные нюансы | PASS: учтены safe-area, клавиатура, back-gesture; FAIL: перекрытия и конфликт жестов | Реальные устройства iOS/Android; orientation change | Опциональное |
Если вы собираетесь заказать адаптивный дизайн сайта у подрядчика, включите в ТЗ критерии приёмки: списки PASS/FAIL, набор устройств, сценарии и минимальные метрики (LCP/TTI/TBT). Это снижает спорные моменты и ускоряет сдачу.
Практические ответы на типичные сомнения
Нужна ли отдельная мобильная версия сайта, если уже есть адаптив?
Обычно нет: адаптивная верстка сайта проще в поддержке и снижает расхождения. Отдельная мобильная версия оправдана, если мобильные сценарии принципиально другие и у вас есть ресурсы поддерживать две реализации.
Какие метрики брать для «приёмки» мобильного UX?
Минимальный набор для контроля: LCP, TTI и TBT (или их аналоги в вашей системе наблюдения). Важно фиксировать целевые значения под конкретные устройства/аудиторию, а не «в вакууме».
Что входит в аудит мобильной версии сайта на практике?
Снятие метрик производительности, проверка адаптива на ключевых ширинах, тач‑юзабилити, медиа‑вес, поведение в плохой сети и базовая доступность. Итог должен быть списком PASS/FAIL с приоритетами и планом исправлений.
Что написать в брифе, если хочу заказать адаптивный дизайн сайта?
Сценарии, контент‑типы, сетку/брейкпоинты, состояния компонентов, требования доступности и перечень устройств для теста. Отдельно — критерии приёмки по метрикам и чек‑листам.
Почему «разработка мобильной версии сайта цена» так сильно различается у разных команд?
Цена зависит от объёма компонентов, качества медиа‑пайплайна, глубины тестирования, требований доступности и от того, делаете ли вы отдельную мобильную версию или усиливаете адаптив. Чем строже критерии приёмки и шире матрица устройств, тем выше трудозатраты.
Какая самая частая причина провалов на мобильных?
Тяжёлый JS и медиа, которые блокируют рендер и ввод, плюс конфликтующие жесты/мелкие цели тапа. Это быстро выявляется профилированием Performance и тестом на реальном устройстве в медленной сети.
