Adding HTTP method to ResourceTiming API structure

[sohomdatta1]

The ResourceTiming API structure doesn't currently give us insight into what HTTP method was used to fetch a specific resource and/or make a API call. It would be great if the HTTP method used to make a specific HTTP request could be added to the ResourceTiming structure.

The major usecase where I see this getting used (and from where this idea came from) is to debug cases where a POST request would have additional latency/overhead over a GET request or vice-versa.

[yoavweiss]

^^ @nicjansma

[clelland]

Let's add this to the agenda for the WG for discussion this week

[nicjansma]

Yes this seems very useful for being able to segment the performance of URLs that are used with different methods. REST APIs come to mind here.

[nicjansma]

For posterity, we had discussed this on the April 13th, 2023 W3C WebPerf Working Group call.

Notes @ https://docs.google.com/document/d/1fIgfd7ONz-sES55qRFHQI_eQUnynnyX2Asrs-cwAQ_Q/edit#heading=h.nuc3bt9j96hk

Summary:

• Useful to know whether a HTTP request was a GET/POST/etc from ResourceTiming, as they may have different performance characteristics
• Question if this would be covered by CORS, or would need another opt-in
• Next steps: Getting a security review from security folks at each vendor

[meetsuraj]

Any updates on this?

[drit]

@nicjansma has it been reviews by the security teams of the involved vendors? I am not sure how this can be a security issue given browser extensions already allow for this.

[nicjansma]

@drit I can follow-up with the browser dev teams to see if there have been any progress on reviewing this.

Unfortunately data available in developer tools and browser extensions (i.e. on your own machine) is not the same scope as being available to JavaScript (i.e. on everyone's machine). There is a lot of data available to you, a developer, while using DevTools that could never be exposed to JavaScript (where anyone could read it). We need to pay close attention to any new bits of information available to JavaScript and the world.

[ErikWitt]

We have another use case to consider:

Navigation requests (i.e. page loads) can also be triggered by GET or POST requests. While GET is the most common case, we also see POST navigations requests especially on e-commerce pages (e.g. when adding something to cart). This site would be an example for this.

In our experience the performance of GET and POST navigations can be drastically different. Especially when HTML caching comes into play (since GET can be cached while POST usually not).

Therefore it would be great to be able to separate GET and POST navigation in real user monitoring (RUM) tracking.

Adding the method to navigations timings could be nice way to achieve that