Что Baseline на самом деле сообщает
Baseline — проект группы WebDX Community Group, который переводит вопрос «можно ли использовать эту фичу браузера» в три понятных состояния. Функция может быть ограниченно доступна (ещё не во всех крупных движках), недавно доступна (появилась во всех отслеживаемых браузерах, но не у всех пользователей уже стоит достаточно свежая версия) или широко доступна — то есть присутствовала во всех этих браузерах примерно 30 месяцев подряд. Отслеживаются семь комбинаций браузер/платформа: Safari на iOS и macOS, Chrome на десктопе и Android, Edge, Firefox на десктопе и Android.
Важная деталь, которую легко упустить: отсчёт 30 месяцев идёт не от текущей даты и не от ярлыка года-когорты («Baseline 2026»), а от момента, когда функция стала «недавно доступной» именно у себя. Функция, попавшая в когорту в январе, к декабрю имеет уже почти год выслуги, а не тридцать месяцев с нуля.
И ещё одна оговорка, которую сама документация проекта формулирует прямо: Baseline — это сводка по поддержке браузерами, а не замена проверок доступности, производительности, безопасности или юзабилити. Он ничего не знает про WebView внутри мобильных приложений, про старые версии Android-браузеров за пределами семёрки отслеживаемых комбинаций и про то, как ваша страница ведёт себя со скринридером. Это метрика совместимости, не метрика готовности продукта к запуску — разница примерно такая же, как между «двигатель прошёл стендовые испытания» и «машина готова к продаже в вашем регионе с вашим климатом и дорогами».
Три проверки вместо одного лозунга
Именно здесь возникает соблазн упрощения: «в стандарте — значит, безопасно, значит, библиотека не нужна». Разбор в источнике предлагает более скромную, но рабочую рамку — три вопроса, которые стоит задавать по очереди, а не оптом.
flowchart TD A[Кандидат на удаление: библиотека X] --> B[1. Baseline-статус для моей аудитории?] B --> C[2. Сколько стоит замена: polyfill, обвязка?] C --> D[3. Совпадает ли фича с реальным use case?] D --> E[Решение: заменить, отложить или оставить]
Первый вопрос — не «в целом ли фича в Baseline», а «безопасна ли она именно для трафика конкретного проекта». Если статус — «широко доступна», ответ почти всегда да. Если статус — «недавно доступна», нужно свериться с аналитикой или конфигом browserslist: B2B-панель, где у всех современные корпоративные ноутбуки, и публичный сайт с длинным хвостом старых Android-устройств — это два разных риска под одним и тем же лейблом Baseline.
Второй вопрос — про реальную стоимость перехода. Замена библиотеки нативным API не бесплатна автоматически: если функции не хватает поддержки для части аудитории, нужен полифилл, а он иногда весит больше, чем удаляемая библиотека.
Третий вопрос — про покрытие сценария. Библиотеки часто делают больше, чем похожий на них платформенный API: axios не просто fetch с автоматическим парсингом JSON, у него есть интерцепторы, отмена запросов, повторные попытки. Прямая замена без проверки того, что вы реально используете, оставляет доработку на потом — и это уже не экономия, а перенос долга.
Где браузер действительно заменяет пакет — а где рано
Если применить эту рамку к кластерам зависимостей из разбора, картина получается неровной: часть замен уже безопасна почти для любой аудитории, часть — только для современной, а один заметный кейс показывает, когда правильный ответ — подождать.
| Кластер | Пример библиотек | Статус Baseline | Типичная экономия |
|---|---|---|---|
| Интернационализация | timeago.js, pluralize, numeral, humanize-duration | В основном широко доступна (Intl.RelativeTimeFormat, NumberFormat, ListFormat); Intl.DurationFormat — недавно | около 14 КБ |
| HTTP-клиенты | axios, superagent | fetch + AbortController широко доступны, но не копируют интерцепторы и авто-retry | около 17 КБ, с оговорками по фичам |
| UI-примитивы | модалки, tippy.js, focus-trap, body-scroll-lock | элемент dialog широко доступен; Popover API и anchor positioning — недавно | около 24 КБ |
| Lodash-утилиты | lodash.clonedeep, lodash.groupby | structuredClone широко доступен; Object.groupBy и методы Set — недавно | от 8 КБ |
| Temporal (замена Date) | dayjs, date-fns | ограниченно доступна: нет в стабильном Safari | замена сейчас увеличивает бандл на десятки килобайт |
Разница между «широко доступна» и «недавно доступна» здесь не формальность. Она буквально определяет, можно ли менять библиотеку прямо сейчас без дополнительных условий, или нужно сначала посмотреть на собственную статистику браузеров — либо поставить проверку поддержки функции с запасным вариантом в коде.
Temporal как урок о том, зачем нужна вторая и третья проверка
Самый показательный случай в разборе — это не история про удачную замену, а история про то, когда фреймворк говорит «подождите». Temporal — новый стандартный API для дат, который решает реальные и давние проблемы Date: неизменяемость объектов, разумную работу с часовыми поясами, отсутствие путаницы с нумерацией месяцев с нуля. Спецификация дошла до Stage 4 в TC39 и вошла в ES2026. Firefox и Chrome с Edge уже поддерживают Temporal нативно, но Safari до стабильного релиза его пока не довёл — он доступен только в технологическом превью.
Формально Temporal — часть подтверждённого стандарта. Но раз хотя бы один из крупных браузеров не поддерживает фичу в стабильной версии, статус Baseline остаётся «ограниченно доступна» — то есть первая проверка уже не пройдена для широкой аудитории. Вторая проверка добивает идею окончательно: официальный полифилл весит около 44 КБ сжатых, облегчённая версия — около 19 КБ, а типичная лёгкая библиотека дат вроде dayjs весит порядка 3 КБ. Замена dayjs на Temporal с полифиллом прямо сейчас не экономит килобайты, а добавляет их — плюс сорок с лишним килобайт, если не грузить полифилл условно. Третья проверка, покрытие сценария, здесь вообще не имеет значения: Temporal действительно лучше dayjs по возможностям, но это не спасает решение, которое проваливается на первых двух пунктах.
Это ровно тот случай, который не укладывается в упрощённую логику «в спецификации — значит, можно удалять библиотеку». Технология стандартизована, но пока не готова стать повсеместной заменой без оглядки на конкретный браузер и без полифилла — и это стоит держать в голове как контрпример к общему энтузиазму по поводу нативных API.
Почему доля Chrome не закрывает вопрос
Здесь уместно вспомнить контекст с браузерными долями в целом. Chrome с большим отрывом лидирует по глобальному трафику, и именно на этом основании иногда делают вывод, что «недавно доступные» фичи можно использовать почти без разбора. Но Baseline тестирует не один Chrome, а согласованность сразу семи комбинаций браузер/платформа, включая Safari на iOS и Android-версии Firefox — и совокупная доля Safari и других движков на части устройств и рынков остаётся достаточно заметной, чтобы решение «отправить недавно доступную фичу без запасного варианта» не превращалось в решение по умолчанию для любого публичного сайта. Общий охват Chrome не отменяет того, что конкретная аудитория конкретного продукта может выглядеть совсем иначе.
Что с этим делать на практике
Разбор из источника предлагает не разовую чистку, а привычку: раз в квартал выгружать список продакшен-зависимостей, сверять размер каждой через анализатор бандла, проверять статус Baseline для потенциальной замены и прогонять три вопроса по каждому кандидату. Это рутина аудита, а не единичный акт удаления библиотек по факту прочтения статьи.
Ключевой вывод скромнее, чем хотелось бы заголовкам: Baseline — полезный инструмент для аудита зависимостей, который экономит время на ручной проверке совместимости. Но он показывает совместимость браузеров, а не пригодность конкретной замены для конкретного проекта. Прежде чем удалить библиотеку, стоит по очереди пройти аудиторию, стоимость замены и совпадение с реальным сценарием использования — и только если все три пункта сходятся, лозунг «браузер уже умеет это делать» превращается в обоснованное решение, а не в красивое допущение.
