Опубликовано: 20 мая 2025 г.
Когда функция веб-платформы внедряется в каждый браузер, она становится Baseline Newly available. Через 30 месяцев эта функция становится Baseline Widely available, что является порогом, при котором большинство веб-сайтов могут внедрять функции без проблем с совместимостью. В этом руководстве объясняется, как использовать Baseline, и как, используя данные, полученные от пользователей вашего веб-сайта, выбрать целевой показатель Baseline.
Что такое базовый целевой показатель?
Базовая цель — это группа веб-функций, которые разработчики могут выбрать для поддержки на основе их базового статуса. Существует два типа базовых целей: движущиеся цели и фиксированные цели.
Движущиеся цели, такие как Baseline Widely available или Baseline Newly available, являются целями, в которых набор содержащихся функций может меняться со временем. Движущиеся цели имеют смысл в случаях, когда вы хотите, чтобы набор поддерживаемых функций развивался автоматически по мере выпуска новых версий браузера.
Фиксированные цели — это те, в которых набор функций не меняется с течением времени. В целом, фиксированные цели основаны на календарных годах. Например, Baseline 2023 — это фиксированная цель, которая содержит набор веб-функций, которые стали Baseline Newly available в 2023 году. Baseline 2023 не будет включать функции, которые стали Baseline после 2023 года, что означает, что набор функций Baseline 2023 никогда не меняется.
Фиксированные цели имеют смысл в случаях, когда предсказуемость и детерминированность имеют первостепенное значение, но со временем они могут устареть, поэтому при использовании фиксированных целей рекомендуется регулярно переоценивать свои цели.
Зачем выбирать цель?
Внедрение функций в Интернете сдерживается из-за проблем совместимости, и это не позволяет Интернету быть настолько хорошим, насколько он мог бы быть. Baseline не только вносит ясность в вопрос поддержки функций в браузерах, но и может быть полезен в том, как он проясняет вопрос о том, когда вы можете использовать определенные функции. Выбрав цель, которая отражает вашу аудиторию и требования, вы можете быть уверены в использовании функций в этой целевой группе, без необходимости проверять отдельные функции по одной.
Используйте данные для выбора базовой цели
Знание правильной базовой цели для выбора должно быть, когда это возможно, решением, основанным на данных. Когда у вас есть данные перед глазами, выбор цели становится более простым и гораздо более обоснованным решением.
Если у вас есть данные Real User Monitoring для вашего сайта, вы можете узнать, как базовые цели сопоставляются с вашими пользователями. Например, если вы используете Google Analytics, бесплатный способ получить эту информацию — использовать Google Analytics Baseline Checker .
Чтобы использовать его, вам нужно создать новое исследование в Google Analytics, добавить некоторые показатели и измерения в ваш отчет и экспортировать отчет как файл TSV. Этот процесс подробно описан в этих инструкциях . Когда вы импортируете файл TSV в средство проверки, вы должны получить вывод, который выглядит следующим образом:

Мы начинаем видеть, как другие инструменты реализуют поддержку Baseline, что может дать вам динамическое представление о том, какая часть вашей аудитории поддерживает заданную цель. Например, RUMvision включает панель инструментов, которая показывает, какая часть вашей аудитории поддерживает каждый год Baseline.
Что делать, если у меня нет данных поддержки от реальных пользователей?
Вы можете оказаться в ситуации, когда вы не можете получить реальные пользовательские данные, когда дело касается функций, которые являются базовыми. Хорошей новостью является то, что вы можете получить общее представление о поддержке различных базовых целей через RUM Archive Insights , даже позволяя вам фильтровать данные до уровня страны. Хотя эти данные не будут специфичны для пользователей вашего веб-сайта. Это общий информационный инструмент, который демонстрирует, что следующие предположения, как правило, безопасны:
- Более новые базовые цели, например, текущего года или предыдущего, скорее всего, будут иметь наименьшую поддержку среди ваших пользователей. Однако, как и любая базовая цель, они будут иметь лучшую поддержку со временем.
- Более старые базовые цели — особенно Baseline Widely available — будут хорошо поддерживаться. Если есть сомнения, Widely available — отличная цель, которая развивается по мере того, как 30-месячное окно прогрессирует с течением времени.
- Даже более старые базовые цели — те, что намного дальше 30-месячного окна Widely available — будут иметь лучшую поддержку. Хотя Widely available — это хорошая цель по умолчанию, особые случаи использования, требующие строгих SLA.
Вероятно, что даже если вы выбираете базовую цель, которой больше пяти лет, вы можете принять функции, которые вы сейчас не используете. В лучшем случае вы уже можете использовать эти функции, но с полифиллами, которые вам могут не понадобиться .
Как обеспечить соблюдение выбранного базового целевого показателя в моем проекте?
Browserslist — это часто используемый метод выбора браузеров, которые вы хотите поддерживать. Он используется в упаковщиках и других связанных инструментах, таких как Babel и PostCSS , чтобы решить, нужно ли преобразовывать или даже заполнять полифиллом определенные фрагменты кода.
Теперь можно использовать Baseline с Browserslist, так что при выборе цели Baseline вы можете указать ее как допустимый запрос Browserslist. Это гарантирует, что инструменты в вашем проекте преобразуют код в соответствии с выбранной вами целью. Для получения дополнительной информации прочтите Use Baseline with Browserslist .
А как быть с функциями, которые не соответствуют моему базовому целевому показателю?
После выбора цели Baseline у вас могут быть функции, которые вы хотите использовать, но не попадают в эту цель. Baseline не говорит вам, что вам следует делать здесь, и хотите ли вы рассмотреть возможность использования этих функций, зависит от типа веб-сайта, который вы создаете, и ожидаемой аудитории.
Например, веб-сайты электронной коммерции или B2B могут быть готовы иметь более низкий порог поддержки и решать проблемы по мере поддержки их пользователями, тогда как правительственные веб-сайты могут требовать более высокий порог поддержки. Одно важное правило здесь заключается в том, что не все веб-функции выходят из строя одинаково . Существует много способов категоризации функций по тому, как они выходят из строя, но один из способов группирования функций, которые могут быть полезны, выглядит примерно так:
- Улучшение: Если функция используется в неподдерживаемом браузере, то работа не нарушается. Возможно, работа может ухудшиться, но, скорее всего, это не будет заметно пользователю. Пример:
loading="lazy"
. - Additive: Функция обеспечивает некоторые дополнительные преимущества, которые могут быть заметны, например, изменения в стиле страницы или некоторых функциональных возможностях. Разница может быть не заметна пользователям, если функция не поддерживается, за исключением сравнения в браузере, который ее поддерживает. Пример: Subgrid
- Критический: Если функция не поддерживается, у пользователя будет негативный пользовательский опыт — возможно, даже полностью сломанный. Пример: API доступа к файловой системе используется как центральная и необходимая функция.
Вы также можете обнаружить, что определенные функции за пределами вашей цели имеют лучшую поддержку, чем вы думаете. Можно понять, сколько ваших пользователей поддерживают определенную функцию. Can I Use имеет возможность проверять поддержку отдельных функций по вашим аналитическим данным. RUMvision также имеет возможность детализировать и исследовать данные на уровне функций, если это вам полезно.
Таким образом, вы можете использовать базовую цель, чтобы сократить количество функций, которые вам нужно тщательно рассмотреть. Обо всем, что находится внутри вашей цели, вам не нужно беспокоиться. Если есть одна или две функции вне вашей цели, которые были бы особенно полезны — у вас есть инструменты для дальнейшего изучения и решения, следует ли использовать полифил или использовать в качестве прогрессивного улучшения.
Заключение
Каждое веб-приложение имеет разные требования — от сайта электронной коммерции, который может выдержать больше проблем с несовместимостью, до правительственного веб-сайта, который обязательно должен быть доступен и работоспособен для как можно большего числа пользователей. Это расчеты, которые вы должны сделать самостоятельно, и цель Baseline не в том, чтобы говорить вам , какие решения принимать, когда дело доходит до принятия новых веб-функций, а скорее в том, как .