-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose Content-Encoding to ResourceTiming #381
Comments
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:
|
Filed chromium side bug. https://crbug.com/327941462 +CC: @Jxck who is interested in this. |
Thanks @horo-t I'm happy to work on it ! |
add `contentEncoding` to Resource Timing. closed w3c#381.
Hi,
Similar to request #203 to expose
Content-Type
, I would like to request exposing theContent-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
andbr-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:CC @pmeenan @horo-t
The text was updated successfully, but these errors were encountered: