Мобильный фронтенд Что замерено на боевом сайте, почему это ломается и в каком порядке чинить

00Итог

Сайт не является мобильным. Это десктопный сайт, у которого местами включены tailwind-брейкпоинты. Разница принципиальна: адаптив здесь — сужение десктопного макета, а не отдельный мобильный сценарий. Отсюда и отзывы.

Пять фактов, снятых инструментально с боевого сайта — не гипотезы:

Ни одна из этих проблем не чинится правкой пары классов. Нужен слой мобильных примитивов — лист-шторка, безопасные зоны, тач-цели, единицы вьюпорта, — и уже поверх него переработка шести ключевых экранов. Работа разбита на шесть волн; первые две закрывают около 80 % видимой боли.

▸Статус: волны В1–В5 сделаны

Пять волн из шести сделаны 31.08.2026: фундамент, навигация, первое касание, ядро продажи (карточка и фильтры) и кабинет с данными. Осталась последняя — вес страницы и документация API. Цифры ниже сняты тем же скриптом, что и цифры «до», на сборке с боевым API — то есть с реальными карточками, а не на пустой странице.

Правки по код-ревью

Параллельная сессия прислала пять замечаний по этим файлам. Все подтвердились чтением кода и исправлены:

По тому же следу нашлась та же болезнь в карточке автомобиля, где ревью её не искало: в зазоре 640–767 px выходил гибрид — ряд действий как на компьютере, но без закреплённой кнопки «Заказать», и при этом уже свёрнутые разделы. Восемь мест приведены к одной границе.

Битые картинки: закрыто до конца

Одиннадцать мест грузили фото без запасного варианта — при сбое отдачи там появлялась иконка битой картинки. Девять сделал коллега (это его область), два оставшихся в моих файлах добрал я. Теперь в проекте не осталось ни одного изображения, которое при сбое покажет «сломанную картинку» вместо заглушки.

Побочный выигрыш: плиткам списков перестала прилетать картинка в 1600 px — запрашивается размер под место показа.

Урок про общее рабочее дерево

Две параллельные сессии в одной папке — и мою работу дважды утащили чужие коммиты. Второй раз спровоцировал я сам: добавил файлы в индекс, чтобы они ушли вместе с настройкой выкладки, и следующий же коммит соседа забрал индекс целиком. Правило, к которому пришли: добавление файла в индекс на общем дереве — это не защита, а способ подарить его следующему коммиту.

Два бага, которые не ловит ни одна моя проверка

Третьим заходом коллега нашёл то, что не видно ни в разметке, ни в размерах:

• Форма фильтров была бы неработоспособна на телефоне. Защита от «выпадания» из шторки перезапускалась на каждое изменение и отбирала фокус у поля ввода. Воспроизвёл до правки: набираю «Toyota» по букве — в поле остаётся одна «T», клавиатура на телефоне схлопывается. После правки текст вводится целиком.
• Лента на главной показывала каталог дважды подряд и упиралась в конец. Список дублировался ради бесшовной прокрутки, но сама прокрутка на телефоне выключена — и дубль превращался в «те же сорок машин ещё раз». Замер после правки: телефон 40 плиток, компьютер 80.

Обе — про поведение, а не про вёрстку: автопроверка видит корректную разметку, правильные размеры и отсутствие переполнения. Это её граница, и её стоит помнить.

Дыры в самих проверках

Вторым заходом коллега разобрал не код, а инструменты. Это оказалось важнее любой отдельной правки вёрстки: проверка, которая зелёная по недосмотру, хуже отсутствующей.

Отдельно: коллега убрал из набора вариантов картинки самый крупный — сервер его не всегда создаёт. Это ломало мой вызов в карточке: при заданном наборе браузер игнорирует основной адрес, и главное фото навсегда осталось бы мелким. Набор с главного фото снят — замер после правки: 1200×900 в слоте 766 px.

Что появилось в коде

• Примитивы: Sheet (нижняя шторка со свайпом, ловушкой фокуса и блокировкой фона), Gallery (свайп на CSS scroll-snap), useBodyScrollLock, useMediaQuery, carImageSrcSet, утилита .tap-44. Шторка и галерея созданы, но подключаются в волнах В3–В4.
• Токены: адаптивный container.padding (+32 % полезной ширины на 360 px), h-screen→100dvh, безопасные зоны, переменные --navbar-h и --composer-h вместо магических констант.
• Починенные примитивы: диалог получил max-height и прокрутку (без них контент выше экрана обрезался без возможности прочитать), у тостов крестик перестал прятаться за hover, кнопки и поля выросли до 44 px на тач.
• Навигация: нижний таб-бар из пяти пунктов с подписями; шапка на телефоне ужата до трёх элементов; композер чата и плавающая кнопка ленты садятся над баром по измеренной высоте, а не по подобранной константе.
• Гарды в CI: scripts/mobile_audit.py валит сборку на горизонтальном переполнении, авто-зуме, целях меньше 24 px и мелком тексте; verify-no-fixed-viewport-units.sh запрещает возврат 100vh. Первая же версия таб-бара с подписями 10 px была поймана этой проверкой.
• Волна В5 — кабинет и данные. Вкладки кабинета получили подписи (были четыре немаркированные иконки). Описание заявки на телефоне — метка над значением вместо колонки в 130 px. Переписка стала полноэкранной с полем ввода внизу. Таблица сравнения перестала жать цену в 94 px. И главное: фото объявления теперь ужимаются прямо в браузере — снимок с камеры на 3–5 МБ превращается в пару сотен килобайт до отправки.
• Волна В4 — ядро продажи. Карточка автомобиля на телефоне стала полноэкранной: сверху закреплены закрытие, название и меню действий, снизу — цена и «Заказать». Фото листаются пальцем со счётчиком кадров. Самые длинные разделы (все характеристики, комплектация — до двухсот полей) свёрнуты. Форма фильтров уехала в шторку с закреплённым внизу счётчиком «Найти · N», а на странице поиска остались чипы применённых фильтров, снимаемые одним тапом.
• Волна В3. Лендинг: герой без переносов, единый ритм секций, 17 контентных карточек уплотнены (иконка в строку с заголовком на телефоне), липкая лента якорей разделов взамен скрытого бокового рейла, у автобегущей ленты появилась пауза — а на тач она вообще не бежит. Чат: обе шторки переведены на общий Sheet со свайпом и блокировкой фона. Карточка авто: зоны нажатия 44 px поверх фото без изменения рисунка, заголовок в две строки вместо обрезки, srcset по ярусам, ховер-подъём убран с тач (там он залипал).

02Доказательства

Скриншоты сняты Chromium в мобильной эмуляции, 360×740, DPR 2, боевой tazzz.ru.

01Что именно называется «мобильной версией»

Уточнение до начала работ, иначе усилия уйдут не туда.

Отдельного мобильного шаблона, маршрута или приложения нет и не планируется. Продукт — адаптивный SPA: одна кодовая база, одни маршруты.

Что известно об аудитории

Данных мало, и это само по себе дефект. Хроника покупателя пишет viewport_width, но только для залогиненных и только с 27.08 — выборка непригодна. По логам nginx за 27–31.08, среди уникальных IP, реально загрузивших бандл: 24 десктоп против 6 мобильных (~20 %). Мобильные — iOS Safari 16–26 и Android 6–15: значит критичны dvh, безопасные зоны, правило 16 px против авто-зума и бюджет JS для слабого железа.

Вывод, которого делать нельзя: «мобильных мало, значит неважно». 20 % при известном качестве мобильной версии — это не спрос, а его отсутствие из-за качества.

03Диагноз

Тринадцать системных дефектов. Каждый — с доказательством и следствием для пользователя.

04Принципы

Контракт, по которому проверяется любой будущий PR к фронту.

05Фундамент — волна В1

Без этого слоя переработка экранов превратится в 30 локальных заплаток.

Семантика брейкпоинтов

Значения оставляем дефолтные, но фиксируем смысл: сейчас sm: используется и как «не телефон», и как «широкий телефон», из-за чего поведение непредсказуемо. md — единственная граница смены парадигмы; sm меняет только число колонок. Нижняя граница поддержки — 320 px, проектная точка — 360.

Токены отступов

container: { padding: { DEFAULT:'1rem', sm:'1.5rem', lg:'2rem' } }   // было '2rem' везде
CardHeader / CardContent / CardFooter:  p-4 md:p-6

Эффект на 360 px: полезная ширина 248 → 328 px (+32 %).

Безопасные зоны и вьюпорт

.pb-safe   { padding-bottom: max(0.75rem, env(safe-area-inset-bottom)); }
.pt-safe   { padding-top:    max(0.75rem, env(safe-area-inset-top)); }
.pb-navbar { padding-bottom: calc(3.5rem + env(safe-area-inset-bottom)); }

height: { screen:'100dvh', 'screen-s':'100svh' }    // + minHeight, maxHeight

svh — для оболочек, которые не должны «дышать» при скрытии панели браузера; dvh — для того, что обязано занимать реально видимую область. Защита от регресса — грит в CI: литералы vh и h-screen в src/** запрещены.

Новые примитивы

06Поверхности

S1 · Навигация — самый важный пункт спецификации

На телефоне верхняя панель ужимается до трёх элементов: бургер · логотип · аватар. Появляется нижняя навигация — fixed bottom-0 h-14 pb-safe, пять пунктов с иконкой и подписью: Чат · Поиск · Радар · Сообщения · Профиль. «История» и «Аналитика» уходят во второй уровень: первая — разрез профиля, вторая — вход из карточки авто. Бар скрывается при открытой шторке и при фокусе в композере. На десктопе всё как сейчас.

Почему нижняя, а не бургер: видимая навигация обнаруживается ~48 % пользователей против ~21 % у скрытой; точность нажатия в нижней зоне ~96 % против ~61 % вверху.

07Бюджет производительности

Цель — «good» по Core Web Vitals на классе Moto G Power / 4G.

Меры в порядке «эффект / стоимость»:

1. Разбиение по маршрутам. В отдельные чанки: /docs/api, весь кабинет перевозчика, аналитика, классические фильтры (2577 строк), сообщения, кабинет. Лендинг гостя должен тянуть только лендинг. Ожидаемо 411 → 150–180 KB.
2. manualChunks: react/router — отдельный долгоживущий вендорный чанк, framer-motion — отдельно (нужен не всем маршрутам).
3. Brotli на nginx: −15–20 % к каждому текстовому ответу.
4. srcset / sizes / loading / fetchpriority.
5. Самохостинг шрифтов с подмножеством кириллицы; убрать блокирующий <link> на fonts.googleapis.com.
6. Композитинг: backdrop-blur-2xl → blur-xl на тач; дрейф аврора-фона гасить на мобильном (фон остаётся, анимация выключается).
7. content-visibility: auto ниже сгиба; виртуализация списков при N > 100.

09Приёмка

Автопроверка в CI — часть работы, не «потом»

Репозиторий тестируется ад-хок-скриптами; вписываемся в этот стиль, не притаскивая новый фреймворк. scripts/mobile-audit.mjs для каждого маршрута × {360×740, 390×844} валит сборку при нарушении:

1. scrollWidth ≤ clientWidth + 1 — нет горизонтального переполнения.
2. innerWidth === viewport.width — нет авто-зума (ловит случай /docs/api).
3. Нет интерактивных элементов меньше 24 px.
4. Число элементов меньше 44 px не растёт относительно baseline-файла в репозитории — улучшать постепенно можно, ухудшать нельзя.
5. Нет текста меньше 12 px; все <img> с loading и пропорциями.

Матрица устройств

Обязательно: портрет и альбом; с открытой клавиатурой; в Safari с показанной и скрытой нижней панелью; свайп «назад» от левого края iOS не должен конфликтовать со свайпом галереи на первом кадре.

10План работ

Внутри волны порядок свободен. В1 обязана быть первой — иначе В2–В6 наплодят локальных решений одних и тех же задач.

11Решения и риски

• Не делаем отдельное мобильное приложение и не оживляем frontend-v2. Nuxt/Tauri-версия не деплоится, отстала от API и дублирует продукт. Если приложение понадобится — это отдельное решение с ADR, а не побочный эффект этой работы.
• Не переходим на UI-библиотеку. Переезд на mui/mantine ради «готового мобильного» переписал бы весь фронт. Добавляем три своих примитива и правим существующие.
• Не вводим мобильные компоненты-дубли. Один компонент, разное поведение внутри: дубли разъезжаются через два спринта.
• Главный риск — модалка авто (1424 строки) и панели фильтров (2577 строк). Правило: сначала выносим структуру, потом меняем поведение; каждая правка — отдельный коммит; tsc --noEmit и селфтест фильтров после каждого шага.
• Риск нижней навигации на iOS: панель Safari и жестовая полоса конкурируют за нижние ~50 px. Смягчение — pb-safe, проверка на живом iPhone и готовность откатить бар за флагом.
• Не трогаем бизнес-логику. Спецификация — про компоновку, ввод, жесты, вес и доступность. Расчёт стоимости, фильтры, реалтайм и ярусы фото по существу не меняются.

Открытые вопросы к владельцу

1. Состав пяти пунктов нижней навигации (предложение: Чат · Поиск · Радар · Сообщения · Профиль).
2. Ярус фото 800 px между thumb-480 и full-1600: стоимость диска против качества на телефоне.
3. PWA — ограничиться манифестом и иконками или доводить до устанавливаемого приложения.
4. Тестовый аккаунт в CI: без него половина маршрутов вне автопроверки.