Super slow preflight OPTIONS in Chrome only

Question

I\'ve been struggling recently with a super-weird problem only happening in Chrome: as my API (NodeJS) is on a different subdomain, I need to use CORS to reach it from my front-

Answer 1

Just as a note: It seems a chrome bug

I reproduced the issue using a server with two DNS names using a service in a unique domain

https://domain1.com  --> https://domain1.com (No CORS, no delay)
https://domain2.com  --> https://domain1.com (CORS, delay)

It is exactly the same service responding to two names, so I am testing exactly the same request, client and server code (DNS names are interchangeable)

Tested with

• Chrome 61.0.3163.100 (Windows) -->DELAY
• Chrome 62.0.3202.84 (Android) -->DELAY
• Chrome 62.0.3202.84 (iOS-Ipad) -->OK!!!
• Firefox-->OK
• Edge --> OK

Workaround (in my case). Create a proxy in my host to respond to the same origin DNS and avoid CORS

Answer 2

I've been seeking to debug this and it appears to be a chrome bug as we were experiencing the same issue.

For reference, I've filed a bug report to chromium here: CORS pre-flight and subsequent requests are very slow only on Chrome

I'm adding this here to help stop any more developers spending half a day investigating it ;) Will update as we here more from Chromium.

Overview of bug report follows:

UserAgent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:

1. Have app.domain.com
2. List item
3. Have api.domain.com
4. Enable CORS on API to enable access
5. Check responses in DevTools, see OPTIONS and GET requests are taking up to 300ms+

What is the expected behavior?

Response timings should be accurate.

What went wrong?

We are using Go microservices and noticed a big disparity in the time taken between browsers - chrome being the slowest up to a magnitude of 100x.

when we have checked the timings from the backend, responses take at most 10ms, with most being sub 1ms. When checking the timing under devtools the same responses were coming in at ~100ms~1s.

Did this work before?

N/A

Chrome version: 63.0.3239.132 Channel: stable OS Version: 10.0 Flash Version:

In Firefox (and any other browser), the exact same requests return in ~1-20ms as expected.

In trying to diagnose further, we used Telerik's Fiddler to check the actual network response times and confirmed that they were being sent and received by Chrome within our expected timings. The only conclusion we could come to is that something internal to Chrome is slowing the processing of these requests down.

We tried all permutations of chrome://flags#out-of-blink-cors and chrome://flags#enable-site-per-process, which are the two options which we spotted which seem vaguely relevant. Nothing seemed to help.

We have also found many Stack Overflow articles about a similar issues that make mention of it being a Chrome bug, but I haven't been able to find it reported here:

• Super slow preflight OPTIONS in Chrome only
• https://github.com/corydolphin/flask-cors/issues/147
• Slow cors preflight OPTIONS Request in Chrome

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

Chrome:

Edge:

Firefox:

Answer 3

I found the solution for my case and I will share it here.

I am on Windows, using Chrome version 70, runing a AngularJS front-end with a nodeJS backend with restify on the same server. I am using fiddler to monitor the requests, and OPTIONS request can take 1 second some times, while some times just < 5 ms. Stop using Filler bring that maximum time down to 300 ms, but still considered long. And this delay happens in Chrome, but not in Firefox. I did not test other browsers.

My case might be different from the question, as I looked the Chrome network timeline, when Fiddler is present, there is a 1s waiting(TTFB) delay. And when Fiddler is not on, there is a 300 ms gap between DNA lookup and initial connection.

I finally found this AJAX query weird delay between DNS lookup and initial connection on Chrome but not FF, what is it?

Just change back-end connection URL from localhost to 127.0.0.1 and It solved my problem perfectly.