resource-timing
resource-timing copied to clipboard
w3c
Expose Content-Encoding to ResourceTiming
Hi,
Similar to request https://github.com/w3c/resource-timing/issues/203 to expose Content-Type, I would like to request exposing the Content-Encoding of each resource to ResourceTiming.
As we're starting to see experimentation and deployments of new content encodings such as Zstandard (zstd) and compression dictionary transports (zstd-d and br-d), we are moving toward content being delivered from a large set of possible encodings, even to the same client on different page loads or (sub)requests to the same domain.
When the content encoded was a small set: (none), gzip and brotli, one could often infer the encoding depending on the encoded/decoded body sizes, though that generally only works if one "owns" the content (has visibility into what the size would be for each encoding type).
Having an explicit .contentEncoding would help with some use-cases I can think of:
- As origins and CDNs want to experiment with new Content Encodings, they could utilize phased rollouts of the above technologies and be able to segment (from RUM) the performance of clients utilizing those new technologies.
- For example, this can help with understanding real-world uptake %, how the performance behaves for those new technologies, and debugging them
- Once fully deployed, origins and CDNs could segment browsing sessions (or A/B test) with those technologies to provide value confirmation and/or debugging via RUM.
- For example, one could verify with RUM (along serverside logs) how often dictionaries are being used.
- Third-party RUM vendors could segment resource fetches by their encoding with certainty (rather than guessing based on file sizes)
- For example, RUM vendors could offer insights and suggestions to enable more advanced encodings and/or dictionaries
CC @pmeenan @horo-t
Similar to Content-Type, this probably needs to be restricted to content that is CORS-enabled or same-origin. That's not a limitation for the dictionary compression encodings (as they have similar restrictions). This might be a limitation for non-dictionary ztd/brotli.
Discussed on the Feb 29, 2024 W3C WebPerf call:
Summary:
- General agreement this would be useful for RUM providers
- This is similar to work that has been merged in for
Content-Type(behind a flag in Chromium) - Chrome net team will be picking up the spec work (in Fetch and ResourceTiming) to complete this and get it into Chromium
Filed chromium side bug. https://crbug.com/327941462
+CC: @jxck who is interested in this.
