资源计时

W3C 候选推荐标准草案

关于此文档的更多详细信息
该版本:
https://www.w3.org/TR/2025/CRD-resource-timing-20250603/
最新发布版本:
https://www.w3.org/TR/resource-timing/
最新编辑草案:
https://w3c.github.io/resource-timing/
历史记录:
https://www.w3.org/standards/history/resource-timing/
提交历史
实现报告:
https://w3c.github.io/test-results/resource-timing/all.html
编辑:
Yoav Weiss (谷歌)
(谷歌)
前编辑:
Ilya Grigorik (谷歌) (截至2021年1月)
(微软公司) (截至2021年1月)
(谷歌公司) (截至2014年12月)
(微软公司) (截至2014年2月)
Zhiheng Wang (谷歌公司) (截至2012年7月)
Anderson Quach (微软公司) (截至2011年3月)
反馈:
GitHub w3c/resource-timing (拉取请求, 新问题, 打开的问题)
public-web-perf@w3.org 标题为 [ResourceTiming] (存档)
浏览器支持:
caniuse.com

摘要

本规范定义了一个接口,供 web 应用程序访问文档中资源的完整计时信息。

本文档的状态

本节描述了本文档发布时的状态。 W3C 当前的出版物列表以及本技术报告的最新修订版可以在 W3C 标准和草案索引(位于 https://www.w3.org/TR/)中找到。

本文档由 Web 性能工作组作为候选推荐标准草案发布, 采用推荐标准流程

作为候选推荐标准发布并不意味着 W3C 及其成员的认可。候选推荐标准草案整合了先前候选推荐标准中的更改,工作组打算将其包含在后续的候选推荐标准快照中。

这是一份草案文件,可能随时被其他文件更新、替换或废弃。 将本文档作为正在进行的工作以外的任何形式引用都是不合适的。

本文档由一个在 W3C 专利政策下运作的小组制定。 W3C 维护着一份与其可交付成果相关的任何专利披露的 公开列表; 该页面还包括披露专利的说明。 任何实际知晓某项专利包含其认为的 必要权利要求的个人, 必须根据 W3C 专利政策第 6 节披露该信息。

本文档受 2023年11月3日 W3C 流程文档的约束。

1. 引言

本节是非规范性的。

用户延迟是 Web 应用程序的一个重要质量基准。虽然基于 JavaScript 的机制可以为应用程序内的用户延迟测量提供全面的工具,但在许多情况下,它们无法提供完整的端到端延迟信息。本文档引入了 PerformanceResourceTiming 接口,使 JavaScript 机制能够收集与文档中资源相关的完整计时信息。导航计时 2 [NAVIGATION-TIMING-2] 扩展了本规范,以提供与导航相关的附加计时信息。

例如,以下 JavaScript 展示了一个简单的尝试,来测量获取资源所花费的时间:

<!doctype html>
<html>
  <head>
  </head>
  <body onload="loadResources()">
    <script>
        function loadResources()
        {
          var start = new Date().getTime();
          var image1 = new Image();
          var resourceTiming = function() {
              var now = new Date().getTime();
              var latency = now - start;
              alert("End to end resource fetch: " + latency);
          };

          image1.onload = resourceTiming;
          image1.src = 'https://www.w3.org/Icons/w3c_main.png';
        }
    </script>
    <img src="https://www.w3.org/Icons/w3c_home.png">
  </body>
</html>

尽管此脚本可以测量获取资源所花费的时间,但它无法细分各个阶段所花费的时间。此外,该脚本无法轻松测量标记中描述的资源的获取时间。

为了解决对用户体验的完整信息的需求,本文档引入了 PerformanceResourceTiming 接口。此接口允许 JavaScript 机制在应用程序中提供完整的客户端延迟测量。使用此接口,可以修改上面的示例来测量用户感知的资源加载时间。

下面的脚本计算页面中每个资源的获取时间,即使是标记中定义的资源。此示例假设该页面托管在 https://www.w3.org。还可以进一步测量获取资源的每个阶段所花费的时间,使用 PerformanceResourceTiming 接口。

<!doctype html>
<html>
  <head>
  </head>
  <body onload="loadResources()">
    <script>
      function loadResources()
      {
          var image1 = new Image();
          image1.onload = resourceTiming;
          image1.src = 'https://www.w3.org/Icons/w3c_main.png';
      }

      function resourceTiming()
      {
          var resourceList = window.performance.getEntriesByType("resource");
          for (i = 0; i < resourceList.length; i++)
          {
              if (resourceList[i].initiatorType == "img")
              {
                alert("End to end resource fetch: " + (resourceList[i].responseEnd - resourceList[i].startTime));
              }
          }
      }
    </script>
    <img id="image0" src="https://www.w3.org/Icons/w3c_home.png">
  </body>
</html>

2. 一致性

除了标记为非规范性的部分外,本规范中的所有编写指南、图表、示例和注释均为非规范性的。本规范中的其他内容都是规范性的。

本文档中的关键词 MAYMUSTSHOULD 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释, 当且仅当它们以全大写形式出现时,如此处所示。

算法中的命令性需求(例如“去掉所有前导空格字符”或“返回 false 并中止这些步骤”)应按照引入算法时使用的关键字(如“MUST”、"SHOULD"、"MAY"等)的含义来解释。

某些一致性要求以属性、方法或对象为要求,这些要求应解释为对用户代理的要求。

以算法或具体步骤表述的一些一致性要求可以通过任何方式实现,只要最终结果等效即可。(特别是,本规范中定义的算法旨在易于理解,而非旨在高效运行。)

3. 术语

表述 “一个 Foo 对象”,其中 Foo 实际上是一个接口,有时会用来代替更准确的说法 “一个实现了接口 Foo 的对象”。

在本规范中,所有的时间值都是自文档导航开始以来的毫秒数 [HR-TIME]。例如,文档导航的开始 发生在时间 0。

注意

此时间定义基于高分辨率时间规范 [HR-TIME],与导航计时规范 [NAVIGATION-TIMING-2] 使用的时间定义不同,后者的时间是自1970年1月1日午夜(UTC)以来的毫秒数。

4. 资源计时

4.1 引言

本节是非规范性的。

PerformanceResourceTiming 接口有助于对获取的 http(s) 资源进行计时测量。例如,此接口可用于 XMLHttpRequest 对象 [XHR]、HTML 元素 [HTML](例如 iframeimgscriptobjectembed 和链接类型为 stylesheetlink)、SVG 元素 [SVG11] (例如 svg)以及 EventSource

4.2 PerformanceResourceTiming 接口中包含的资源

本节是非规范性的。

由非 null 客户端获取的资源请求会作为 PerformanceResourceTiming 对象包含在客户端全局对象性能时间轴中,除非在获取过程中被排除在时间轴之外。从 HTTP 缓存中检索的资源会作为 PerformanceResourceTiming 对象包含在性能时间轴中。已启动获取但稍后中止(例如由于网络错误)的资源会作为PerformanceResourceTiming 对象包含在性能时间轴中,并带有其开始和结束计时。

示例:

4.3 PerformanceResourceTiming 接口

WebIDL[Exposed=(Window,Worker)]
interface PerformanceResourceTiming : PerformanceEntry {
    readonly attribute DOMString initiatorType;
    readonly attribute DOMString deliveryType;
    readonly attribute ByteString nextHopProtocol;
    readonly attribute DOMHighResTimeStamp workerStart;
    readonly attribute DOMHighResTimeStamp redirectStart;
    readonly attribute DOMHighResTimeStamp redirectEnd;
    readonly attribute DOMHighResTimeStamp fetchStart;
    readonly attribute DOMHighResTimeStamp domainLookupStart;
    readonly attribute DOMHighResTimeStamp domainLookupEnd;
    readonly attribute DOMHighResTimeStamp connectStart;
    readonly attribute DOMHighResTimeStamp connectEnd;
    readonly attribute DOMHighResTimeStamp secureConnectionStart;
    readonly attribute DOMHighResTimeStamp requestStart;
    readonly attribute DOMHighResTimeStamp finalResponseHeadersStart;
    readonly attribute DOMHighResTimeStamp firstInterimResponseStart;
    readonly attribute DOMHighResTimeStamp responseStart;
    readonly attribute DOMHighResTimeStamp responseEnd;
    readonly attribute unsigned long long  transferSize;
    readonly attribute unsigned long long  encodedBodySize;
    readonly attribute unsigned long long  decodedBodySize;
    readonly attribute unsigned short responseStatus;
    readonly attribute RenderBlockingStatusType renderBlockingStatus;
    readonly attribute DOMString contentType;
    readonly attribute DOMString contentEncoding;
    [Default] object toJSON();
};

一个 PerformanceResourceTiming 具有一个关联的 DOMString 发起者类型

一个 PerformanceResourceTiming 具有一个关联的 DOMString 交付类型

一个 PerformanceResourceTiming 具有一个关联的 DOMString 请求的 URL

一个 PerformanceResourceTiming 具有一个关联的 DOMString 缓存模式 (空字符串、“local”或“validated”)。

一个 PerformanceResourceTiming 有一个关联的 获取计时信息 计时信息

一个 PerformanceResourceTiming 有一个关联的 响应体信息 资源信息

一个 PerformanceResourceTiming 具有一个关联的 状态 响应状态

一个 PerformanceResourceTiming 具有一个关联的 RenderBlockingStatusType 渲染阻塞状态

当调用 toJSON 时,为 PerformanceResourceTiming 运行默认 toJSON 步骤

initiatorType getter 步骤是为 this 返回发起者类型

注意

initiatorType 返回以下值之一:

  • "navigation",如果请求是导航请求
  • "css",如果请求是处理 CSS url() 指令(例如 @import url()background: url())的结果;[CSS-VALUES]
  • "script",如果请求是加载任何脚本(经典的 script模块脚本Worker)的结果。
  • "xmlhttprequest",如果请求是处理 XMLHttpRequest 的结果;
  • "fetch",如果请求是处理 fetch() 方法的结果;
  • "beacon",如果请求是处理 sendBeacon() 方法的结果;[BEACON]
  • "video",如果请求是处理 video 元素的 postersrc 的结果。
  • "audio",如果请求是处理 audio 元素的 src 的结果。
  • "track",如果请求是处理 track 元素的 src 的结果。
  • "img",如果请求是处理 img 元素的 srcsrcset 的结果。
  • "image",如果请求是处理 image 元素的结果。[SVG2]
  • "input",如果请求是处理 typeimageinput 元素的结果。
  • "a",如果请求是处理 a 元素的 downloadping 的结果。
  • "iframe",如果请求是处理 iframesrc 的结果。
  • "frame",如果请求是加载 frame 的结果。
  • "other",如果以上条件均不匹配。
注意

initiatorType 的设置是在报告资源计时条目的不同位置完成的,例如 fetch 标准。

deliveryType getter 步骤是为 this 返回交付类型

注意

deliveryType 返回以下值之一:

  • "cache",如果缓存模式不是空字符串。
  • 空字符串 "",如果不匹配上述任何条件。

预计未来的规范更新将扩展此内容,例如描述如何消费预加载资源和预取导航请求。

workerStart getter 步骤是为 this计时信息最终 service worker 启动时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 获取

redirectStart getter 步骤是为 this计时信息重定向开始时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 重定向获取

redirectEnd getter 步骤是为 this计时信息重定向结束时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 重定向获取

fetchStart getter 步骤是为 this计时信息重定向后开始时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 获取

domainLookupStart getter 步骤是为 this计时信息最终连接计时信息域名查找开始时间this相关全局对象转换获取时间戳。更多信息请参见记录连接计时信息

domainLookupEnd getter 步骤是为 this计时信息最终连接计时信息域名查找结束时间this相关全局对象转换获取时间戳。更多信息请参见记录连接计时信息

connectStart getter 步骤是为 this计时信息最终连接计时信息连接开始时间this相关全局对象转换获取时间戳。更多信息请参见记录连接计时信息

connectEnd getter 步骤是为 this计时信息最终连接计时信息连接结束时间this相关全局对象转换获取时间戳。更多信息请参见记录连接计时信息

secureConnectionStart getter 步骤是为 this计时信息最终连接计时信息安全连接开始时间this相关全局对象转换获取时间戳。更多信息请参见记录连接计时信息

nextHopProtocol getter 步骤是同构解码 this计时信息最终连接计时信息ALPN 协商协议。更多信息请参见记录连接计时信息

注意

问题 221 建议移除对 nextHopProtocol 的支持,因为它可能会泄露用户网络配置的详细信息。

requestStart getter 步骤是为 this计时信息最终网络请求开始时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 获取

firstInterimResponseStart getter 步骤是为 this计时信息第一个临时网络响应开始时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 获取

finalResponseHeadersStart getter 步骤是为 this计时信息最终网络响应开始时间this相关全局对象转换获取时间戳。更多信息请参见 HTTP 获取

responseStart getter 步骤是返回 thisfirstInterimResponseStart(如果不为 0);否则返回 thisfinalResponseHeadersStart

responseEnd getter 步骤是为 this计时信息结束时间this相关全局对象转换获取时间戳。更多信息请参见 获取

encodedBodySize getter 步骤是返回 this资源信息编码大小

decodedBodySize getter 步骤是返回 this资源信息解码大小

transferSize getter 的步骤是:

  1. 如果 this缓存模式是“local”,则返回 0。

  2. 如果 this缓存模式是“validated”,则返回 300。

  3. 返回 this响应体信息编码大小加 300。

    注意

    添加到 transferSize 的常量数字取代了公开 HTTP 标头的总字节大小,因为这可能会暴露某些 cookie 的存在。请参见此问题

responseStatus getter 步骤是返回 this响应状态

注意

responseStatus获取中确定。对于跨域 no-cors 请求,它将为 0,因为响应将是不透明的过滤响应

contentType getter 步骤是返回 this资源信息内容类型

contentEncoding getter 的步骤是返回 此对象资源信息内容编码

renderBlockingStatus getter 步骤是如果 this计时信息渲染阻塞为 true,则返回 blocking;否则返回 non-blocking

注意

实现 PerformanceResourceTiming 的用户代理需要在 supportedEntryTypes 中包含 "resource"。这允许开发人员检测对资源计时的支持。

4.3.1 RenderBlockingStatusType 枚举

WebIDLenum RenderBlockingStatusType {
                "blocking",
                "non-blocking"
            };

这些值的定义如下:

blocking
资源可能会阻止渲染。
non-blocking
资源不会阻止渲染。

4.4 Performance 接口的扩展

用户代理 可以 限制多少资源作为 PerformanceResourceTiming 对象包含在 性能时间线 中 [PERFORMANCE-TIMELINE-2]。此部分扩展了 Performance 接口,以允许控制存储的 PerformanceResourceTiming 对象的数量。

推荐的 PerformanceResourceTiming 对象的最小数量是 250,尽管此数量可能会由用户代理更改。 可以调用 setResourceTimingBufferSize 来请求更改此限制。

每个 ECMAScript 全局环境 都有:

WebIDLpartial interface Performance {
          undefined clearResourceTimings ();
          undefined setResourceTimingBufferSize (unsigned long maxSize);
          attribute EventHandler onresourcetimingbufferfull;
        };

Performance 接口定义在 [HR-TIME] 中。

clearResourceTimings 方法运行以下步骤:

  1. 删除 PerformanceResourceTiming 对象在 性能条目缓冲区 中的所有实例。
  2. 资源计时缓冲区当前大小 设置为 0。

setResourceTimingBufferSize 方法运行以下步骤:

  1. 资源计时缓冲区大小限制 设置为 maxSize 参数。如果 maxSize 参数小于 资源计时缓冲区当前大小,则不从 性能条目缓冲区 中删除任何 PerformanceResourceTiming 对象。

onresourcetimingbufferfullresourcetimingbufferfull 事件的事件处理程序,描述如下。

要检查 是否可以添加资源计时条目,请执行以下步骤:

  1. 如果 资源计时缓冲区当前大小 小于 资源计时缓冲区大小限制,则返回 true。
  2. 返回 false。

添加 PerformanceResourceTiming 条目 new entry性能条目缓冲区 中,请执行以下步骤:

  1. 如果 是否可以添加资源计时条目 返回 true 且 资源计时缓冲区已满事件挂起标志 为 false,请执行以下子步骤:
    1. new entry 添加到 性能条目缓冲区
    2. 资源计时缓冲区当前大小 增加 1。
    3. 返回。
  2. 如果 资源计时缓冲区已满事件挂起标志 为 false,请执行以下子步骤:
    1. 资源计时缓冲区已满事件挂起标志 设置为 true。
    2. 排队任务性能时间线任务源,运行 触发缓冲区已满事件
  3. new entry 添加到 资源计时次要缓冲区 中。
  4. 资源计时次要缓冲区当前大小 增加 1。

复制次要缓冲区,请执行以下步骤:

  1. 资源计时次要缓冲区 非空时,并且 是否可以添加资源计时条目 返回 true,请运行以下子步骤:
    1. entry 设置为最旧的 PerformanceResourceTiming资源计时次要缓冲区 中。
    2. entry 添加到 性能条目缓冲区 的末尾。
    3. 资源计时缓冲区当前大小 增加 1。
    4. entry资源计时次要缓冲区 中移除。
    5. 资源计时次要缓冲区当前大小 减少 1。

触发缓冲区已满事件,请执行以下步骤:

  1. 资源计时次要缓冲区 非空时,请运行以下子步骤:
    1. number of excess entries before 设置为 资源计时次要缓冲区当前大小
    2. 如果可以添加资源计时条目返回 false,则在 Performance 对象上触发一个名为 resourcetimingbufferfull 的事件。
    3. 运行 复制次要缓冲区
    4. number of excess entries after 设置为 资源计时次要缓冲区当前大小
    5. 如果 number of excess entries before 小于等于 number of excess entries after,则从 资源计时次要缓冲区 中移除所有条目, 将 资源计时次要缓冲区当前大小 设置为 0,并中止这些步骤。
  2. 资源计时缓冲区已满事件挂起标志 设置为 false。

    这意味着,如果 resourcetimingbufferfull 事件处理程序没有比它向缓冲区添加的资源腾出更多空间, 则多余的条目将从缓冲区中丢弃。开发者应该确保 resourcetimingbufferfull 事件处理程序调用 clearResourceTimings 或足够扩展缓冲区(通过调用 setResourceTimingBufferSize)。

4.5 跨域资源

注意

正如 Fetch 中详述的,跨域资源的请求作为 PerformanceResourceTiming 对象包含在性能时间轴中。如果跨域资源的计时允许检查算法失败,则该条目将是一个不透明条目。此类条目的大部分属性都会被屏蔽,以防止泄露未公开的跨域数据。因此,对于一个不透明条目,以下属性将被设置为零: redirectStartredirectEndworkerStartdomainLookupStartdomainLookupEndconnectStartconnectEndrequestStartfirstInterimResponseStartfinalResponseHeadersStartresponseStartsecureConnectionStarttransferSizeencodedBodySizedecodedBodySize。 此外, nextHopProtocol 属性将被设置为空字符串。

服务器端应用程序可以返回 Timing-Allow-Origin HTTP 响应头,以允许用户代理完全向指定的文档源公开那些由于跨域限制而设置为零的属性值。

4.5.1 Timing-Allow-Origin 响应头

Timing-Allow-Origin HTTP 响应头字段可用于传达一个策略,该策略指示哪些源可以查看由于跨域限制而本应为零的属性值。该标头的值由以下 ABNF [RFC5234] 表示(使用列表扩展,[RFC9110]):

Timing-Allow-Origin = 1#( origin-or-null / wildcard )

发送方 可以 生成多个 Timing-Allow-Origin 头字段。接收方 可以 通过将每个后续字段值按顺序附加到组合字段值来组合多个 Timing-Allow-Origin 头字段,使用逗号分隔。

用户代理 可以 仍然执行跨域限制并将 transferSize、encodedBodySize 和 decodedBodySize 属性设置为零,即使存在 Timing-Allow-Origin HTTP 响应头字段。如果这样做,它 可以 还将 deliveryType 设置为空字符串 ""。

Timing-Allow-Origin 头字段在 FETCH 中处理以相应地计算属性。

Timing-Allow-Origin 头字段可能作为缓存响应的一部分到达。在缓存重新验证的情况下,根据 RFC 7234, 该头字段的值可能来自重新验证响应,或者如果那里没有出现,则来自原始缓存的资源。

问题 222223 建议从 Timing-Allow-Origin 中删除通配符支持,以限制其使用。

4.5.2 IANA 考虑事项

本节将 Timing-Allow-Origin 注册为 临时消息头

头字段名称:
Timing-Allow-Origin
适用协议:
http
状态:
临时
作者/变更控制者:
W3C
规范文档:
4.5.1 Timing-Allow-Origin 响应头

4.6 资源计时属性

本节是非规范性的。

下图说明了 PerformanceResourceTiming 接口定义的计时属性。在获取跨域资源时,括号中的属性可能不可用。用户代理可能会在计时之间执行内部处理,这允许计时之间存在非规范性间隔。

1 该图说明了 PerformanceResourceTiming 接口定义的计时属性。括号中的属性表示如果资源未通过 时间允许检查 算法,它们可能不可用。
资源计时属性

4.7 创建资源计时条目

标记资源计时,给定一个 获取计时信息 timingInfo、一个 DOMString requestedURL、一个 DOMString initiatorType、一个全局对象 global、一个字符串 cacheMode、一个 响应体信息 bodyInfo、一个 状态 responseStatus 以及一个可选的字符串 deliveryType(默认为空字符串),请执行以下步骤:

  1. global领域中创建一个 PerformanceResourceTiming 对象 entry
  2. 给定 initiatorTyperequestedURLtimingInfocacheModebodyInforesponseStatusdeliveryType,为 entry 设置资源计时条目
  3. 排队 entry
  4. entry 添加global性能条目缓冲区

要为 PerformanceResourceTiming entry 设置资源计时条目,给定 DOMString initiatorType、DOMString requestedURL获取计时信息 timingInfo、一个 DOMString cacheMode、一个 响应体信息 bodyInfo、一个 状态 responseStatus 以及一个可选的 DOMString deliveryType(默认为空字符串),请执行以下步骤:

  1. 断言 cacheMode 为空字符串、"local" 或 "validated"。
  2. globalentry相关全局对象
  3. 初始化 entry,给定转换 timingInfo开始时间(给定 global)、"resource"、requestedURL 以及转换 timingInfo结束时间(给定 global)的结果。
  4. entry发起者类型设置为 initiatorType
  5. entry请求的 URL 设置为 requestedURL
  6. entry计时信息设置为 timingInfo
  7. entry响应体信息设置为 bodyInfo
  8. entry缓存模式设置为 cacheMode
  9. entry响应状态设置为 responseStatus
  10. 如果 deliveryType 为空字符串且 cacheMode 不为空,则将 deliveryType 设置为 "cache"。
  11. entry交付类型设置为 deliveryType

转换获取时间戳,给定 DOMHighResTimeStamp ts全局对象 global,请执行以下操作:

  1. 如果 ts 为零,则返回零。
  2. 否则,返回给定 tsglobal相对高精度粗略时间

4.8 安全性考虑

本节为非规范性内容。

PerformanceResourceTiming 接口向已请求该资源的任何网页或 worker 公开该资源的计时信息。为了限制对 PerformanceResourceTiming 接口的访问,默认情况下会强制执行同源策略,并且某些属性会设置为零,如 HTTP 获取中所述。资源提供者可以通过添加 Timing-Allow-Origin HTTP 响应头来明确允许收集资源的所有计时信息,该响应头指定了允许访问计时信息的域。

4.9 隐私考虑

本节为非规范性内容。

统计指纹识别是一个隐私问题,恶意网站可以通过测量第三方网站中资源的缓存命中和未命中的时间来确定用户是否访问过该第三方网站。尽管 PerformanceResourceTiming 接口提供了文档中资源的计时信息,但资源的加载事件已经可以有限地测量计时以确定缓存命中和未命中,并且 HTTP 获取中的跨域限制阻止了任何其他信息的泄漏。

4.10 致谢

感谢 Anne Van Kesteren、Annie Sullivan、Arvind Jain、Boris Zbarsky、Darin Fisher、Jason Weber、Jonas Sicking、James Simonsen、 Karen Anderson、Kyle Scholz、Nic Jansma、Philippe Le Hegaret、Sigbjørn Vik、Steve Souders、Todd Reifsteck、Tony Gentilcore、 William Chan 和 Alex Christensen 对这项工作的贡献。

A. 参考文献

A.1 规范性参考文献

[dom]
DOM 标准. Anne van Kesteren. WHATWG. 现行标准. URL: https://dom.spec.whatwg.org/
[FETCH]
Fetch 标准. Anne van Kesteren. WHATWG. 现行标准. URL: https://fetch.spec.whatwg.org/
[HR-TIME]
高精度时间. Yoav Weiss. W3C. 2024年11月7日. W3C 工作草案. URL: https://www.w3.org/TR/hr-time-3/
[HTML]
HTML 标准. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 现行标准. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra 标准. Anne van Kesteren; Domenic Denicola. WHATWG. 现行标准. URL: https://infra.spec.whatwg.org/
[NAVIGATION-TIMING-2]
导航计时级别 2。 Yoav Weiss;Noam Rosenthal。W3C。2025年2月13日。W3C 工作草案。URL:https://www.w3.org/TR/navigation-timing-2/
[PERFORMANCE-TIMELINE-2]
性能时间轴。Nicolas Pena Moreno。W3C。2025年5月21日。CRD。URL:https://www.w3.org/TR/performance-timeline/
[RFC2119]
RFC 中用于指示需求级别的关键字. S. Bradner. IETF. 1997年3月. 最佳当前实践. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC2397]
"data" URL 方案. L. Masinter. IETF. 1998年8月. 建议标准. URL: https://www.rfc-editor.org/rfc/rfc2397
[RFC5234]
语法规范的增强 BNF:ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008年1月. 互联网标准. URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC8174]
RFC 2119 关键字中大写与小写的歧义. B. Leiba. IETF. 2017年5月. 最佳当前实践. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC9110]
HTTP 语义. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. 2022年6月. 互联网标准. URL: https://httpwg.org/specs/rfc9110.html
[WEBIDL]
Web IDL 标准. Edgar Chen; Timothy Gu. WHATWG. 现行标准. URL: https://webidl.spec.whatwg.org/

A.2 信息性参考文献

[BEACON]
信标. Ilya Grigorik; Alois Reitbauer. W3C. 2022年8月3日. CRD. URL: https://www.w3.org/TR/beacon/
[CSS-VALUES]
CSS 值和单位模块第 3 级. Tab Atkins Jr.; Elika Etemad. W3C. 2024年3月22日. CRD. URL: https://www.w3.org/TR/css-values-3/
[css-values-4]
CSS 值和单位模块第 4 级. Tab Atkins Jr.; Elika Etemad. W3C. 2024年3月12日. W3C 工作草案. URL: https://www.w3.org/TR/css-values-4/
[SVG11]
可缩放矢量图形 (SVG) 1.1(第二版). Erik Dahlström; Patrick Dengler; Anthony Grasso; Chris Lilley; Cameron McCormack; Doug Schepers; Jonathan Watt; Jon Ferraiolo; Jun Fujisawa; Dean Jackson et al. W3C. 2011年8月16日. W3C 推荐标准. URL: https://www.w3.org/TR/SVG11/
[SVG2]
可缩放矢量图形 (SVG) 2. Amelia Bellamy-Royds; Bogdan Brinza; Chris Lilley; Dirk Schulze; David Storey; Eric Willigers. W3C. 2018年10月4日. W3C 候选推荐标准. URL: https://www.w3.org/TR/SVG2/
[XHR]
XMLHttpRequest 标准. Anne van Kesteren. WHATWG. 现行标准. URL: https://xhr.spec.whatwg.org/