发布时间：2025 年 3 月 18 日
长期以来，Polyfill 一直是 Web 开发人员体验的一部分，因为它们试图为并非所有浏览器都支持的 Web 功能提供支持。Polyfill 似乎是 Web 开发人员工具包中不可或缺的工具，但几乎不可能将如此复杂的关注领域提炼成一个明确的声明。
何时为某个功能使用 Polyfill 取决于该功能在各个浏览器中的可用性，而基线可以帮助您做出判断。虽然基线不会告诉您是否应该使用 Polyfill，但它为 Web 平台功能的可用性带来了清晰度，让您有机会更有选择性，因为应用程序中过多的 Polyfill 可能会带来显著的缺点。
什么是 Polyfill？
Polyfill 是一段代码，用于评估浏览器对某个功能的支持情况，如果浏览器不支持该功能，它将使用 JavaScript 尝试提供缺失的功能。
Polyfill 的早期示例是 Matchmedia.js，它使用 JavaScript 检测并提供对 matchMedia 方法的支持。matchMedia 让开发者可以评估媒体查询是否与 JavaScript 中当前视口的state匹配。通过加载 Polyfill 来提供缺失的功能，可以在任何浏览器中使用 matchMedia 方法，但现在已不再需要此 Polyfill，因为 matchMedia 在几乎所有正在使用的浏览器中都可用。
虽然在某些方面，为不受支持的功能添加支持是有利的，但 Polyfill 的缺点往往被忽视。随着 Web 应用程序中 Polyfill 数量的增加，它们可能会开始产生负面影响。
Polyfill 有哪些缺点？
与浏览器中支持的相同功能相比，Polyfill 功能始终会产生一定的成本，并且随着您添加更多 Polyfill，这些成本会累积。
- Polyfill 是用 JavaScript 编写的，Web 应用程序中任何额外的 JavaScript 都可能影响性能。负面影响可能包括渲染阻塞，以及由于 额外的长任务（JavaScript 可能会通过额外的解析和编译工作引入）而阻塞主线程。
- 如果 Polyfill 不遵守它们试图模拟的功能的规范，它们也可能影响无障碍功能。某些功能会以 Polyfill 不会或不能的方式修改辅助功能树。
- 与直接在浏览器中实现的功能相比，Polyfill 可能无法忠实地再现它们试图提供的功能的所有方面。这可能会导致用户体验以意想不到的方式受到影响，或限制功能的可使用程度。
一个很好的例子是 容器查询 Polyfill，它带有一些缺点。容器查询让您可以根据 HTML 元素自身的状态应用 CSS 规则，而不是媒体查询，后者让您可以根据视口的状态将 CSS 应用于元素。此 Polyfill 使用 ResizeObserver 和 MutationObserver JavaScript API 来模拟容器查询的功能。特别是，ResizeObserver 回调发生在浏览器绘制新帧之前，这会增加呈现延迟，这是优化页面交互到下次绘制 (INP) 的重要考虑因素。
除了性能之外，Polyfill 无法提供容器查询的某些方面。虽然并非每个 Polyfill 都会导致用户体验问题或 Web 功能的不完整实现，但您使用的 Polyfill 越多，您的应用程序就越有可能受到负面影响。
基线在哪里发挥作用？
过去，即使各种工具使用 browser-compat-data 等数据源来帮助开发人员做出这些艰难的决定，也很难评估某个 Web 功能是否可以安全使用。Can I Use 是一个流行的 Web 功能支持矩阵，它使用这些数据。
基线通过三个状态指示器，进一步提供关于哪些 Web 功能在所有浏览器中都受支持的清晰且一致的消息传递。
- 有限可用性：该功能并非所有主流浏览器都支持。
- 新近可用：该功能在过去 30 个月内在所有主流浏览器中出现。
- 广泛可用：该功能在过去 30 个月以上的时间里一直受到所有主流浏览器的支持。
基线不将 Polyfill 视为其消息传递的一部分。 例如，如果某个功能具有有限可用性，但可以为所有浏览器进行 Polyfill，则该功能永远不会被假定为新近可用或广泛可用。确定功能是新近可用还是广泛可用的决定性因素是给定功能是否在所有主流浏览器中完全实现。这会告知开发人员哪些功能可以安全使用，从而告知开发人员是否应该使用 Polyfill。
确定您的基线阈值
基线的主要优点是，它可以减少您在开发人员工作流程中需要担心的事情的数量。如果您决定采用任何已通过广泛可用线的功能而无需担心 Polyfill，则意味着您唯一需要考虑状态的功能是该线之外的功能。然后，基线可以帮助您决定如何处理新近可用的功能。
当所有目标浏览器都支持某个功能时，该功能将变为新近可用，但这并不自动意味着您可以在第一天就使用该功能，并期望每个用户使用的每个浏览器都支持它。现在大多数浏览器都会自动更新，但所有用户都需要时间才能收到这些更新。需要考虑的一个因素是，设备的浏览器版本何时与其操作系统版本绑定。在这些情况下，在给定用户更换其设备之前，他们将无法再接收操作系统更新。
基线功能按年度集合分组，例如 基线 2025、基线 2024 等，直到足够的时间过去，这些功能成为广泛可用集合的一部分。通过将此信息与有关用户的信息相结合，您现在可以就以下问题做出明智的决定：是使用新近可用的功能，还是结合 Polyfill 使用。
用于确定基线阈值的最佳数据源是您网站的数据源。此领域的工具正在不断发展，以包含基线阈值的数据。RUMvision 是一款提供此信息的产品。
在 RUMvision 的案例中，您不仅可以搜索对离散功能的支持，还可以查看有多少百分比的用户支持按年份划分的给定基线功能集。
如果您还没有网站的 RUM 数据，RUM Insights 可以为您提供每个基线功能集支持的广泛视图。您会注意到的一个模式是，广泛可用窗口内的基线阈值受到 98% 或更多用户的支持，最早的阈值实现了接近 100% 的用户支持。
如何确定功能支持由您决定，但一般来说，您越接近 100% 的用户，您就越有信心可以安全地使用基线 Web 功能，而无需 Polyfill。作为一般规则，如果 98% 或 99% 的用户在其选择的浏览器中支持某个功能，您很可能可以安全地使用该功能，但您仍然需要考虑这对少数用户意味着什么。
何时以及何时不 Polyfill 缺失的功能
是否使用 Polyfill 的决定是主观的，并且完全取决于您的 Web 应用程序的要求。但是，了解到使用 Polyfill 可能会给用户体验带来缺点，您应该努力尽可能少地使用它们。了解某个功能是否已达到基线新近可用或广泛可用状态应该可以为这一决定提供依据。
假设您希望使用基线新近可用的功能，但您的数据告诉您，目前 95% 的用户支持该功能。这意味着 5%（即每 20 个用户中就有 1 个）将使用不支持该功能的浏览器。这并不意味着您应该自动使用 Polyfill，因为是否需要 Polyfill 取决于功能，以及如果用户缺少该功能会产生什么影响。
虽然这可能是一个难以做出的决定，但它可能有助于您考虑不支持您希望使用的功能的浏览器中的用户可能产生的潜在负面用户体验影响，以及这些影响是否值得使用 Polyfill。
此评估标准将功能分为三类
- 增强功能：该功能以不会导致视觉变化或在不受支持时降低功能的方式增强用户体验。如果用户缺少该功能，他们很可能不会注意到。如果缺少这些功能，您很可能不需要 Polyfill 这些功能。
- 附加功能：该功能提供了一种附加优势，可能会影响网页的外观或功能，但不会以浮现严重问题的方式影响。事实上，除非用户在支持该功能的不同浏览器中比较相同的体验，否则他们甚至可能不会注意到。如果有 Polyfill 可用，请倾向于不使用它，尤其是当您已经 Polyfill 了许多其他功能时，因为添加额外的 Polyfill 只会使性能恶化。
- 关键功能：该功能提供必要的功能，如果用户的浏览器中缺少该功能，将会由于 JavaScript 评估和运行时错误、布局损坏以及其他不可接受的结果而导致体验中断。在这种情况下，您决定 Polyfill 该功能，或避免使用它并找到不同的解决方法。
弄清楚哪些功能属于哪个类别可能很棘手，但以下是一些实际示例
- 增强功能的良好示例是与性能相关的功能。诸如
fetchpriority、HTTP/3 等功能可以提高页面的性能。这有利于改善用户体验，但如果用户使用的浏览器不支持这些功能，在许多情况下，他们不会体验到不利甚至明显的影响。产品利益干系人可能可以接受绝大多数用户获得好处，只要极少数用户不会被排除在外。 - 附加功能的示例是那些增强页面视觉吸引力的功能。颜色空间和函数和 子网格 是附加功能的良好示例，如果用户缺少这些功能，他们可能不会注意到。在这种情况下，如果某些用户缺少此类功能，一些项目利益干系人可能会担心品牌完整性，但如果体验没有完全中断，则可能会确信可以采用此类功能。
- 关键功能的采用是不容商量的。此类功能的一个示例可能是 HTML
<datalist>元素，如果缺少该元素，可能会产生次优的用户体验。期望项目利益干系人不会接受采用会在某些浏览器中破坏用户体验的功能。
一般来说，以下是您可以根据功能的基线状态评估哪些功能属于哪个类别的方式
- 如果某个功能广泛可用，您不应使用 Polyfill，除非您有关于用户的明确告知您相反情况的数据。
- 如果某个功能是新近可用，则很可能得到广泛支持，但应使用用户支持数据来确定最适合坚持的基线阈值，以最大限度地减少滋扰或不可接受的结果，并理解支持将在一段时间内提高到接近 100%。
- 如果某个功能是有限可用，则它极有可能为某些用户创建中断的体验，因此应谨慎对待，即使 Polyfill 可用。
我应该使用有限可用性功能吗？
这个问题的答案是肯定的，但有一些重要的注意事项
- 具有有限可用性的基线功能永远不能保证会变为新近可用及更高版本。您必须非常仔细地考虑这对用户体验意味着什么。
- 如果您决定采用有限可用性功能以及 Polyfill，请理解您正在向用户传递额外的字节，除非您有条件地加载这些 Polyfill，以便只有需要的用户才能获得它们。即便如此，需要它们的用户仍然会产生性能成本。
- 除了性能成本之外，如果某个功能的 Polyfill 无法忠实地复制其本机实现的等效功能的功能，则需要 Polyfill 以实现有限可用性功能的用户可能会遇到问题。这可能会影响功能，在某些情况下，甚至会影响无障碍功能。
- 有限可用性功能也可能会更改其指定的行为。特别是，任何仅在一个浏览器中实现的功能都可能在其他浏览器开始实现支持时必须更改。这意味着您的代码以及任何 Polyfill 都可能与此类更改不同步。
除非您的用户锁定到单个浏览器引擎，否则建议使用基线新近可用功能，尤其是广泛可用功能。这样做意味着您通常会花费更少的时间考虑功能支持，而将更多时间用于使用它们，并将节省的时间用于解决其他问题。
结论
在采用 Web 平台功能时，您是否应该使用 Polyfill 的规则并不明确。就像您在 Web 上所做的任何事情一样，它需要仔细思考，同时权衡收益和风险。回顾一下，解决此问题的一组粗略规则是
- 了解虽然 Polyfill 在某些方面具有优势，但它们代表了潜在的性能和无障碍功能成本，并且可能无法忠实地复制未实现的 Web 功能。
- 如果可能，请使用来自用户的数据确定您的基线阈值。如果不可能，则基线广泛可用的功能集是一个良好的起点，并考虑使用 RUM Insights 数据 来做出明智的决定。
- 使用该数据，评估如果用户的浏览器不支持您希望使用的功能，可能会有多少用户受到影响，并评估该影响的严重程度。
- 与项目利益干系人沟通，以确定哪些功能对于您项目的目标和业务需求是可接受和适当的。
- 如果您必须使用有限可用性功能，请评估您的受众以及使用它们的风险。除非您的用户锁定为使用单个浏览器引擎，否则即使使用 Polyfill，您也无法保证兼容性。
这些原因就是 Polyfill 未包含在基线中的原因。基线的作用是告知您哪些功能在所有主流浏览器引擎中都受支持。您仍然需要了解有多少用户可以使用基线功能，并根据您的用户和项目的需求做出决策。基线广泛可用通常是一个很好的默认值，并且在许多情况下通常具有最广泛的 Web 功能支持。
Web 平台的功能正在以前所未有的速度成熟，随着越来越多的功能变得可互操作并且随着时间的推移得到更广泛的支持，使用更多 Web 平台功能的机会也越来越多。这将为您提供更多机会使用更多 Web 平台功能，同时减少 Polyfill 的使用。