We've just tested Chrome on MacOS and it doesn't appear to be an issue - so may be limited to Windows.

Deleted: optionsEdge.PNG 80.4 KB

	optionsEdge.PNG 80.4 KB View Download

Deleted: getEdge.PNG 93.5 KB

	getEdge.PNG 93.5 KB View Download

I believe that issue by itself does not related to Chrome DevTools, forwarded to network.

I'm having a similar problem and I'm on Mac (using NodeJS as a back-end framework, EmberJS as a front-end framework)

Thank you for reporting.

Can you provide a netlog? https://dev.chromium.org/for-testers/providing-network-details

For visibility: I have emailed the netlog directly to @yhirano.

Thanks!

Thank you for providing more feedback. Adding requester "yhirano@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@yhirano: Are you investigating the netlog? Otherwise, can you link to the net internals with internal permissions, or set this bug to Restrict-View and upload it here, so someone on the Network team triage rotation can take a look.

For visibility: I have re-sent the netlog directly to @yhirano, @svaldez and @wangyix.

Thanks!

Thank you for providing more feedback. Adding requester "wangyix@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sorry for the delay. I haven't seen anything CORS specific from the log so far, so I appreciate Internals>Network eyes.

Attaching the NetLog file I received from matt@.

Given that the netlog was emailed in order to keep it private, can you please urgently remove (or make private) that attachment?

NetLog attachment removed. NetLog can be downloaded here:
https://drive.google.com/file/d/1OifTNnzljeDiMkwPAuf9VxKQAMO-uP0W/view?usp=sharing

Hmm, nothing really stuck out as taking way too long on the NetLog to me as it did on those waterfall screenshots... I wonder what exactly the "Content Received" portion of the waterfall is measuring.

That's a good question, morlovich@ - I don't think that the "Content Received" portion of the waterfall is so large because the request is slow, as everything else we've done to try to trace the issue shows the requests flying through just as quickly as for other browsers.

Is there any chance you can get somebody from the DevTools team to look at this again and shed some light on what exactly goes into "Content Received" (and perhaps tell us if there's anything we can do to help narrow down where the time is actually being spent, since the netlog wasn't much help there)?

Is it possible to provide a reduction or a test site demonstrating this? This would help further diagnostic triage as well as narrow down the reported platform differences  (from Comment #1)

assigning to yhirano@ so the issue doesn't keep popping up for triage

Quick ping for a reduction or test site which would help further debugging (as requested in comment #19).

Removing the Internals>Network label - requests in the log generally take under 80 milliseconds, with the majority of that either waiting to establish a connection or waiting on headers.  A couple are delayed by up to 30 milliseconds from the resource scheduler, but nothing going on that explains the log.  There are two 260 millisecond requests, but both of those were blocked for 180 milliseconds on headers (And 40 milliseconds on the renderer, to validate if the an initial redirect request should be followed).

None of this points to a network issue.

There have been no response from the reporter for two months.

I'm experiencing this problem too. If you're waiting for feedback or as described above a test site I could perhaps provide one if it means this would continue to be investigated? I've replicated this on a couple of machines (all mac os though), in private browsing, and on multiple websites.

Also still experiencing this problem. I can provide a test site.

Hi Team,

Sorry we haven't responded - we didn't want to clog up the ticket.

@paul.n has tried to reproduce the issue a couple of times, but we haven't been able to create a solid case. In our case we have a number of factors in play which has made it harder to deduce. Also, due to our development cycle frontend performance tuning is pegged in for a later date. 

If someone (@ben/@ood?) has a solid reproducible test case are you able to link it here please? Then we can all try to reproduce and report the results. :)

We are planning to replace all CORS-preflight implementation. So, I'm not sure if we should pay much attention to improve current implementation. But definitely, if we could have a simple test to check performance, it would be helpful.

toyoshim: Is there a design doc available for that to review?

Yes, here; https://docs.google.com/document/d/1JNmUcvbw2UcjfdI2uyUpveHXCbae-DQ1n8d_sVs5fLg/edit?usp=sharing

New CORS-preflight implementation is already in //services/network/cors.

I'll appreciate a reproducible test case.

I can confirm this behavior. We're seeing, in some cases, an extra 6 seconds to resolve an OPTIONS request. This is not present in any other browser or HTTP client.

> We are planning to replace all CORS-preflight implementation. So, I'm not sure if we should pay much attention to improve current implementation.

Frankly, this is a careless response, especially for a project that so many companies depend on. Our application's performance was reduced by 120X, which has a meaningful impact to our business. I truly do not understand the lack of urgency for something that is so easily reproducible and wide spread.

I'll appreciate a reproducible test case.

Unable to reproduce.