Expose Content-Encoding to ResourceTiming

[nicjansma]

Hi,

Similar to request #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

[yoavweiss]

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.

[nicjansma]

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

[horo-t]

Filed chromium side bug. https://crbug.com/327941462

+CC: @Jxck who is interested in this.

[Jxck]

Thanks @horo-t I'm happy to work on it !
Let me check.

[guohuideng2024]

Updated explainer can be found here:
https://github.com/guohuideng2024/resource-timing/blob/gh-pages/Explainers/Content_Encoding.md

[guohuideng2024]

I plan to filter the contentEncoding value before exposing it in resource timing. ( The unfiltered value in the response header remains for other uses), but how exactly the value should be filtered?

Continuing the discussing in whatwg/fetch#1742.

Below are the possible values that are registered. I am putting them in the following categories:

-- definitely allowed (confirmed that Chromium supports in WPT tests)
br
dcb
dcz
deflate
gzip
zstd

-- maybe allowed?
compress

-- What about these? Maybe not allow? why?

exi
identity
pack200-gzip
aes128gcm

-- The below are deprecated. Since we are building new feature, should we just disallow them( forcing the app to change to the up-to-date name)? Or should be be forgiving and transfer them to compress and gzip?

x-compress Deprecated (alias for compress)
x-gzip Deprecated (alias for gzip)

-- What about these? They are not registered contendEncoding values, should we disallow them?
br-d
zstd-d

++++++++++++++++
A disallowed value will be exposed as unknown
++++++++++++++++
Thanks!

[pmeenan]

I'd limit it to formats a given browser supports natively (not sure if "exi" makes that list for Chrome) and "unknown" for anything else, even if it is registered. That way the browser can be responsible for updating their enum as formats change. br-d and zstd-d were replaced by dcb and dcz and should never be reported.

…

On Fri, Dec 6, 2024 at 4:37 PM Guohui Deng ***@***.***> wrote: I plan to filter the contentEncoding value before exposing it in resource timing. (But keep the unfiltered value in the response header for other uses), but how exactly the value should be filtered? continuing the discussing in whatwg/fetch#1742 <whatwg/fetch#1742>. Below are the possible values that are registered. I am putting in the following categories: -- definitely allowed br compress dcb dcz deflate exi gzip zstd -- What about these? Maybe not allow? why? identity pack200-gzip aes128gcm -- The below are deprecated. Since we are building new feature, should we just disallow them( forcing the app to change to the up-to-date name)? Or should be be forgiving and transfer them to compress and gzip? x-compress Deprecated (alias for compress) x-gzip Deprecated (alias for gzip) -- What about these? They are not registered contendEncoding values, should we disallow them? br-d zstd-d ++++++++++++++++ A disallowed value will be exposed as unknown ++++++++++++++++ — Reply to this email directly, view it on GitHub <#381 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMOBNV25ANMQ4QXDEHMDD2EIKIXAVCNFSM6AAAAABTDBYOFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRUGIZDCNZVGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[guohuideng2024]

Based on what Patrick said above and some digging, I think the following could be filtered out:

aes128gcm: looks like this is only used for "pushing messages", not for receiving resources via fetch
compress, exi, pack200-gzip: not supported in chromium
br-d, zstd-d, x-compress and x-zip: they are deprecated name
identity: it's just a reserved name

And the following will be supported:
br, dcb, dcz, deflate, gzip, zstd

(last updated 2024/12/11)

[nhelfman]

I think we must also specify what would be the value in case there is no content encoding (i.e. uncompressed payload).
It should be differentiated from the unknown case so we can track these separately. An example use case is when a CDN process decides to no compress the payload due to some issue (a real scenario I had). It is important to being able to identify these cases.

Seems easiest to just not set the value in that case so that when the property is read it will be JS undefined. However, this will harm supportability discovery since it will not be possible to determine if there was no encoding or the feature is not supported / or allowed by the UA.

My suggestion is for a specific string value in that case:
undefined / uncompressed / no-encoding

Anyone has a preference or other suggestions?

[yoavweiss]

"identity" seems appropriate IMO.

[guohuideng2024]

Thanks for pointing out the "identity" value meaning Yoav. I missed it. :)

And I think I could mention the "identity" value too in the fetch standard modification.
I am going to modify the CLs and PRs accordingly, and I will soon start reviewing process after that.