BITSPARK / Статьи / Заказ, договор и приёмка
Кроссбраузерность сайта: что это и как проверить до приёмки
Коротко: кроссбраузерность сайта по русской странице MDN («кросс-браузерное тестирование») - это практика обеспечения уверенности, что сайт работает «в приемлемом количестве браузеров». Список браузеров и устройств, где сайт, по словам страницы, должен работать полностью, MDN советует выбирать по аудитории. Перед приёмкой этот список можно пройти самому: в нескольких браузерах и на телефоне.
Источник определения - учебный курс MDN для веб-разработчиков. Это учебный материал: стандарта или нормативного акта в нём нет, и слово «должен» в статье передаёт текст страницы. Код, запасные варианты для старых браузеров и автоматизация тестов не разбираются; примеры вымышленные: пекарня «Колос» и сайт example.ru. Страница MDN на русском - перевод сообщества; страницы о стратегиях и Baseline читаются в английской версии, русская страница web.dev переведена автоматически. Цитаты с английских страниц даны в нашем переводе и помечены словом «перевод».
Что такое кроссбраузерность сайта?
Коротко: MDN называет проверку «кросс-браузерное тестирование». По определению на русской странице это уверенность, что сайт работает в приемлемом количестве браузеров, на разных устройствах и для людей со вспомогательными технологиями. Сто процентов браузеров в мире страница не требует.
Определение дано на странице Введение в кросс-браузерное тестирование - Изучение веб-разработки | MDN (перевод сообщества, изменена 27 июня 2026):
«Кросс-браузерное тестирование - это практика обеспечения уверенности в том, что веб-сайты и веб-приложения, которые вы создаёте, работают в приемлемом количестве браузеров.»
- MDN, Введение в кросс-браузерное тестирование (перевод сообщества)
Страница называет три группы, о которых нужно думать:
- другие браузеры, в том числе довольно старые, которые не поддерживают современные возможности CSS и JavaScript;
- разные устройства: от новых планшетов, смартфонов и «умных» телевизоров до дешёвых устройств и самых старых смартфонов;
- люди с инвалидностью, которые пользуются вспомогательными технологиями, например скринридерами (программами чтения с экрана), или работают только с клавиатурой.
Допустимые различия страница описывает так:
«Это нормально, если сайт выглядит немного по-разному в разных браузерах, главное он должен обеспечивать полную функциональность.»
- MDN, Введение в кросс-браузерное тестирование (перевод сообщества)
Там же приведён пример:
«В современных браузерах вы можете сделать что-то анимированным или использовать 3D, тогда как в старых браузерах вы можете лишь показать плоскую картинку, предоставляющую ту же информацию.»
- MDN, Введение в кросс-браузерное тестирование (перевод сообщества)
Для сайта пекарни «Колос» на example.ru это могло бы выглядеть так: в новом браузере карточка булки плавно возникает на экране, в старом стоит на месте. Цена, описание и кнопка «Заказать» работают одинаково.
О границах страница пишет прямо:
«Когда мы говорим "приемлемое количество браузеров", мы не говорим, что это должно быть 100% всех браузеров в мире - это почти невозможно.»
- MDN, Введение в кросс-браузерное тестирование (перевод сообщества)
Дальше русская и английская версии страницы расходятся. На русской сказано: «вы должны определить для себя несколько браузеров и устройств, на которых код должен работать полностью». В английской версии (изменена 4 сентября 2026) это место звучит иначе. Перевод: К тому же работа сайта на всех браузерах и устройствах почти невозможна, поэтому веб-разработчику следует договориться с владельцем сайта о круге браузеров и устройств, на которых код будет работать. Источник: Introduction to cross-browser testing - Learn web development | MDN. Это совет учебного курса разработчику. Для заказчика из него следует вопрос: какой список согласован. Его разбирают следующие разделы.
Почему сайт выглядит по-разному в разных браузерах?
Коротко: MDN называет три причины: баги и разная реализация возможностей в браузерах, разная степень поддержки современных технологий и ограничения устройств. Страница также указывает, что ошибки в самом коде нужно исправить до того, как искать проблемы браузеров.
Все три причины приведены на русской странице MDN Введение в кросс-браузерное тестирование, к ним добавлено «а также другие причины».
- Баги и разная реализация возможностей. Страница возвращается к 1990-м: тогда компании-разработчики браузеров умышленно реализовывали возможности по-своему. О нынешнем положении сказано так: «Сейчас же браузеры гораздо жёстче соблюдают стандарты, но различия и баги всё же иногда возникают.»
- Разная степень поддержки современных технологий. Это относится к новейшим функциям, которые браузеры только начинают осваивать, и к очень старым браузерам, которые больше не дорабатываются. Пример страницы: передовые возможности JavaScript могут не работать в старых браузерах.
- Ограничения устройств. Пример страницы: «если сайт был спроектирован для просмотра на десктопных устройствах, он возможно будет выглядеть мелко и трудночитаемо на мобильных устройствах». Второй пример касается тяжёлых анимаций: на производительных планшетах они могут быть хороши, а на менее мощных устройствах, по словам страницы, «может быть вялым или резким».
Для сайта пекарни «Колос» это значило бы: страница с большим числом анимаций открывается на новом планшете плавно, а на дешёвом телефоне движения идут рывками. По описанию MDN это причина из третьего пункта.
Как сайт подстраивается под ширину экрана и как это проверить в браузере, разобрано в статье «Адаптивный сайт: что это и как проверить адаптив до приёмки». Здесь устройство рассматривается как одна из трёх групп из определения.
Как выбрать браузеры, в которых сайт должен работать полностью?
Коротко: страница MDN «Strategies for carrying out testing» исходит из того, что проверить все сочетания браузеров и устройств нельзя, и предлагает делить их по уровню поддержки: A, B и C. Состав списка зависит от аудитории сайта. Уровни на странице даны как пример способа.
Перевод фразы со страницы Strategies for carrying out testing - Learn web development | MDN (изменена 4 мая 2026): Поскольку проверить каждое сочетание браузера и устройства нельзя, достаточно убедиться, что сайт работает на самых важных из них. Деление на уровни страница вводит словами «For example» (по-русски: например). Описания уровней в переводе:
| Уровень | Кого относят (перевод) | Что делают (перевод) |
|---|---|---|
| A-grade | Распространённые и современные браузеры, про которые известно, что они справляются | Тестируют тщательно и обеспечивают полную поддержку |
| B-grade | Более старые и менее способные браузеры, про которые известно, что они не справляются | Тестируют и дают более простой вариант, который открывает полный доступ к основной информации и сервисам |
| C-grade | Редкие и неизвестные браузеры | Не тестируют, но исходят из того, что они справляются. Отдают полный сайт, который должен работать как минимум на запасных вариантах, заложенных в коде |
Страница связывает такой подход с Yahoo (Graded browser Support). Список браузеров из примера страницы здесь не приводится: он составлен для пользователей из Северной Америки и Западной Европы. Страница сама оговаривает, что для аудитории из других мест браузеры и операционные системы могут отличаться от перечисленных.
Источников данных о браузерах аудитории страница называет три: предположения по демографии пользователей, статистику по регионам и аналитику самого сайта. Отдельное замечание страницы касается особых условий. Если продукт нацелен на рынок, где основной способ выхода в интернет - мобильные телефоны, поддержке мобильных браузеров, по словам страницы, скорее всего стоит дать приоритет.
Для пекарни «Колос» это могло бы выглядеть так: заказчик и исполнитель выписывают браузеры и устройства посетителей из отчётов «Браузеры» и «Устройства» Яндекс Метрики, относят каждый к уровню A, B или C и записывают результат.
Где посмотреть, какими браузерами пользуются посетители?
Коротко: у действующего сайта браузеры и их версии показывает отчёт «Браузеры» Яндекс Метрики: Отчеты → Технологии → Браузеры. Для этапа планирования MDN называет и другие источники: данные заказчика, статистику конкурентов и стран, куда обращён сайт.
Справка Яндекс Метрики Отчет «Браузеры» пишет: «Отчет содержит статистику по браузерам и их версиям, которые используют посетители.» Путь к отчёту там же: «Отчеты → Технологии → Браузеры». Страница Технологии добавляет: «Счетчик Яндекс Метрики собирает данные об устройствах и программном обеспечении, которое используют посетители сайта.» Другие отчёты этой группы, названные там: «Устройства», «Разрешения дисплеев», «Операционные системы». Отчёт заполняется данными со счётчика; установка счётчика в статье не описывается.
Владелец действующего сайта пекарни «Колос» открывает отчёт «Браузеры» и выписывает названия браузеров и версий, которые в нём перечислены. Эти названия дают исходные данные для списка из предыдущего раздела.
MDN на странице о стратегиях (Strategies for carrying out testing) называет аналитику значительно более точным источником данных и оговаривает: такая аналитика опирается на уже существующий сайт, поэтому для совсем нового сайта не годится. Там же есть предупреждение о смещении данных, на примере Google Analytics. Если по данным у сайта нет посетителей с Firefox Mobile, это может привести к отказу от поддержки этого браузера. При этом таких посетителей не будет, если сайт в нём был сломан изначально.
Для этапа начального планирования страница Introduction to cross-browser testing называет три источника. Перевод: у клиента могут быть данные из прежних исследований, например с других его сайтов или с прежних версий сайта; если их нет, можно смотреть статистику использования у конкурентов или по странам, которые обслуживает сайт; можно также положиться на интуицию. Рыночные доли браузеров по странам считает Яндекс.Радар: на странице «Как это работает» сказано, что для расчёта он анализирует «сводные данные по счетчикам Яндекс.Метрики». Отчёты по технологиям там доступны для России, Беларуси, Казахстана и Турции. Цифры долей в статье не приводятся.
Что такое Baseline и чего он не сообщает?
Коротко: Baseline - сводка поддержки возможностей веб-платформы браузерами. Он делит функции на широко доступные, недавно доступные и с ограниченной доступностью. Глоссарий MDN перечисляет семь браузеров, на которые он смотрит, и прямо пишет, что Baseline не заменяет проверку доступности, удобства, скорости и безопасности.
Термин описан в двух источниках, и деталями они различаются; каждый назван отдельно.
Глоссарий Baseline (compatibility) - Glossary | MDN (изменён 27 августа 2026): Baseline показывает доступность функций веб-платформы, среди них API, свойства CSS и синтаксис JavaScript. Он делит функции на широко доступные, недавно доступные и с ограниченной доступностью. Браузеров семь:
- Apple Safari (iOS);
- Apple Safari (macOS);
- Google Chrome (Android);
- Google Chrome (desktop);
- Microsoft Edge (desktop);
- Mozilla Firefox (Android);
- Mozilla Firefox (desktop).
Страница Baseline | web.dev (русская версия Базовый уровень | web.dev переведена автоматически) называет набор из четырёх браузеров: Chrome (компьютер и Android), Edge, Firefox (компьютер и Android), Safari (macOS и iOS). Там же сказано, что Baseline разработала команда Chrome, а сейчас его определяет группа сообщества WebDX.
Статусы описаны по-разному. Таблица сделана из переводов с двух страниц:
| Статус | MDN, глоссарий (перевод) | web.dev (перевод) |
|---|---|---|
| Широко доступна (widely available) | Стабильная история поддержки в каждом из браузеров Baseline не менее 2,5 лет («at least 2.5 years») | Прошло 30 месяцев с даты, когда функция стала новой и совместимой между браузерами |
| Недавно доступна (newly available) | Работает как минимум в последней стабильной версии каждого браузера Baseline, но может не работать в старых браузерах и на старых устройствах | Поддерживается всеми основными браузерами и поэтому совместима |
| Ограниченная доступность (limited availability) | Ещё нет во всех браузерах | Функция ещё не поддерживается всеми браузерами; такой она бывает до статуса «newly available» |
В таблице срок дан словами каждого источника: у MDN отсчёт идёт по истории поддержки в браузерах Baseline, у web.dev - от даты, когда функция стала новой.
О границах Baseline глоссарий MDN пишет так. Перевод: Baseline - это сводка поддержки браузерами. Она не заменяет проверку доступности, удобства использования, производительности, безопасности и другие виды проверки. Baseline может не показать, работает ли функция: на старых устройствах и версиях браузеров; в браузерах, не охваченных определением Baseline, например в веб-представлениях операционной системы; во вспомогательных технологиях, таких как программы чтения с экрана.
Яндекс Браузер в списках MDN и web.dev не назван. Что Baseline сообщает о нём, на этих страницах не сказано. Если подрядчик ссылается на Baseline, у заказчика есть конкретный вопрос: какие браузеры и версии из согласованного списка проверены отдельно.
Как проверить кроссбраузерность сайта самому перед приёмкой?
Коротко: MDN описывает проверку для разработчика. Заказчик может пройти ту её часть, где код не нужен: записать критерии, открыть сайт в нескольких браузерах и на телефоне, пройти сценарии мышью, клавиатурой и касанием, а найденное передать подрядчику с названием браузера, версией и устройством.
Порядок ниже собран из страниц MDN Introduction to cross-browser testing и Strategies for carrying out testing. Пересказы приведены в нашем переводе.
- Запишите критерии до проверки. Страница о стратегиях советует перед началом проверки составить список требований, которые должны выполняться, чтобы функцию приняли; они бывают визуальными и функциональными. Пример со страницы: кнопка включается основным способом управления, будь то мышь, клавиатура или касание, текст читается. Для пекарни «Колос» критерии могли бы звучать так: кнопка «Заказать» нажимается мышью, клавиатурой и касанием; форма заказа отправляется; текст читается.
- Откройте сайт в нескольких браузерах. Страница Introduction советует проверить в паре стабильных браузеров на своей системе и называет для примера Firefox, Safari, Chrome и Edge. Список определяется аудиторией сайта.
- Проверьте доступность. MDN включает в проверку попытку пользоваться сайтом только с клавиатуры или через скринридер, чтобы увидеть, можно ли по сайту перемещаться.
- Откройте сайт на телефоне. Страница Introduction называет мобильную платформу, например Android или iOS. Режим устройства в Chrome и проверку ширины экрана разбирает статья об адаптивном сайте.
- Пройдите браузеры из согласованного списка. Способы перечислены в таблице ниже.
- Используйте чистый профиль браузера. Страница о стратегиях советует по возможности завести отдельный профиль браузера с отключёнными расширениями и проверять в приватном режиме: так в браузере нет ничего, что могло бы повлиять на результат, а файлы cookie и временные файлы не сохраняются.
Способы проверки по страницам MDN (перевод и пересказ):
| Способ | Как описан на страницах MDN |
|---|---|
| Реальные устройства | Устройство с нужным браузером даёт наибольшую точность в поведении и общем впечатлении; страница советует проверять на реальных устройствах там, где это возможно |
| Эмуляторы | Программы на компьютере, которые имитируют устройство или его условия и позволяют проверять удобнее, чем подбирать нужное сочетание оборудования и программ |
| Виртуальные машины | Приложения, которые запускают имитацию целых операционных систем, каждая в своём виртуальном диске |
| Группа пользователей | Люди вне команды разработки: друзья, коллеги, добровольцы. Им дают набор шагов (сценарий) и просят сообщить результаты; страница описывает проверку на тестовом сервере, чтобы не выпускать сайт до готовности |
MDN упоминает также автоматизацию и коммерческие сервисы проверки. В статье они не разбираются и не сравниваются, цены не приводятся.
Разработчику страница Introduction советует выяснить у сообщившего о проблеме платформу, устройство и версию браузера. Заказчик может указать эти три пункта сразу, в самом замечании.
Что обсудить с подрядчиком до начала работы?
Коротко: английская версия страницы MDN советует разработчику договориться с владельцем сайта о круге браузеров и устройств. Заказчик может задать пять вопросов до подписания договора и записать ответы вместе с условиями приёмки. О нормах ГК РФ про приёмку работы сказано в статье о договоре.
Вопросы построены по страницам, которые разобраны выше:
- Для каких браузеров и устройств сайт должен работать полностью (уровень A в терминах MDN), а для каких допустим более простой вариант (уровень B)?
- Какие возможности в старых браузерах заменят упрощёнными? Пример MDN: в современных браузерах анимация или 3D, в старых плоская картинка с той же информацией.
- Где проверяют: на реальных устройствах или в эмуляторах?
- По какому списку проверок сайт будет приниматься? Такой список страница о стратегиях советует составить заранее.
- Если упоминается Baseline: какие браузеры и версии проверены отдельно?
Для сайта с трёхмерной графикой MDN даёт пример: если владелец интернет-магазина хочет 3D-тур по каждому товару на WebGL, ему придётся принять, что это не заработает во всех устаревших версиях браузеров (перевод со страницы Introduction to cross-browser testing). На главной странице BITSPARK среди услуг названа «Интерактивный сайт»: «Индивидуальная оценка - WebGL, motion и нестандартные интерфейсы.»
Шаг процесса «Запуск» описан там так: «Проверяем desktop и mobile, скорость, формы и ключевые сценарии - затем запускаем.» Скорость и формы в этой статье не разбираются.
В статье «Договор на разработку сайта: что говорит ГК и что проверить до подписи» разобрано, что сказано в ст.720 ГК РФ о приёмке работы. Среди примеров того, что стоит описать в договоре, она называет «на каких устройствах сайт должен открываться». Список браузеров и устройств из этой статьи можно использовать для такого описания. Нормы ГК здесь не пересказываются.
Источники
Страницы открыты 05.10.2026.
- Введение в кросс-браузерное тестирование - Изучение веб-разработки | MDN - определение, причины различий (перевод сообщества, изменена 27 июня 2026).
- Introduction to cross-browser testing - Learn web development | MDN - английская версия: согласование круга браузеров, источники данных об аудитории, порядок проверки (изменена 4 сентября 2026).
- Strategies for carrying out testing - Learn web development | MDN - выбор браузеров, уровни A, B, C, критерии проверки, способы проверки (изменена 4 мая 2026, английская страница).
- Baseline (compatibility) - Glossary | MDN - семь браузеров, статусы, границы Baseline (изменён 27 августа 2026, английская страница).
- Baseline | web.dev и Базовый уровень | web.dev - кто определяет Baseline, этапы, 30 месяцев (русская версия переведена автоматически).
- Отчет «Браузеры» - справка Яндекс Метрики, путь к отчёту.
- Технологии - справка Яндекс Метрики, отчёты группы.
- Как это работает - Яндекс.Радар - основа расчёта долей браузеров.
- BITSPARK - Digital studio - услуга «Интерактивный сайт» и шаг «Запуск» (главная студии).
- Адаптивный сайт: что это и как проверить адаптив до приёмки - BITSPARK - статья раздела.
- Договор на разработку сайта: что говорит ГК и что проверить до подписи - BITSPARK - статья раздела.
Обсудить проект в Telegram: t.me/billioniks