Сайт малює дизайнер на 27-дюймовому моніторі, погоджує директор із ноутбука, а дивиться його жінка в метро з тріснутим екраном і однією рукою. Розрив між цими трьома сценаріями коштує реальних заявок. Нижче — що конкретно означає проєктувати mobile-first: у якому порядку робити макети, які розміри тапів працюють, чому плавність скролу важливіша за анімацію і як це перевірити, не покладаючись на емулятор у браузері.

Mobile-first — це не «зменшити десктоп»

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

• Обмеження працює як фільтр. На 375 пікселях ширини фізично поміщається один заголовок, один абзац і одна кнопка. Те, що не пройшло цей відбір, зазвичай не було потрібне й на десктопі.
• Пріоритет стає видимим. Порядок блоків у мобільному макеті — це і є ваша воронка. Якщо ціна опинилась нижче за історію компанії, ви щойно побачили проблему позиціонування.
• Продуктивність закладається одразу. Коли макет починається з телефона, важкі фонові відео й паралакси просто не встигають потрапити в проєкт — їх немає у вихідній версії.
• Пошук оцінює мобільну версію. Індексується саме те, що бачить телефон. Контент, схований під «показати ще» на мобільному, — це контент, який ви приховали від пошуку.

Порядок роботи, який реально працює

1. 1

   Один екран — одне рішення

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

2. 2

   Макет 375 пікселів першим

   Це нижня межа, яка досі поширена. Якщо композиція виживає тут, на 430 і на 1440 вона виживе теж. Зворотний шлях не працює ніколи.

3. 3

   Дві контрольні точки замість п’яти

   На практиці вистачає переходів приблизно на 640 і 1024 пікселях. Більше точок — більше станів для тестування і більше місць, де верстка розʼїжджається.

4. 4

   Типографіка й сітка до кольору

   Розмір базового тексту від 16 пікселів, міжрядковий інтервал 1,5, довжина рядка 45–75 символів. На телефоні саме це визначає, чи дочитають текст.

5. 5

   Стани елементів окремим екраном

   Пусті списки, довгі назви товарів, помилки форми, довантаження. Пропущені стани — головна причина того, що готовий сайт виглядає гірше за макет.

Пальці, зона великого пальця й форми

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

Плавність скролу важливіша за анімацію

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

• Розмиття фону — найдорожчий ефект у списку. Один напівпрозорий блок із розмиттям на липкій шапці здатен зʼїсти половину кадрового бюджету на скролі.
• Анімації, що не зупиняються — пульсуючі кнопки, градієнти, що переливаються, обертові фігури. Вони працюють, поки сторінка відкрита, навіть коли їх не видно.
• Анімація не тих властивостей — рухати варто transform і opacity. Зміна width, top чи margin змушує браузер перераховувати всю розкладку.
• Зображення без розмірів — без явних width і height контент стрибає під час завантаження, і це прямо псує показник зсуву макета.

/* Дорогі ефекти лишаємо десктопу з мишею,
   і завжди поважаємо системне налаштування руху */
.panel {
  background: rgba(12, 14, 18, 0.92);
}

@media (min-width: 1024px) and (hover: hover) {
  .panel {
    background: rgba(12, 14, 18, 0.6);
    backdrop-filter: blur(12px);
  }
}

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

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

Як перевірити, а не сподіватись

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

Часті питання про mobile-first

Коротко

• Mobile-first — це порядок проєктування, а не набір медіазапитів. Макет починається з 375 пікселів, інакше телефон отримає обрізаний десктоп.
• Палець потребує 48 пікселів зони дотику, поля — шрифту 16 пікселів, головна дія — нижньої третини екрана.
• Плавність скролу дорожча за анімацію: розмиття фону й нескінченні ефекти прибирайте з мобільної версії першими.
• Індексується мобільна версія, тому видалений з неї контент зникає й з пошуку.
• Перевіряйте на реальному середньому телефоні, при повільному зʼєднанні й зі збільшеним системним шрифтом.