Include Content Type

[Snugug]

I'd like to be able to use Resource Timing to programmatically get a sense of where my application is spend its performance budget, but unfortunately I cannot because resource timing doesn't include the ability to inspect why kind of resource it is.

I would love to see either the content-type header, a Request Destination string, or both, included in resource timing to allow for this kind of introspection of the resource.

[yoavweiss]

We've discussed adding an initiator or some other attribute which maps into Reqeust.destination. I believe that would be an improvement over the current initiatorType.

[nicjansma]

One use case where having access to Content-Type would be useful is for analyzing file formats that may be "swapped out" transparently (and the URL doesn't change).

For example, with adoption of WebP and AVIF, some websites will be built with <picture> elements where each supported image format has a different URL. But there are commercial CDNs out there that transparently swap out the image format based on the User Agent string or Client Hints. In those cases you may have a .jpg URL that actually returns image/avif.

If we had access to the Content-Type we could know exactly what format was being used. This can help in cases of understanding format adoption for a website. For analytics vendors, this could be helpful in segregating user experiences based on the image formats the client decoded.

[nicjansma]

We discussed this on the 2021/07/29 W3C WebPerf call, minutes are here: https://docs.google.com/document/d/1O-LPrbJYXZST7AdIZxQIOMFsnikiZpNk6H15mnKWAa8/edit#

Summary:

• There are a couple different potential scenarios/requirements in this ticket from (1) understanding request destination to (2) accessing Content-Type to (3) what format the browser interpreted requests at. Each may have different solutions.
• Some servers may lie about Content-Type and that MIME Sniffing rules come into play to determine what the UA may actually read the content as.
  • MIME sniffing rules are not highly spec compliant between browsers, none are over 50% passing and there are a lot of edge-cases so it may not be a reliable spec to use for this
• For the scenario I mentioned before, understanding the "interpreted" Content Type (whatever the browser reads the content as) would be more valuable than the server's raw Content-Type header.

[alonkochba]

Adding my 2 cents here - we ran into the need to determine our images content-type, specifically for LCP images. The approach we originally took at the time to report this data was not using Server-Timing, but rather issuing a new HEAD request for LCP images, which we took the content-type from and reported in our RUM. It's worth noting that we use a server side mechanism to decide on the image format according to accept header, disregarding the extension of the requested filename.

This helped understand the breakdown of what image formats are the LCP across all of Wix's sites, as part of our efforts to move to more extensive use of WebP, gifs removal etc.

Today, with @yoavweiss's help, I realized that this approach was actually causing problems for us with browser cache - the HEAD request seems to have been evicting the cache for the image! I opened this chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=1319926, but regardless - this is obviously a bad approach and it would have been beneficial if we could access the content-type of the image directly.

The content-type itself, or what format the browser interpreted the request would both work for our purposes.