Mobile First у 2026: що перевірити в макеті, формах і ТЗ сайту

Mobile First означає порядок роботи: спочатку проєктують вузький екран, дотик і слабший процесор, а потім розширюють макет для планшета та десктопа. Є нюанс, який часто губиться: у світі смартфони давно переважають, але в українській статистиці картина інша. Нижче — як зрозуміти, наскільки мобільна версія важлива саме вашому сайту, що вимагає Google і що перевірити до запуску.

≈ 59 %

трафіку у світі йде з мобільних

вересень 2026

≈ 32 %

трафіку в Україні йде з мобільних

решта переважно десктоп

24 × 24 px

мінімальний розмір цілі за WCAG 2.2 (AA)

web.dev радить близько 48 px

Джерела: Statcounter Global Stats (вересень 2026), W3C WCAG 2.2, web.dev

Скільки у вас мобільних відвідувачів насправді

За даними Statcounter, у вересні 2026 року на мобільні пристрої припадало близько 59 % трафіку у світі. Для України той самий сервіс показує близько 32 %, решта — переважно десктоп. Чому так, ми не беремося стверджувати: вибірка Statcounter може відрізнятися від аудиторії конкретного бізнесу. Висновок для власника простіший: не вгадуйте, а дивіться у власну аналітику.

На практиці ми радимо зробити три речі:

розкласти трафік і заявки за категорією пристрою в GA4 і порівняти не лише кількість сесій, а й частку заявок з кожного пристрою;
окремо подивитися платні кліки з рекламного кабінету: аудиторія реклами може сильно відрізнятися від органічної;
звернути увагу на конверсію. Якщо мобільних візитів багато, а заявок з них мало, проблема майже завжди в зручності, а не в аудиторії.

Навіть якщо мобільних відвідувань третина, це кожен третій потенційний клієнт. А людина зі смартфона зазвичай шукає конкретне: телефон, адресу, ціну. Якщо на це піде більше кількох дотиків, вона піде до конкурента.

Mobile First і адаптивний сайт: не синоніми

Адаптивна верстка підлаштовується під ширину вікна: гнучка сітка, медіазапити, масштабована типографіка. Сайт може бути адаптивним, але зробленим desktop-first: спочатку повний десктопний макет, потім його «стискають» під телефон.

Mobile First — це порядок стилів і мислення: базові стилі для вузького екрана, а далі @media (min-width: …) для ширших. Плюси: менше зайвого CSS на телефоні, чіткіший пріоритет контенту і менший шанс, що дрібні екрани «доробляться» в останній день.

Підхід	З чого стартують	Типовий ризик
Desktop First	Великий макет	Перевантажена мобільна версія, дрібний текст, «зрізані» блоки
Mobile First	Вузький екран	Потрібна дисципліна: не тягнути на десктоп зайве без потреби

Технічна основа — тег viewport. Без <meta name="viewport" content="width=device-width"> частина мобільних браузерів малює сторінку у віртуальному вікні, ширшому за екран (MDN наводить приклад 980 px), а потім зменшує результат. Медіазапити під вузькі екрани в такому разі просто не спрацьовують.

Протилежна помилка — вимкнути масштабування через user-scalable=no. За MDN, це заважає людям із поганим зором, а WCAG вимагає, щоб сторінку можна було збільшити щонайменше вдвічі. До того ж браузери нерідко ігнорують це обмеження: iOS починаючи з десятої версії робить це за замовчуванням.

Що саме вимагає Google від мобільної версії

Google індексує й ранжує сайт за його мобільною версією. У документації є конкретні вимоги, і найчастіше на них спотикаються сайти з окремою «полегшеною» мобільною версією:

основний контент мобільної версії має бути еквівалентним десктопному; якщо його менше, Google прямо попереджає про можливу втрату трафіку;
однакові структуровані дані, title, description, мета-теги robots і alt-тексти зображень;
не підвантажуйте основний контент лише після дії користувача (свайп, клік, введення): Google такий контент не завантажить;
акордеони й вкладки на мобільному допустимі, якщо вміст еквівалентний десктопному.

Останній пункт знімає популярне побоювання. Ховати довгий текст в акордеон заради зручності можна; проблеми починаються тоді, коли блок на телефоні прибрано зовсім. Це наша інтерпретація документації, але вона узгоджується з її прямим текстом.

Швидкість і Core Web Vitals — окрема тема. Нагадаємо лише, що телефон середнього класу має слабший процесор за ноутбук, тож кожен сторонній скрипт там коштує дорожче.

Тач-цілі: розмір, який не «промазують»

Тач-ціль — це будь-який елемент, який людина натискає пальцем: кнопка, пункт меню, іконка, чекбокс. Орієнтири з документації різні, і корисно знати обидва:

Джерело	Розмір цілі	Примітка
WCAG 2.2, критерій 2.5.8 (рівень AA)	не менше 24 × 24 CSS-пікселів	винятки: достатній відступ, посилання всередині тексту, еквівалентний елемент
web.dev, рекомендація	близько 48 × 48 px (приблизно 9 мм)	відступ між цілями близько 8 px

Збільшувати саму іконку не обов’язково. Web.dev радить додати padding, щоб зона дотику виросла до 48 px, а іконка лишилася, скажімо, 24 px. Збільшену зону можна вмикати лише для сенсорних пристроїв через @media (any-pointer: coarse).

Наш совет: перевіряйте насамперед те, що натискають найчастіше. Це кнопка дзвінка, пункти меню, закриття модального вікна, іконки месенджерів у шапці й підвалі, чекбокси в формі. Саме там дрібні цілі найсильніше б’ють по заявках.

Форми: де мобільний сайт найчастіше втрачає заявки

Форма на телефоні — місце, де розбивається більшість зусиль із реклами. Рекомендації web.dev щодо форм зводяться до кількох правил:

кожне поле має label, а не лише підказку всередині;
правильні type і autocomplete, щоб браузер міг підставити дані; для номерів, які не збільшують і не зменшують (наприклад, номер картки), не використовуйте type="number", а беріть текстове поле з inputmode="numeric";
блокуйте кнопку відправки після натискання, щоб не було подвійних заявок;
перевіряйте дані під час введення, а не лише після відправки;
не питайте те, що вам не потрібне, і приймайте ім’я одним полем.

На практиці для українського малого бізнесу додамо: поле телефону з type="tel", маска, яка не ламається при вставці номера з буфера, і поряд зрозумілі альтернативи для тих, хто не любить форм, — дзвінок одним дотиком і кнопка в месенджер.

Сучасний CSS: менше breakpoints, більше гнучкості

Десять «магічних» ширин у медіазапитах — ознака слабкої верстки. Обирайте точки перелому за вмістом: там, де рядок стає завеликим чи сітка ламається, а не під назви конкретних пристроїв. Зручно доповнювати це кількома прийомами:

контейнерні запити (@container) змінюють компонент залежно від ширини його контейнера, а не вікна, тому картка однаково працює і в вузькому сайдбарі, і на всю ширину;
одиниці svh і dvh враховують панель браузера, що ховається при прокручуванні: повноекранний блок не «з’їдається» адресним рядком;
viewport-fit=cover разом зі змінними env() потрібен для пристроїв із вирізом: MDN радить через них відступати від країв, щоб важливе не обрізалося;
плавна типографіка через clamp() замінює пачку медіазапитів для розмірів шрифту.

Типові помилки

«Мобільна версія — це зменшений десктоп»: нечитаний текст, форми, що вилазять за екран.
Ховер як єдиний спосіб відкрити меню чи підказку: на сенсорному екрані ховера немає.
Повноекранний попап одразу після відкриття: людина ще не побачила сторінку, а їй уже щось пропонують.
Фіксована панель, що перекриває кнопки й поля, особливо коли з’являється екранна клавіатура.
Меню без доступності з клавіатури та для скрінрідерів: втрачена частина аудиторії й сигнал низької якості.

Як перевірити мобільну версію до запуску

Порядок роботи над мобільною версією

1

Контент і пріоритети

що людина має побачити першим на вузькому екрані
2

Базові стилі

макет для вузького екрана без медіазапитів
3

Розширення

планшет і десктоп через min-width
4

Тест у DevTools

режим пристрою з обмеженням мережі й процесора
5

Реальні телефони

Android, iPhone і хоча б один старіший пристрій

Схема авторська; кроки тестування — за документацією Chrome for Developers

Режим пристрою в Chrome DevTools показує розмір екрана й вміє «душити» мережу та процесор. Є пресет Mid-tier mobile (швидка 3G, процесор у 4 рази повільніший) і Low-end mobile (повільна 3G, у 6 разів повільніший). Документація чесно називає це наближенням першого порядку: код не запускається на справжньому телефоні, тому фінальну перевірку робіть на живих пристроях.

Короткий чек-лист для приймання:

Немає горизонтального скролу на вузькому екрані (орієнтуйтеся приблизно на 320–360 px).
Усі кнопки й посилання без зусиль натискаються великим пальцем, без промахів.
Форма заповнюється з екранною клавіатурою, а поле не ховається під нею.
Дзвінок і месенджер доступні одним дотиком.
Масштабування сторінки не вимкнено, текст читається без збільшення.
На мобільній версії є той самий основний контент, що й на десктопній.

Що зафіксувати в ТЗ

Цільові ширини й список пристроїв, на яких приймається верстка.
Мінімальні розміри тач-цілей і відступів, хоча б за рівнем WCAG AA.
Поведінку форм, фільтрів і таблиць на вузькому екрані: як саме вони перебудовуються.
Вимоги до швидкості в мобільному режимі й до тестування на реальних пристроях.
Окремим рішенням: потрібен чи ні PWA, а не «за замовчуванням».

Ці пункти зручно закласти вже в бриф, коли ви замовляєте адаптивний сайт для компанії: тоді мобільна версія не стає доробкою наприкінці проєкту.

Що робити далі

Почніть із власної аналітики: частка мобільних візитів і конверсія за пристроями. Потім відкрийте головну й сторінку з формою на реальному телефоні та пройдіть чек-лист вище. Виправляйте за пріоритетом: форми, тач-цілі, перший екран.

Хочете, щоб ми подивилися ваш сайт на телефоні й назвали, що виправляти насамперед? Напишіть нам.

Автор: Сергій Філатьєв — засновник авторської студії Veb-Dev.