Chrome因并发请求数卡住Parse HTML的典型表现是：Performance面板中Parse HTML蓝条悬停超100ms，同时Network面板出现多个同域名请求处于Queued或Stalled状态（>50ms），且均指向同一host（如cdn.example.com）。
怎么看 Chrome 是否因并发请求数卡住 Parse HTML
Chrome 对同一域名的并发 HTTP/1.1 请求默认限制为 6 个，超出的资源会排队等待，如果排队的是关键脚本或 CSS，就会让 Parse HTML 在中途暂停——不是脚本执行慢，而是它根本还没下载完。打开 DevTools → Performance 面板录制加载，重点看 Parse HTML 蓝条是否在某处突然“悬停”超过 100ms，同时 Network 面板里有多个请求处于 Queued 或 Stalled 状态，且它们都指向同一个域名（比如 cdn.example.com），这就是并发瓶颈的典型信号。
哪些资源最容易触发域名级并发阻塞
外链 JS、CSS、字体、SVG Sprite、甚至 <img src="https://cdn.example.com/logo.png"> 都算。只要它们 host 相同，就共享那 6 个 slot。特别容易被忽略的是：第三方统计、客服 SDK、CDN 上的图标字体（@font-face src: url(//cdn.example.com/icon.woff2)）——它们和你自己的 JS/CSS 混在同一个域名下，悄悄吃掉并发额度。
- 用
chrome://net-internals/#http2查当前连接是否已升到 HTTP/2（HTTP/2 无此限制，但需服务端支持） - 把非关键资源（如埋点、广告、非首屏图片）换到子域名，比如
stats.example.com、img2.example.com - 避免把所有静态资源都扔进
static.example.com——看似统一，实则自建瓶颈
为什么本地 file:// 下看不出这个问题
因为 file:// 协议不走网络栈，没有 DNS、没有 TCP 连接、更没有并发限制——所有资源“瞬间”可读。但这恰恰掩盖了线上真实瓶颈。你在本地双击打开时一切飞快，一上 Nginx 就卡顿，大概率就是这个原因。必须用 http://localhost（比如 python3 -m http.server）复现，才能看到真实的排队行为。
- Network 面板中，
Stalled时间 > 50ms 且集中在同一域名 → 并发饱和 -
Waterfall里多个请求起始时间相差几秒，但发起时间几乎一致 → 排队等待 - 把某个
script改成async后反而更慢？可能是它抢到了 slot，把真正关键的 CSS 挤到了后面
怎么验证改域名真能缓解解析停顿
最直接的方法是临时修改一个非关键资源的域名，观察 Parse HTML 是否不再悬停。比如把 <link rel="stylesheet" href="https://cdn.example.com/extra.css"> 改成 https://cdn2.example.com/extra.css（哪怕只是 CNAME 到同一台机器），再录一次 Performance。如果原来卡在 800ms 的蓝条现在平滑跑到 300ms，说明并发确实是瓶颈。注意：别动关键 CSS 和首屏 JS，否则可能引发 FOUC 或白屏。
立即学习“前端免费学习笔记（深入）”；
- 改域名前先确认 DNS 解析正常，
dig cdn2.example.com不能超时 - 不要用
127.0.0.1或localhost做子域名，浏览器会把它和主站归为同一源，不释放 slot - HTTP/2 服务端开启后，单域名并发不再是问题，但得确保 TLS 配置正确，否则 fallback 到 HTTP/1.1
cdn.example.com 下，悄无声息地占满 6 个 slot，导致紧随其后的 app.js 等了 2 秒才开始下载。 
