Кроссбраузерность сайта: что это такое и почему это важно

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

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

Что означает кроссбраузерность на практике

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

Разложу это на уровни, потому что при приёмке работ полезно проверять их по очереди, а не смотреть на страницу целиком.

• Контент читается. Текст не наезжает сам на себя, не уходит под соседний блок, не обрезается по правому краю, страница не прокручивается вбок.
• Навигация работает. Меню раскрывается, вложенные пункты доступны, хлебные крошки кликабельны, кнопка «наверх» не перекрывает ссылки.
• Интерактив отвечает. Слайдеры листаются, вкладки переключаются, аккордеон раскрывается, фильтры каталога применяются.
• Формы отправляются. Поля принимают ввод, маска телефона не мешает, кнопка активна, после отправки виден понятный ответ — успех или ошибка.
• Оформление узнаваемо. Отступы, цвета и иерархия сохраняются настолько, что страница выглядит законченной, а не «поехавшей».

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

Три движка вместо десятка браузеров

Тестировать «все браузеры» невозможно и не нужно. Отображение задаёт не название программы, а движок рендеринга, а их в живом обиходе три. Как только это укладывается в голове, задача из необъятной становится обозримой.

Движок	Какие браузеры на нём	Где встречается	Что проверять в первую очередь
Blink	Chrome, Edge, Opera, Яндекс Браузер	Windows, Android, macOS	Базовое поведение: это де-факто эталон, на нём верстают
WebKit	Safari, а также любой браузер на iPhone и iPad	iOS, iPadOS, macOS	Формы, высота экрана, фиксированные элементы, видео
Gecko	Firefox	Windows, Linux, Android, macOS	Свежие свойства CSS, скроллбары, печать страницы
Встроенные вебвью	Просмотр ссылок внутри мессенджеров и соцсетей	Приложения на телефоне	Открытие ссылок, скачивание файлов, оплата, работа скриптов аналитики

Отдельно про iPhone, потому что это самое частое недопонимание. Установленный на iPhone Chrome или Яндекс Браузер — это оболочка вокруг того же самого системного WebKit. Проверив сайт «в Chrome на айфоне», вы проверили Safari, а вовсе не Chrome. И наоборот: то, что работает в Chrome на Android, ничего не говорит о поведении на iPhone.

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

Подробнее об этом — в статье «Адаптивность сайта: почему это важно и как повысить ее уровень».

Почему вёрстка расходится в разных браузерах

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

Симптом	Частая причина	Чем проверить
Страница прокручивается вбок на телефоне	Жёсткая ширина в пикселях у блока или картинки	Сузить окно браузера до 360 px и найти вылезающий элемент
Блоки схлопнулись в одну колонку кашей	Свойство раскладки не поддержано, запасного варианта нет	Сверить свойство по caniuse с версией браузера посетителя
Слайдер или фильтр не реагирует на клики	Ошибка JavaScript, оборвавшая выполнение всего файла	Консоль разработчика: одна красная строка объясняет всё
Кнопка отправки нажимается, но заявка не уходит	Скрипт формы использует метод, недоступный в этом движке	Отправить тестовую заявку с реального iPhone и проверить почту
Часть экрана закрыта пустотой снизу	Высота задана в единицах экрана без учёта адресной строки	Открыть на телефоне и прокрутить: пустота «дышит»
Текст наезжает на соседний текст	Шрифт не загрузился, подставился системный с другой шириной	Отключить загрузку шрифтов и посмотреть, что останется
Разные браузеры показывают разную структуру	Незакрытые теги: каждый движок чинит разметку по-своему	Валидатор разметки W3C

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

Из чего складывается продвижение сайта и как оно работает:

14:31

Что теряет бизнес и что видит поиск

Оценить ущерб можно за пятнадцать минут и без разработчика, если у вас стоит Яндекс Метрика. Логика такая: сравнить не посещаемость, а конверсию в разрезе технологий. Посещаемость по браузерам вам ничего не скажет, а вот разрыв в доле достижений цели скажет всё.

1. Откройте отчёт по браузерам и запишите доли: обычно на первые четыре браузера приходится больше девяноста процентов визитов.
2. Наложите на отчёт цель — отправку формы или звонок.
3. Сравните конверсию по каждому браузеру со средней по сайту.
4. Повторите то же самое в разрезе «десктоп / телефон», а затем по операционным системам.
5. Если по одному браузеру или по iOS конверсия заметно ниже при сопоставимом трафике — это не совпадение, а адрес поломки.

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

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

Тему разбирал отдельно: «Оптимизация сайта для мобильных устройств: почему это важно и как правильно ее выполнить».

Как проверить сайт самому: порядок шагов

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

1. Составьте матрицу. Возьмите из Метрики четыре-пять самых частых сочетаний «браузер + устройство». Это ваш список, а не абстрактный «весь интернет».
2. Выпишите пять сценариев. Например: найти услугу через меню, открыть карточку, отправить заявку, позвонить по клику на телефон, найти адрес на карте.
3. Пройдите каждый сценарий до конца. Именно до конца: не «форма выглядит нормально», а «заявка пришла на почту».
4. Проверьте на реальном iPhone. Не в эмуляторе. Это единственный движок, который эмулируется хуже всего.
5. Откройте ссылку из мессенджера. Встроенное окно приложения — отдельная среда со своими сюрпризами.
6. Посмотрите консоль. В настольном браузере откройте инструменты разработчика и загляните во вкладку с ошибками. Красные строки — готовый список задач.
7. Проверьте разметку валидатором. Ошибки вложенности лечатся дёшево и убирают сразу несколько симптомов.
8. Зафиксируйте дефекты таблицей. Что сделал, что ожидал, что получил, на каком устройстве, скриншот. Без этого исправление превращается в переписку без конца.

Чем проверять: инструменты и их границы

У каждого способа проверки своя зона достоверности, и подмена одного другим — источник ложного спокойствия. Особенно это касается режима эмуляции устройств в браузере: он меняет размер окна, но не меняет движок.

Инструмент	Что действительно проверяет	Чего не покажет
Реальные телефон и планшет	Всё: движок, касания, клавиатуру, вебвью	Ограничен теми устройствами, что есть под рукой
Режим устройств в инструментах разработчика	Поведение раскладки при разной ширине экрана	Особенности чужого движка: Safari в Chrome не появится
Онлайн-фермы устройств	Редкие связки версий и систем	Скорость реальной сети и капризы конкретной прошивки
Валидатор разметки W3C	Ошибки вложенности и незакрытые теги	Логические дефекты вёрстки и падения скриптов
Справочник поддержки свойств caniuse	Есть ли свойство в нужной версии движка	Как именно оно себя поведёт на вашей странице
Метрика и Вебвизор	Где теряются живые посетители	Техническую причину — только адрес поломки

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

Как чинить: прогрессивное улучшение вместо погони за версиями

Правильная стратегия не в том, чтобы поддержать каждый браузер отдельным набором костылей. Она в том, чтобы базовая версия страницы работала на минимальных средствах, а всё красивое добавлялось сверху и отваливалось безопасно.

• Смысловая разметка как фундамент. Заголовки, списки, ссылки и настоящие теги форм работают везде и без единой строки скриптов. Кнопка, сделанная из блока с обработчиком клика, ломается в разы чаще настоящей кнопки.
• Проверка поддержки в самом CSS. Правило, которое применяет современный приём только там, где он поддержан, избавляет от угадывания версий: остальные получают простой запасной вариант.
• Гибкие размеры вместо фиксированных. Проценты, минимальные и максимальные значения, ограничение ширины картинок по контейнеру. Жёсткая ширина в пикселях — причина горизонтальной прокрутки в девяти случаях из десяти.
• Автоматическая простановка префиксов и сборка кода. Это работа инструментов сборки, а не человека: руками поддерживать актуальность префиксов невозможно.
• Обработка ошибок в скриптах. Одна невыловленная ошибка обрывает выполнение всего файла, и вместе со слайдером умирает форма, лежащая в том же файле ниже. Разнесение критичного и декоративного кода по разным файлам — дешёвая страховка.
• Никаких полифилов «на всякий случай». Каждый подключённый набор заплаток — это лишний код, который тоже может сломаться. Подключается только то, что закрывает измеренную проблему.
• Нормализация стилей в начале. Браузеры имеют разные значения по умолчанию для отступов и элементов форм; единый сброс убирает половину мелких расхождений сразу.

Мобильный Safari: место, где ломается чаще всего

Если нужна помощь по теме — мой курс по SEO.

Этому движку стоит выделить отдельный раздел, потому что доля iPhone среди платёжеспособной аудитории выше средней, а поведение WebKit отличается заметнее всего. Перечислю дефекты, которые вижу в аудитах регулярно.

• Экран «дышит» при прокрутке. Высота, заданная в единицах видимой области, на iPhone считается вместе со скрывающейся адресной строкой. Первый экран то обрезается, то оставляет пустую полосу.
• Страница увеличивается при нажатии на поле. Если размер шрифта в поле меньше шестнадцати пикселей, Safari принудительно приближает страницу. Посетитель попадает в увеличенный макет и часто не понимает, как вернуться.
• Клавиатура закрывает кнопку отправки. Особенно на длинных формах с закреплённым нижним блоком. Человек заполнил поля и не видит, чем это подтвердить.
• Тип поля выбран неверно. Телефон, почта и число должны открывать соответствующую клавиатуру. Иначе номер набирается на буквенной раскладке, и это прямая потеря заявок.
• Маска ввода конфликтует с автозаполнением. Скрипт маски вставляет символы, автозаполнение подставляет свой формат, поле оказывается заполнено мусором, а проверка не пропускает отправку.
• Закреплённые панели перекрывают контент. Плавающая кнопка звонка внизу и виджет чата рядом с ней закрывают последнюю строку формы или ссылку на политику обработки данных, без согласия с которой заявка не отправится.
• Наведение вместо нажатия. Выпадающее меню, раскрывающееся по наведению курсора, на сенсорном экране требует двух касаний, и первое из них часто засчитывается как переход по родительской ссылке.

Кроссбраузерность в задании и при приёмке работ

Формулировка «сайт должен корректно отображаться во всех браузерах» юридически и практически пуста: под «корректно» каждая сторона понимает своё. Требование становится рабочим, когда в нём есть перечень сред, перечень сценариев и критерий готовности.

Смежный материал по теме — «Индексация сайта: что это такое и как она работает».

Пункт задания	Как сформулировать	Как проверить при приёмке
Матрица поддержки	Перечислить браузеры и системы с указанием актуальных версий и одной предыдущей	Пройти сценарии на каждой позиции списка
Критерий соответствия	Функциональная эквивалентность, а не совпадение до пикселя	Разделить замечания на «не работает» и «выглядит иначе»
Список сценариев	Пять-семь пользовательских путей, включая отправку заявки	Довести каждый путь до результата, а не до вида страницы
Валидность разметки	Отсутствие ошибок вложенности на шаблонных страницах	Прогнать по одному представителю каждого типа страниц
Чистая консоль	Отсутствие ошибок выполнения скриптов на всех типах страниц	Открыть инструменты разработчика и посмотреть вкладку ошибок
Срок на исправление	Отдельный срок для дефектов, найденных после сдачи	Зафиксировать в договоре гарантийный период

Ещё один пункт, который стоит убрать из старых шаблонов заданий, — требование поддержки Internet Explorer. Браузер снят с поддержки, его доля в отчётах статистики близка к нулю, а совместимость с ним заставляет отказываться от современных приёмов вёрстки в пользу громоздких обходных решений. Если в вашем задании эта строка ещё есть, она стоит вам денег и не приносит ни одного посетителя.

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

Нужно ли, чтобы сайт выглядел одинаково везде? Нет, и такой цели не ставят. Шрифты, элементы форм и скроллбары рисуются по-разному по определению. Требование — одинаковый набор возможностей и сохранение читаемости, а не совпадение картинок.

У меня сайт на конструкторе, это моя забота? Отчасти. Базовые шаблоны конструкторов проверяются разработчиками платформы, и с ними обычно всё в порядке. Проблемы приходят с тем, что добавили сверху: сторонние виджеты, вставленные блоки кода, чужие скрипты чатов и калькуляторов. Проверять всё равно нужно, просто список подозреваемых короче.

Как часто перепроверять? Раз в квартал по короткому сценарию и обязательно после каждого изменения шаблона, обновления системы управления сайтом или подключения нового виджета. Больше всего поломок приходит не из воздуха, а сразу после чужой правки.

Разработчик говорит, что у него всё работает. Что ответить? Попросить пройти конкретный сценарий на конкретном устройстве из вашей матрицы и приложить видеозапись экрана. «У меня работает» — это утверждение о его ноутбуке, а не о вашем сайте. Запись Вебвизора с реальным посетителем закрывает такой спор за минуту.

Сколько стоит починка? Зависит от природы дефекта. Горизонтальная прокрутка, размер шрифта в полях, неверный тип поля ввода — это правки на десятки минут. Слайдер или калькулятор, написанный под один движок, иногда дешевле заменить готовым решением, чем чинить. Начинать имеет смысл с дефектов на пути к заявке — они окупаются первыми.

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

Коротко

• Кроссбраузерность — это одинаковый набор возможностей у посетителя с любым распространённым браузером, а не совпадение страницы до пикселя.
• Проверять надо три движка — Blink, WebKit, Gecko — плюс встроенное окно мессенджера, а не полтора десятка названий браузеров.
• Любой браузер на iPhone работает на WebKit, поэтому проверка «в Chrome на айфоне» проверяет Safari и ничего больше.
• Масштаб потерь считается по конверсии в разрезе браузеров и устройств в Метрике, а причину показывают Вебвизор и консоль ошибок.
• Лечение строится на прогрессивном улучшении: смысловая разметка и гибкие размеры как основа, современные приёмы сверху с запасным вариантом.
• В задании подрядчику нужны матрица поддержки, список сценариев и критерий функциональной эквивалентности, иначе требование непроверяемо.

Если на сайте есть подозрение, что часть аудитории не доходит до заявки, а причина неочевидна, приходите на SEO-консультацию: посмотрим статистику по браузерам и устройствам вместе, найдём места, где теряются посетители, и я назову порядок исправлений от самых окупаемых к остальным.