верстка «съезжает» в Safari на iPhone: как найти причину за 20 минут

если форма заказа наезжает на текст в Safari на iPhone, а в Chrome на компьютере менеджера всё выглядит идеально — дело почти всегда в трёх вещах: нестандартных CSS-свойствах без вендорных префиксов, старой версии WebView на Android или блоке, который не проходит валидацию HTML. Проверяется это через эмуляцию реальных браузеров и устройств, а не через один десктопный Chrome.

сцена: форма заявки, которую никто не мог отправить с телефона

интернет-магазин мебели в Москве получал по 30-40 заявок в день с сайта. В понедельник утром менеджер заметил, что за выходные пришло всего три заявки вместо обычных пятидесяти-шестидесяти. Сайт открывался, каталог работал, но форма заказа на мобильной версии показывала кнопку «отправить» наполовину под полем ввода телефона.

на компьютере дизайнера в Chrome всё выглядело ровно. На ноутбуке верстальщика в Firefox — тоже. Но 70% трафика магазина шло с телефонов, и именно там кнопка пряталась. Проблему нашли не с первого раза: два дня ушло на то, чтобы просто её увидеть, потому что тестировали не на том устройстве, где она проявлялась.

что теряет бизнес, пока баг не найден

каждый день с неработающей формой на мобильной версии — это упущенные заявки, которые не вернутся: покупатель мебели не будет ждать, пока починят сайт, он откроет вкладку конкурента. При среднем чеке в мебельном сегменте потеря 40-50 заявок за выходные означает не просто «недополученную прибыль» — это конкретные сорванные сделки, которые уже утекли к тем, у кого форма работает.

но самая дорогая часть истории — не сами потерянные заявки, а время на диагностику. Владелец бизнеса тратит день на звонки верстальщику, который божится, что «у него всё работает», а разработчик тем временем проверяет код на своём экране, где баг не воспроизводится. Спор идёт вслепую, потому что никто не смотрит на реальную матрицу браузер-устройство-версия.

как аудит находит причину, а не симптом

шаг 1: собрать реальную статистику посетителей

прежде чем открывать десять браузеров подряд, смотрят в аналитику сайта: какие браузеры и версии реально используют посетители за последние 30 дней. Часто выясняется, что 15-20% аудитории заходит со старых версий Safari на iPhone или из встроенного браузера мессенджера — именно там баги проявляются чаще всего, потому что эти движки медленнее получают обновления CSS-стандартов.

шаг 2: проверить на реальных, а не виртуальных устройствах

эмулятор в DevTools меняет размер экрана, но не эмулирует особенности рендеринга WebKit на iOS. Форма с кнопкой, которая уезжает под поле ввода — классический случай, когда фикс-позиционирование ведёт себя иначе на iPhone из-за динамической панели адреса Safari, съедающей часть высоты экрана.

шаг 3: проверить валидность HTML и CSS

незакрытый тег или свойство без вендорного префикса браузер обычно «прощает» и достраивает разметку по своим правилам — а правила у Chrome, Safari и Firefox отличаются. Один непарный div выше по коду может сдвинуть блок только в одном из трёх движков, оставаясь незаметным в остальных.

шаг 4: проверить скрипты, которые могут падать тихо

JavaScript-ошибка в одном браузере может блокировать выполнение всего скрипта целиком, включая обработчик отправки формы, при этом визуально страница выглядит нормально. Консоль разработчика в проблемном браузере обычно показывает причину за минуту — но её редко открывают, если баг не воспроизводится на своём рабочем компьютере.

сравнение способов диагностики

почему баг находят долго, если искать в одиночку

владелец бизнеса или штатный верстальщик обычно проверяет то, что привычно: свой браузер, свой телефон, стандартное разрешение экрана. Но 15-20% посетителей сайта могут заходить с конфигураций, которые никто из команды физически не тестирует — старый Android с WebView двухлетней давности, встроенный браузер в мессенджере, Safari с включённым режимом чтения.

именно поэтому баг с формой заказа мебельного магазина нашли не за час, а за два дня: искали там, где привычно, а не там, где реально сидел баг. Системный аудит сразу проверяет весь набор конфигураций по статистике реальных посетителей сайта, а не по интуиции команды.

что входит в проверку и сколько это стоит

аудит корректности отображения — одно из направлений комплексной проверки сайта. Он включает тестирование в основных браузерах и их актуальных версиях, проверку на мобильных устройствах с разными операционными системами, валидацию HTML и CSS по стандартам, поиск скриптов с тихими ошибками и проверку адаптивной верстки на разных разрешениях экрана.

полная стоимость и состав входящих проверок указаны в разделе цены и тарифы. Отдельно от кросс-браузерности аудит сайта проверяет ещё восемь направлений — от скорости загрузки до безопасности форм, полный список — на странице аудит сайта по 9 направлениям. По итогу заказчик получает не список «у вас баг где-то там», а конкретный отчёт: какой браузер, какая версия, какой элемент верстки и какая строка кода тому виной.

для мебельного магазина из примера выше диагностика заняла два рабочих дня вместо тех двух дней, что ушли на слепые звонки верстальщику: причина оказалась в CSS-свойстве position: sticky без нужного префикса, которое iOS Safari интерпретировал иначе, чем Chrome. Правка заняла 20 минут, но найти её без системной проверки по матрице устройств было почти невозможно.

❓ Частые вопросы

как понять, что у сайта есть проблемы с кросс-браузерностью, если у меня всё работает?

смотрите статистику посетителей в аналитике: какие браузеры и версии они используют. Если там есть заметная доля Safari на iOS, старого Android или встроенных браузеров мессенджеров — вероятность скрытых багов высокая, даже если на вашем рабочем компьютере всё выглядит ровно.

сколько времени занимает аудит отображения сайта в браузерах?

обычно отчёт готов за 1-3 рабочих дня в зависимости от размера сайта и количества страниц с формами и интерактивными элементами. В отчёте указывается конкретный браузер, версия и элемент верстки, где найдена проблема.

можно ли проверить только мобильную версию, не трогая десктоп?

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

баг проявляется не всегда, а через раз — это тоже можно найти?

да, нестабильные баги обычно связаны с кэшированием старой версии CSS или скрипта у части пользователей, либо с гонкой состояний в JavaScript. При аудите такие случаи проверяются отдельно через принудительную очистку кэша и повторные тесты на разных сессиях.

а если проблема не в верстке, а в самом хостинге сайта?

такое тоже встречается: медленный отклик сервера иногда обрывает загрузку скриптов раньше времени, и браузер рендерит страницу без части стилей. Если причина в производительности сервера, а не в коде, это отдельно фиксируется в отчёте аудита с рекомендацией по инфраструктуре.