Проверять нужно не все браузеры, а четыре сценария с основным трафиком: Chrome и Яндекс.Браузер на десктопе, мобильный Safari на iOS, Chrome на Android с открытой клавиатурой. Чаще всего ломаются flexbox без учёта min-width, единица 100vh в Safari и увеличенный масштаб страницы в Яндекс.Браузере. Проверка занимает около получаса.
Один CSS, три разных результата
Вёрстка, которая идеально легла в Chrome на вашем ноутбуке, не гарантирует ничего для посетителя с айфоном 2019 года или с Яндекс.Браузером, где включено увеличение шрифта до 130 процентов. У каждого браузерного движка свои допущения о том, как считать высоту блока, где ставить перенос строки и как вести себя sticky-элементу.
Для лендинга это не абстрактная проблема вёрстки, а прямая потеря заявок: если кнопка формы уехала за край экрана на треть трафика, вы теряете эту треть молча, без единой ошибки в консоли.
Проверять всё руками долго, но пропустить проверку ещё дороже: цена клика в Директе для многих ниш малого бизнеса от 40 до 150 рублей, и каждый визит с разъехавшейся вёрсткой - это выброшенные деньги без единого шанса на заявку.
Какие браузеры нужно проверять на лендинге?
Проверять все существующие браузеры бессмысленно. По статистике посещаемости российских лендингов из моей практики трафик почти всегда распределяется между четырьмя движками: Chrome и его клоны на Android, мобильный Safari на iOS, Яндекс.Браузер (тоже на движке Chromium, но с собственными надстройками) и десктопный Chrome или Edge. На эти четыре сценария приходится обычно 90-95 процентов визитов.
Отдельно стоит держать в уме старые версии Safari: часть аудитории 45+ годами не обновляет iPhone, и версия iOS у них может отставать на три-четыре релиза.
Флексбокс и грид: где чаще всего ломается
Самые частые баги вёрстки лендинга приходятся не на экзотику, а на банальный flexbox. Блок с тремя карточками в ряд, где ширина задана в процентах без учёта gap, в одном браузере сжимается ровно, а в другом карточки переносятся по одной. Вторая частая беда - min-width по умолчанию у флекс-элементов: текст внутри карточки не сжимается, а раздвигает контейнер вширь, и на маленьком экране вся строка уезжает вбок.
Safari и вебкит: свои причуды
Мобильный Safari славится проблемой с единицей 100vh: она считается от полной высоты экрана, а не от видимой области за вычетом адресной строки, поэтому блок на весь экран обрезается снизу кнопкой браузера. Лечится через dvh или через JS-расчёт реальной высоты.
Вторая частая причина отличий - position: sticky внутри контейнера с overflow. В Chrome это иногда прощается, в Safari sticky-элемент просто перестаёт прилипать. Третья мелочь, которая ловит новичков: инпут типа date в Safari на iOS рисуется совсем не так, как в Chrome, и если вёрстка рассчитывала на конкретную высоту поля, форма разъезжается.
Мета-тег viewport и другие причины ложных багов
Иногда баг, который выглядит как проблема конкретного браузера, на деле - забытая или неправильно прописанная строка <meta name="viewport" content="width=device-width, initial-scale=1"> в head. Без неё мобильный браузер отрисовывает страницу в масштабе десктопной версии и потом сжимает картинку целиком, из-за чего текст становится нечитаемым, хотя вёрстка сама по себе рабочая.
Ещё одна ложная причина - кэш браузера или прокси оператора связи. Если правка на сервере уже внесена, а на телефоне всё ещё старая версия страницы, первым делом стоит открыть её в режиме инкогнито или добавить к адресу произвольный параметр вроде ?v=2, прежде чем искать баг там, где его больше нет.
Похожая история с CSS grid: если сетка задана через auto-fit и minmax без явного предела, при узких экранах колонка может схлопнуться и утащить контент за пределы видимой области. Проверяется это только реальным сужением окна браузера, а не чтением кода.
Яндекс.Браузер: турборежим и масштаб текста
Яндекс.Браузер работает на движке Chromium, поэтому в большинстве случаев ведёт себя как обычный Chrome. Разница всплывает в двух местах. Первая - опция увеличения масштаба страницы в настройках браузера, которой часто пользуются люди старше 50 лет: при 125-150 процентах заголовок первого экрана, рассчитанный впритык, начинает переноситься некрасиво или наезжать на кнопку. Вторая - режим экономии трафика, который иногда подменяет шрифты и сжимает изображения, если сайт открывают в зоне слабого сигнала.
Android: разброс экранов и клавиатура над формой
С Android сложнее не браузер, а сама экосистема: сотни моделей с разной шириной экрана, от 360 до 430 пикселей, и с разной высотой из-за вырезов камеры и жестовой навигации. Плюс системная клавиатура на части телефонов перекрывает нижнюю треть экрана, и если кнопка отправки формы стоит близко к последнему полю, пользователь не видит, что нажал.
Список того, что стоит проверить именно на Android:
- виден ли последний элемент формы, когда открыта клавиатура;
- не съезжает ли фиксированная кнопка звонка при появлении клавиатуры;
- читается ли текст без горизонтальной прокрутки на ширине 360 пикселей, это самый частый минимум.
Как проверить кроссбраузерность без парка телефонов?
Держать физически весь набор устройств не нужно. Практичный минимум: свой смартфон на Android, любой айфон у знакомых или коллег хотя бы с одной проверкой раз в квартал, и DevTools в Chrome для эмуляции размеров экрана. Эмуляция размера экрана не заменяет реальный Safari, но ловит грубые переносы и наезды текста.
Для реального Safari без своего айфона выручает BrowserStack (платный, но есть бесплатный пробный период) или удалённая отладка через Xcode, если есть Mac у знакомых. Для разовой проверки перед запуском рекламы этого достаточно, покупать технику под тест не нужно.
Для Android то же самое даёт подключение телефона к компьютеру по USB и вкладка chrome://inspect в десктопном Chrome: видно реальный рендер страницы на реальном устройстве, а не эмуляцию размера экрана.
Ещё один вариант для разовой проверки - попросить клиента прислать пару скриншотов с его собственного телефона на этапе приёмки. Это не заменяет полноценный тест, но ловит грубые случаи, если у вас самих под рукой нет нужной модели.
Чек-лист по устройствам и браузерам
| Устройство | Браузер | Частая ошибка | Как проверить |
|---|---|---|---|
| iPhone | Safari | обрезка блока по 100vh | реальный телефон или BrowserStack |
| Android, разные бренды | Chrome | клавиатура перекрывает форму | свой телефон, ширина 360px |
| Десктоп, возраст 45+ | Яндекс.Браузер | перенос заголовка при масштабе 125% | Ctrl + для увеличения масштаба |
| Планшет | Safari / Chrome | карточки не переносятся, уезжают вбок | DevTools, ширина 768-1024px |
| Старый Android | Chrome старой версии | не поддерживается gap во flexbox | эмуляция плюс проверка на старом устройстве |
Что делать, когда бюджет времени ограничен
Проверять абсолютно все комбинации браузера и устройства нерационально: их сотни, а бюджет разработки лендинга за 15 000 рублей не резиновый. Правило простое: сначала проверяете три сценария с наибольшей долей трафика по вашей нише, а экзотику откладываете, пока не появятся жалобы. Для барбершопа и салона это Android и мобильный Safari, десктоп в этой нише часто даёт меньше 10 процентов визитов.
Полный список технических проверок перед сдачей страницы, включая кроссбраузерность как один из пунктов, собран в статье Как проверить готовый лендинг перед приёмкой. Отдельно про разницу между простой адаптивностью и полноценной мобильной версией написано в статье Адаптивная вёрстка лендинга.
Баг, который вы не нашли сами, найдёт клиент рекламной кампании в первый же день показов, и цена такой находки выше стоимости получаса тестирования.
Частые вопросы
Нужно ли покупать iPhone для тестирования Safari?
Не обязательно. Можно попросить знакомых с айфоном проверить страницу раз в квартал, воспользоваться BrowserStack с бесплатным пробным периодом или удалённой отладкой через Xcode на чужом Mac. Свой айфон нужен только при регулярной разработке многих лендингов.
Почему на телефоне видна старая версия лендинга после правок?
Чаще всего дело в кэше браузера или прокси оператора связи, а не в баге вёрстки. Откройте страницу в режиме инкогнито или добавьте к адресу произвольный параметр вроде ?v=2, прежде чем искать проблему в коде.
Сколько времени занимает проверка кроссбраузерности перед запуском рекламы?
Для трёх основных сценариев - Android, iOS и десктопный Chrome - хватает 30-40 минут: открыть страницу на реальных устройствах или в DevTools и прокликать форму. Экзотические браузеры проверяют только при жалобах.
Как понять, что баг именно в кроссбраузерности, а не в самой вёрстке?
Если страница ломается только в одном браузере, а в остальных выглядит нормально - это кроссбраузерный баг, обычно связанный с flexbox, grid или единицами вроде vh. Если ломается везде одинаково, проблема в разметке или CSS, а не в конкретном движке.
Коротко
Кроссбраузерность лендинга не требует парка устройств и подписки на дорогие сервисы. Достаточно проверить четыре сценария, которые реально дают трафик: Chrome и Яндекс.Браузер на десктопе, Safari на iOS и Chrome на Android с открытой клавиатурой.
Самые частые причины разъезжания вёрстки - flexbox без учёта min-width, единица 100vh в Safari и масштаб страницы в Яндекс.Браузере. Проверка этих трёх вещей перед запуском рекламы закрывает подавляющее большинство реальных жалоб.
