只是一个注解：这似乎是一个Chrome错误
我重现了这个问题使用一个服务器与两个DNS名称使用服务在一个独特的域名

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

这是完全相同的服务响应两个名称，所以我测试完全相同的请求，客户端和服务器代码（DNS名称是可互换的）
测试与

• Chrome 61.0.3163.100（Windows）-->延迟
• Chrome 62.0.3202.84（Android）-->延迟
• Chrome 62.0.3202.84（iOS-Ipad）-->OK！！！
• Firefox-->OK
• 边缘-->确定
  解决办法（在我的情况下）。在我的主机中创建一个代理以响应同源DNS并避免CORS

我一直在寻求调试这个和它似乎是一个Chrome错误，因为我们遇到了同样的问题。
作为参考，我在这里提交了一份关于chromium的bug报告：CORS pre-flight and subsequent requests are very slow only on Chrome
我在这里添加这一点是为了帮助阻止更多的开发人员花费半天的时间来调查它;）将更新，因为我们在这里更多的 chrome 。
错误报告概述如下：

UserAgent：

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

重现问题步骤：

1.有app.domain.com
1.列表项
1.有api.domain.com
1.在API上启用CORS以启用访问
1.检查DevTools中的响应，请参见OPTIONS和GET请求占用时间长达300 ms +

什么是预期的行为？

响应时间应该准确。

出了什么问题？

我们正在使用Go微服务，并注意到浏览器之间的时间差异很大- Chrome是最慢的，高达100倍。
当我们从后端检查计时时，响应最多需要10 ms，大多数是sub1 ms。当在devtools下检查定时时，相同的响应在~ 100 ms ~ 1 s时到达。
”””这是以前的工作吗？**
N/A
Chrome版本：63.0.3239.132通道：稳定操作系统版本：10.0 Flash版本：
在Firefox（和任何其他浏览器）中，完全相同的请求在预期的1- 20 ms内返回。
为了进一步诊断，我们使用Telerik的Fiddler来检查实际的网络响应时间，并确认Chrome在我们预期的时间内发送和接收了它们。我们能得出的唯一结论是，Chrome内部的某些东西正在减慢这些请求的处理速度。
我们尝试了chrome://flags#out-of-blink-cors和chrome://flags#enable-site-per-process的所有排列，这是我们发现的两个似乎模糊相关的选项。似乎没有什么帮助。
我们还发现了许多关于Stack Overflow的文章，这些文章提到了类似的问题，但我没有在这里找到报告：

• 仅Chrome中的超慢飞行前选项
• https://github.com/corydolphin/flask-cors/issues/147
• Slow cors preflight OPTIONS Request in Chrome

我们刚刚在MacOS上测试了Chrome，这似乎不是一个问题-所以可能仅限于Windows。
Chrome：

边：

x 1c 3d 1x
Firefox：

我找到了我的解决方案，我将在这里分享。
我在Windows上，使用Chrome版本70，在同一台服务器上运行AngularJS前端和nodeJS后端。我使用fiddler来监视请求，OPTIONS请求有时需要1秒，而有时只需< 5毫秒。停止使用填充器将最大时间降低到300 ms，但仍被视为较长。这种延迟发生在Chrome中，而不是Firefox中。我没有测试其他浏览器。
我的情况可能与问题不同，因为我看了Chrome网络时间轴，当Fiddler存在时，有1秒等待（TTFB）延迟。当Fiddler未打开时，DNA查找和初始连接之间有300毫秒的间隙。
终于找到了AJAX query weird delay between DNS lookup and initial connection on Chrome but not FF, what is it?
只要把后端连接地址从localhost改为127.0.0.1，就完美解决了我的问题。

老文章，但这是一个比大多数这些答案暗示的更深层次的问题，可以影响任何人。这篇文章https://www.wpeform.io/blog/handle-cors-preflight-php-wordpress/极大地帮助我理解和缓解了这个问题。
OPTIONS请求需要作为每个URL的Web规范的一部分。这使得缓存粉碎请求非常容易发生，只需更改URL即可。此外，确保您的请求检测OPTIONS请求并且不做太多处理（例如：从数据库中加载大量内容等）。