PerformanceResourceTiming deliveryType explainer

explainer.md

PerformanceResourceTiming deliveryType explainer

This is based on w3c/resource-timing#332. See also w3c/resource-timing#343, w3c/navigation-timing#163, WICG/nav-speculation#180.

Resources on the web are usually fetched via HTTP (from the origin server), but in some cases they are known to be delivered from a cache or other buffer, in a way that affects loading performance. Insight into this is useful for authors understanding when these caches accelerate resource loading.

The deliveryType attribute on PerformanceResourceTiming addresses this, with the following values:

""

No more specific delivery type applies, most likely because the resource was fetched from its origin server. Also returned if the user agent doesn't wish to disclose the use of a cache, for security or privacy reasons.

"cache"

The resource was served from the cache (i.e., the user agent's HTTP cache).

"navigational-prefetch"

The resource was prefetched for navigation on another page (e.g., using speculation rules) and served from the prefetch buffer when navigation subsequently occurred.

w3c/resource-timing#303 discusses how consuming a preload ought to be exposed in the future; if it is, using another deliveryType (e.g., "preload") would be viable. This is not yet proposed as of June 2023, however.

security-privacy-questionnaire.md

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This exposes information pertaining to how resources were delivered, for the purpose of allowing sites to better gather data and reason about the loading performance of their site. This is comparable to other attributes in the Resource Timing specification.

Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes.

How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

No PII is processed.

How do the features in your specification deal with sensitive information?

This information is not generally sensitive.

Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

Do the features in your specification expose information about the underlying platform to origins?

No (except to the extent that it might reveal, e.g., the existence of a persistent disk due to a cache being non-empty, and similar things).

Does this specification allow an origin to send data to the underlying platform?

No.

Do features in this specification enable access to device sensors?

No.

Do features in this specification enable new script execution/loading mechanisms?

No.

Do features in this specification allow an origin to access other devices?

No.

Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No.

What temporary identifiers do the features in this specification create or expose to the web?

None.

How does this specification distinguish between behavior in first-party and third-party contexts?

Timing-Allow-Origin protection applies, and user agents might further redact information from some contexts.

How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

All known delivery types/caches have separate state between normal and private browsing modes.

Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes.

Do features in your specification enable origins to downgrade default security protections?

No.

How does your feature handle non-"fully active" documents?

It is part of the same performance timeline as other resource timing information. Loading generally does not occur in this state, so there are no updates to the performance timeline.

What should this questionnaire have asked

No suggestions at this time.