Почему мобильная версия стала основной
Поисковые системы оценивают сайт преимущественно по тому, как он выглядит и работает на телефоне. Практическое следствие важнее самого факта: если на мобильной версии нет блока, который есть на десктопной, при оценке его нет вовсе.
Отсюда меняется порядок работы. Раньше делали сайт и адаптировали под телефон, теперь исходной берут узкую ширину, а на широком экране добавляют пространство и второстепенные элементы.
Что ломается чаще всего
| Поломка | Как проявляется | Где искать причину |
|---|---|---|
| Горизонтальная прокрутка | Страница ездит вбок, часть текста за краем | Один широкий элемент: таблица, изображение, длинная строка кода |
| Мелкие цели нажатия | Промахи по кнопкам и ссылкам | Цели меньше примерно сантиметра или стоящие вплотную |
| Перекрытие содержимого | Липкая панель закрывает текст или поле ввода | Фиксированные шапка и нижняя панель без компенсации отступом |
| Неверная клавиатура | В поле телефона открывается буквенная раскладка | Не задан тип поля ввода |
| Потерянный фокус | При открытии клавиатуры поле уезжает за экран | Нестандартная прокрутка или модальное окно с фиксацией |
| Невидимая ошибка формы | Сообщение об ошибке выше видимой области | Ошибки выводятся общим списком сверху, а не у поля |
Первая строка — самая частая и самая незаметная: на десктопе такой страницы просто нет, а на телефоне достаточно одной широкой таблицы, чтобы вбок поехал весь макет.
Палец вместо курсора
Различие глубже, чем размер цели.
Нет состояния наведения. Подсказка, появляющаяся при наведении, на сенсорном экране недоступна. Если в ней содержится что-то нужное — оно потеряно.
Палец закрывает то, на что нажимает. Элемент, меняющий вид под пальцем, изменения не покажет.
Промах стоит дороже. На десктопе неверный клик исправляется мгновенно, на телефоне часто означает переход на другую страницу и возврат.
Край экрана — рабочая зона. Действия в верхних углах на большом телефоне требуют перехвата устройства; основное действие уместнее держать в нижней половине.
Формы
Форма на телефоне ломается не там, где на десктопе. Количество полей важно, но первым делом стоит проверить другое: форма заявки разбирает состав полей, здесь — мобильную специфику.
Тип поля определяет клавиатуру: для телефона должна открываться цифровая, для почты — раскладка со знаком собаки. Автозаполнение работает, только если полям заданы понятные браузеру имена, — иначе человек набирает адрес вручную на маленькой клавиатуре. Сообщения об ошибках должны стоять у своего поля: список сверху при открытой клавиатуре не виден. Часть этих поломок снимается заменой ввода выбором — отметить готовый ответ легче, чем набрать его на маленькой клавиатуре, — отчего квизы и удобны на телефоне, хотя главное отличие квиза от формы не в удобстве ввода, а в том, какую пользу человек видит прежде, чем назовёт свой номер.
Высокий процент выходов только с телефонов. Сравните показатель по устройствам в аналитике. Расхождение указывает на поломку вёрстки, а не на содержание — начните с проверки горизонтальной прокрутки.
Заявки приходят с десктопа, с телефона почти нет. Проверьте форму на реальном устройстве целиком, до отправки. Чаще всего дело в клавиатуре, автозаполнении или невидимой ошибке валидации.
Люди возвращаются в выдачу через несколько секунд. Обычно скорость: на мобильной сети страница собирается дольше. Разбор — скорость загрузки.
Часть контента исчезла из индекса после редизайна. Блоки не попали в мобильную вёрстку. Сравните, что отдаётся в мобильной версии, с тем, что есть на десктопной.
Порядок проверки
- Открыть на реальном устройстве — не в узком окне браузера. Эмулятор показывает размеры, но не клавиатуру, не попадание пальцем и не поведение при медленной сети.
- Проверить горизонтальную прокрутку на каждом типе страниц: главная, раздел, статья с таблицей, форма.
- Пройти целевой путь целиком — от входа до отправки заявки, не пропуская шаги.
- Посмотреть при медленном соединении — так видно, что появляется первым и не прыгает ли макет при догрузке.
- Сверить содержимое мобильной и десктопной версий: блоки должны совпадать.
Критерий готовности каждого шага — не «выглядит нормально», а «действие выполнено до конца без промахов и возвратов».
Где правило mobile-first не работает
Есть задачи, которые на телефоне решаются редко и вопреки удобству. Профессиональные интерфейсы с большими таблицами, редакторы, панели управления рекламой — их основной сценарий десктопный, и урезать десктопную версию ради симметрии вредно.
Различать помогает не тип бизнеса, а данные по устройствам в аналитике. Если доля мобильных визитов в разделе устойчиво мала на протяжении месяцев — приоритет там действительно другой. Но проверять это нужно по своим числам, а не по общему правилу, и отдельно для каждого раздела: юзабилити обычно расходится между витриной и личным кабинетом сильнее, чем между сайтами.
Текст на маленьком экране
Читаемость ломается тише, чем вёрстка, — страница выглядит целой, но её перестают читать.
Размер и межстрочное расстояние. Основной текст мельче 16 пикселей заставляет браузер предлагать увеличение, а увеличенная страница почти всегда едет вбок. Строки, стоящие вплотную, на маленьком экране слипаются сильнее, чем на большом.
Длина строки. На узком экране она задана шириной устройства, поэтому регулировать приходится боковыми отступами. Текст, прижатый к самым краям, читается хуже: взгляду не за что зацепиться при переходе на новую строку.
Абзацы и подзаголовки. Экран телефона вмещает примерно один абзац, поэтому сплошной текст на пять абзацев выглядит как стена без ориентиров. Подзаголовки здесь работают не украшением, а навигацией — по ним человек понимает, где он находится.
Таблицы. Главный источник горизонтальной прокрутки. Таблица должна прокручиваться внутри собственного контейнера, а не растягивать всю страницу; узкие колонки при этом лучше не сжимать до переноса каждого слова.
Навигация
Меню под кнопкой экономит место и одновременно прячет структуру: человек не видит, что на сайте есть ещё разделы, пока не нажмёт. Для сайта с двумя-тремя разделами это лишний шаг — их проще показать сразу.
Что стоит проверить отдельно: закрывается ли открытое меню кнопкой возврата, не остаётся ли страница под ним заблокированной, доступен ли поиск по сайту без раскрытия всего меню, и виден ли текущий раздел — на телефоне ориентир «где я» теряется быстрее, чем на десктопе, где рядом стоит боковая колонка.
Отдельная проверка — путь назад. Человек, пришедший из выдачи сразу на внутреннюю страницу, не видел ни главной, ни меню: хлебные крошки и ссылка на раздел в конце материала для него единственный способ понять, куда он попал.
Спорное место
Мобильная оптимизация превратилась в набор ритуалов, часть которых давно не связана с результатом. Проверка «оптимизировано для мобильных» проходится сайтом, на котором невозможно заполнить форму, — она смотрит на ширину и размеры целей, но не на то, доходит ли человек до конца пути.
Отсюда разумная рамка: технические проверки годятся как фильтр от грубых поломок, а вывод о пригодности даёт только прохождение целевого сценария на реальном устройстве. И ещё одно — доля мобильных визитов не аргумент в споре о приоритете, если конверсия с телефона втрое ниже: это может означать и что аудитория там другая, и что версия сломана. Различить помогает не спор, а разбор пути по шагам.
Частые вопросы
Нужна ли отдельная мобильная версия на поддомене?
Можно ли прятать часть текста под кнопку «показать ещё»?
Насколько важна скорость именно на телефоне?
Как проверить, что ничего не разъехалось?
Источники
- Адаптивный веб-дизайн — Wikipedia