Иван Погоренко

Выкатили новую фичу, а потом бэкендер со своим Firefox пишет, что у него что-то не работает? Или пользователь с Safari жалуется на неудобства? Ничего страшного: поищу причину в интернете, починю баг и продолжу использовать для разработки Chrome. В этой статье рассмотрим, почему проблемы кроссбраузерности никуда не пропали в 2026 году, и попробуем понять, как заранее определять появление ошибок. Статистика Много лет Chrome лидирует среди всего многообразия браузеров, второе место стабильно занимает Safari, а оставшуюся долю около 15% делят между собой другие браузеры. Статистика использования браузеров за последние 5 лет: Браузер20252024202320222021Chrome68,86%65,82%63,87%64,78%64,45%Safari15,96%18,22%19,78%18,93%18,9%Edge5%5,16%5,03%4,18%3,59%Firefox2,38%2,79%2,95%3,38%3,62%Samsung Internet2,04%2,49%2,48%2,83%3,11%Opera1,93%2,3%2,74%2,23%2,24% Прежде чем махнуть рукой на 2% Firefox, вспомните, что это все еще десятки миллионов пользователей. А если ваш продукт ориентирован на IT-специалистов, доля Firefox в вашей аналитике может быть значительно выше средней. Поэтому выбор браузеров для разработки и тестирования должен определяться в первую очередь не их популярностью или вашими личными привычками, а глубокой аналитикой продукта, которую можно получить, например, из PostHog. Такой подход, конечно, не решит проблему кроссбраузерности полностью, но поможет снизить количество случаев, когда разработчик говорит, что все работает корректно, а пользователь жалуется на съехавшую верстку. Три движка Движки браузеров на десктопе можно разделить на три группы: Chromium-совместимые браузеры, Safari на движке Webkit и Firefox (а также его форки) с Gecko. Отдельные движки могут по-разному интерпретировать HTML, CSS и JavaScript, из-за чего у пользователей, использующих браузер, отличный от того, которым пользуется сам разработчик, могут возникать технические или визуальные ошибки. Chromium Chromium — самый распространенный движок: на нем работают Edge, Samsung Internet, Opera, Brave, сам Google Chrome и еще множество менее известных браузеров. При этом сам по себе Chromium тоже является браузером, который представляет собой «стерильную» версию Chrome без лишних функций. Chromium и Google Chrome вышли одновременно и изначально имели идентичный код. Сегодня же Chrome имеет расширенный функционал и интеграции с сервисами Google, тогда как Chromium остался базовой платформой, на основе которой сторонние разработчики создают собственный интерфейс, уникальные инструменты и функции. Chromium состоит из трех основных частей: движка рендеринга Blink, движка JavaScript V8 и самого UI браузера — той части, которую каждый вендор разрабатывает и кастомизирует под себя. Chromium-совместимые браузеры могут незначительно отличаться версией движка и отставать друг от друга, поддерживать или не поддерживать экспериментальные фичи (не просто так существует сервис Can I use). Обвязка и особенности поведения браузеров разных вендоров могут создавать незначительные баги (в layout, автозаполнении или работе с паролями), но в целом все Chromium-браузеры ведут себя одинаково. Благодаря этому в разработке и тестировании можно ориентироваться только на Chrome и радоваться жизни. WebKit Safari на движке WebKit — единственный браузер от Apple. Движок развивается одной компанией, которая полностью определяет приоритеты его разработки. Webkit состоит из двух частей: сам WebKit — движок рендеринга, и JavaScriptCore (Nitro) — движок JavaScript. Множество ошибок во фронтенде связано именно с Safari — и возникают они из-за того, что это (удивительно!) другой движок. Blink отделился от WebKit в 2013 году, так что корни у них общие, однако за 13 лет они значительно разошлись. Gecko Firefox и его форки (LibreWolf, Waterfox, Tor Browser) используют собственный движок компании Mozilla (наследницы легендарного Netscape, чей открытый код стал фундаментом для Gecko и всего современного семейства Firefox). Все эти браузеры используют движок рендеринга Gecko (с компонентом Stylo для CSS, WebRender для растеризации) и движок JavaScript SpiderMonkey. Mozilla — некоммерческая организация с ограниченными ресурсами. Это единственный крупный независимый движок, не принадлежащий технологическому гиганту. Одинаковый движок — разное поведение Как бы ужасно это не звучало, но даже использование одного и того же браузера не гарантирует отсутствие проблем с совместимостью. Давайте рассмотрим этот вопрос на примере Chromium, который каждый месяц выпускает новую стабильную версию. С каждым таким обновлением появляются новые CSS-возможности, Web API и исправления браузерных багов. Из-за этого даже две одинаковых версии одного браузера могут вести себя по-разному. Недавно я как раз столкнулся с похожей ситуацией: передал задачу в тестирование, а она вернулась с багом — съехало отображение поясняющего popup. Наши лица в тот момент. Источник. Как оказалось, причина была не в неисправном коде: у тестировщика была старая версия Chromium, в результате чего модуль Layout в старой версии Blink неправильно позиционировал popup. Десктопные ОС Один и тот же браузер может выдавать разные ошибки в зависимости от операционной системы пользователя. На это есть несколько причин. Рендеринг текста Системы macOS, Linux и Windows по-разному отображают текст, так как используют разные технологии сглаживания, хинтинга и субпиксельного рендеринга: Core Text, FreeType и DirectWrite соответственно. Отсюда появляются визуальные дефекты: разная толщина шрифтов, обрезание строк или их смещение в процессе загрузки. Рендеринг текста в Firefox MacOs. Рендеринг текста в Firefox Ubuntu. Рендеринг текста в Firefox Windows. Скроллбары В Windows используются стандартные скроллбары, занимающие место на странице. В то же время в macOS используются overlay-скроллбары, которые отрисовываются поверх контента и не влияют на ширину блоков. Из-за этого в браузерах со стандартной прокруткой может сдвигаться весь интерфейс или неожиданно появляться горизонтальный скролл. Скроллбары в Chrome MacOS. Скроллбары в Chrome Ubuntu. Скроллбары в Chrome Windows. HiDPI и масштабирование На HiDPI-экранах (Retina и аналоги) браузеры работают через коэффициент device pixel ratio (DPR), который связывает CSS-пиксели с физическими пикселями. При DPR > 1 один CSS-пиксель соответствует нескольким физическим, и это повышает четкость, но усложняет рендеринг. В Windows используется дробное масштабирование, в macOS — кратное, а в Linux поведение зависит от окружения и настроек. Это влияет на всю графику: тонкие линии могут выглядеть размытыми или разной толщины, тени и градиенты — иметь разную мягкость, а элементы — смещаться на доли пикселя. Canvas особенно чувствителен к DPR: если не учитывать масштабирование вручную, он будет выглядеть «мыльным» на экранах Retina. При этом даже при правильной настройке результат может отличаться между ОС из-за различий в сглаживании и GPU. С изображениями та же ситуация: браузеры по-разному применяют downscaling и interpolation, поэтому одна и та же картинка может выглядеть либо более резкой, либо более размытой. Особенности мобильных устройств На мобильных устройствах часто встречаются специфичные баги. Иногда они связаны просто с плохой адаптацией веб-приложения к мобильным версиям, но есть и специфика именно мобильных браузеров: о ней у моей коллеги есть замечательная статья, в которой можно почитать подробнее об особенностях веба на мобильных устройствах. WebView WebView — это браузер внутри нативного приложения, браузерный движок без UI-обвязки. Вы сталкиваетесь с ним в банковских приложениях, мессенджерах и соцсетях, когда переходите по какой-либо ссылке и открывается не системное окно браузера, а просмотр веба в этом приложении. На разных платформах используют разный WebView: Android System WebView — системный компонент на базе Chromium. Он обновляется автоматически через Google Play, поэтому его версия может отличаться от версии Chrome на этом же устройстве. WKWebView на базе WebKit для iOS, который работает в отдельном процессе и имеет ограничения в API (например, недоступность Service Worker, потеря сессионных данных из-за ограничений памяти и тому подобное). Десктопные решения. В качестве WebView на ПК часто используют Electron (Chromium + Node.js) — на нем работают Discord, Visual Studio Code и Figma. Другой популярный вариант — встраиваемый Chromium для нативных приложений CEF (Chromium Embedded Framework), на котором построены Telegram Mini Apps для Windows и Linux. Кроссбраузерность в WebView упирается в то, как именно хост-приложение сконфигурировало этот компонент. Разрешена ли геолокация, как обрабатываются редиректы и межсайтовые запросы — все это может кардинально изменить поведение одного и того же приложения. Ваш код может идеально работать в WebView банковского приложения, но ломаться в мессенджере из-за жесткой CSP или отсутствия нужных разрешений. Поэтому тестировать приходится не просто на версиях ОС, а на реальных сценариях открытия внутри ваших целевых приложений: Telegram, VK, Discord и других. К тому же, если говорить о телефонах, то важно минимизировать шанс разного поведения в зависимости от ОС или ее версии. Откуда берутся различия Отличия в браузерах разных вендоров начинаются уже с интерпретации спецификаций — начиная с 2016 IT-сообщество активно стандартизирует веб-технологии. Но в спецификациях указывается лишь ожидаемое поведение, а вопрос конечной реализации стоит за вендором. Это, пожалуй, основная причина различий в поведении браузеров. Каждый движок использует собственные алгоритмы рендеринга и оптимизации. Они могут по-разному рассчитывать размеры элементов, округлять значения и обрабатывать события. Поэтому соблюдение требований не всегда гарантирует одинаковый результат. Кроме того, реализация определенных фич в браузерах может откладываться годами из-за внутренней политики компаний. Например, Apple гораздо позже внедрила полноценные API для доступа в файловую систему, пуш-уведомлений и PWA, поскольку эти API позволяют fingerprinting (сбор уникальных характеристик устройства)или дают слишком много доступа к устройству. Моя коллега тоже сталкивалась с подобной проблемой при использовании CSS-свойства ime-mode, которое управляло вводом иероглифов и специфических символов. Дело в том, что данное свойство долго поддерживалось только Firefox и IE, в то время как Chrome и Safari отказались от него. И поскольку Firefox не вывел ни одного предупреждения в консоль о том, что это свойство устарело, она узнала об этом от коллег-бэкендеров. Доступность поздно поддерживаемых API в разных браузерах на примере File System Access API. Стандартизируем внедрение стандартов Инициативы по внедрению фич Interpop и Baseline от web.dev определяют приоритетные направления внедрения стандартов и классифицируют функции как новые или базово доступные. Если раньше браузеры могли годами внедрять одни и те же возможности независимо друг от друга, то теперь крупные вендоры вместе решают проблемы совместимости. Конечно, это не означает, что проблемы кроссбраузерности исчезли. Baseline не гарантирует отсутствие браузерных багов или полностью одинаковое поведение, но позволяет гораздо увереннее использовать современные возможности платформы, чем несколько лет назад. Актуальные проблемы и где о них узнать Проанализировать боли разработчиков помогают ежегодные опросы State of CSS, State of JS, State of HTML и другие подобные. А еще в процессе написания мне попалась занимательная статья про целых 50 багов кроссбраузерности от разработчика, пытавшегося написать игру на HTML5. Рассмотрим некоторые проблемы, которые стали болью разработки в 2025 году: Полноэкранный режим в Safari на iPhone API requestFullscreen официально поддерживается всеми браузерами, но в Safari для iOS на смартфонах он отсутствует. Вероятно, это может быть связано с политикой Apple, стремящейся ограничить конкуренцию веб-игр с нативными приложениями из App Store. Полноэкранный режим в Safari на iPad На планшетах этот режим работает, но в новых версиях iPadOS экранная клавиатура отказывается работать в полноэкранном режиме и просто выходит из него, а в более поздних — выдает всплывающее окно с предупреждением о фишинге. Проблема возникает из-за того, что Apple добавила защитный механизм против фишинговых атак через поддельные клавиатуры. Сделано это, чтобы избежать уязвимости, когда мошенник мог перевести сайт в полноэкранный режим и показать поддельное окно входа, имитирующее внешний вид страницы банка или другого сервиса. Разная реализация клика в Chrome и Safari На iOS событие клика (click) не срабатывает на неинтерактивных элементах (например, или ), пока вы явно не добавите им интерактивные свойства: стиль cursor: pointer или атрибут onclick. Отличия в реализации метода .play() для тега audio Метод .play() у HTMLAudioElement помечен как полностью поддерживаемый, но на IOS он все же работает с некоторыми ограничениями. Проблема заключается в том, что чтобы воспроизвести аудиофайл, его нужно вызвать непосредственно внутри обработчика касания. Это ломает отложенное или фоновое воспроизведение звуков. Firefox игнорирует сенсорную полоску на новых IOS устройствах Начиная с модели iPhone X, Apple использует сенсорную полосу внизу экрана вместо физической кнопки «Домой». Safari рисует страницу с заранее заложенным отступом под эту полоску, в то время как, например, Firefox для IOS просто обрезает нижнюю часть интерфейса, потому что в нем заранее не заложены данные отступы. position: sticky для заголовка таблицы Стиль position: sticky долгое время не работал для заголовка таблицы, его приходилось задавать для каждого по-отдельности. Теперь же это считается стандартной практикой, но дело в том, что браузеры по-разному могут обрабатывать дробные пиксели. Chrome может округлить позицию sticky-элемента не в ту сторону, из-за чего между ним и границей родительского контейнера образуется артефакт в 1 пиксель. Внешний вид заголовка таблицы со стилем position: sticky после скролла в Firefox. Внешний вид заголовка таблицы со стилем position: sticky после скролла в Chromium. Закономерно возникает вопрос — а что же делать? Решить проблему можно, заменив свойство border на outline, так как оно не влияет на размеры и положение элемента в потоке, что позволяет обойти проблему с округлением. backdrop-filter + preserve-3d Важно понимать, что backdrop-filter работает не с самим элементом, а с содержимым, расположенным позади него, поэтому браузеру необходимо сначала понять положение и порядок отрисовки объектов в 3D пространстве, и только потом он сможет определить область для применения фильтра. В сочетании с preserve-3D процесс определения фонового содержимого усложняется, так как дочерние элементы сохраняют общую 3D структуру, а не преобразуются в плоский слой. В Chromium такая комбинация обрабатывается корректно и фильтр применяется к фону. В то же время в Firefox при определенных сценариях, например при пересечении элементов, фильтр не применяется, хотя оба свойства работают ожидаемо по-отдельности. Данная проблема даже зарегистрирована в Mozilla Bugzilla и находится в статусе open. Следовательно, важно помнить, что если свойства поддерживаются одинаково в разных браузерах по-отдельности, то это не гарантирует ожидаемого поведения при их совместном использовании. Backdrop-filter + preserve-3D в Firefox и Chromium. Разная реализация HTML элементов Еще один пример кроссбраузерности — реализация нативных элементов формы, например поля для поиска или чисел. Несмотря на то, что поведение таких элементов описано в стандартах HTML и CSS, их внешний вид частично определяется браузером. Так, Chrome и Firefox исторически использовали разные стили для разных полей формы. Это связано с тем, что браузер для элементов формы предоставляет собственный интерфейс и применяет UA-стили. Как следствие мы имеем, что кроссбраузерность может затрагивать не только поддержку CSS свойств, но и стандартные компоненты браузера. Поэтому разработчики часто сбрасывают стандартные стили, чтобы получить одинаковое отображение во всех браузерах. Search input в Firefox. Search input в Chromium. Cumulative Layout Shift Основная сложность с CLS в контексте кроссбраузерности — отсутствие универсальной поддержки: эту метрику умеют измерять только браузеры на движке Chromium, тогда как Firefox и Safari не предоставляют для этого нужного API. Это означает, что данные о сдвигах макетов от пользователей этих браузеров не попадают в отчет Google CrUX, что затрудняет мониторинг CLS. В силу отсутствия обратной связи разработчикам приходится действовать на опережение и жестко задавать размеры фото и видео-контента на странице, использовать aspect-ratio с проверкой поддержки, а также добавлять визуальное регрессионное тестирование в CI/CD. Почему же на CLS нельзя просто «забить» и оставить все как есть? На самом деле за ростом данной метрики следует несколько неприятных фактов, например проблемы с SEO-ранжированием. CLS входит в состав Core Web Vitals, а значит высокие показатели будут ухудшать позиции сайта в поисковой выдаче. Кроме того, не стоит забывать о пользовательском опыте, о котором должен заботиться каждый frontend-разработчик. Согласитесь, мало приятного, если в процессе чтения контента он съезжает или если собираешься нажать на кнопку Купить, а она смещается в самый последний момент, и вместо этого попадаешь по рекламе. Вывод Понятию кроссбраузерности уже около 30-ти лет, но проблемы с непредсказуемым поведением в разных браузерах до сих пор актуальны, хотя их и стало гораздо меньше. К сожалению, нет уникального средства для борьбы с багами такого типа, но шанс их возникновения можно значительно минимизировать за счет правильного определения целевого браузера с помощью аналитики и проверки поддерживаемости решения на CanIUse. Также можно отслеживать актуальные баги на WebKit Bugzilla, Chromium Issues и Mozilla Bugzilla.