浏览器对同一域名并发请求限制通常为6个，关键资源需通过域名拆分、preconnect预连接、异步加载CSS等手段“插队”抢占前6席，而非仅依赖defer或减少请求数。
浏览器对同一域名的并发请求数有限制（通常是6个），当 HTML 解析过程中遇到大量 、<script></script> 或
为什么加了 defer 还卡在解析阶段？
因为 defer 只影响脚本执行时机，不改变下载排队顺序。HTML 解析器遇到 <script src="a.js"></script> 就立刻发起请求，哪怕它后面跟着 5 个 CSS 文件，全部挤在同一个域名下，a.js 下载完成前，第 7 个资源（比如 logo.png）根本拿不到 TCP 连接。
- Chrome/Firefox 对同源 HTTP/1.1 域名默认最多 6 个并发连接；HTTP/2 虽支持多路复用，但若服务端未启用或客户端不支持，仍退化为 HTTP/1.1 行为
-
可以提升优先级，但不会绕过连接池限制；它只是告诉浏览器“这个资源我马上要”，提前触发 DNS/TCP/SSL，不解决排队本身 - 内联
和<script></script>不占并发名额，但体积过大（>2KB）会拖慢 HTML 解析器本身的 tokenization 阶段
如何把关键资源“插队”进前 6 名？
核心思路是拆分域名、预热连接、控制加载节奏，而不是等浏览器自己排完队再干活。
- 将非首屏资源（如统计 JS、第三方字体、埋点 SDK）迁移到独立子域名，例如
stats.example.com、fonts.example.com——每个新域名带来额外 6 个并发连接额度 - 在
里加，提前建立 DNS+TCP+TLS 连接，避免首次请求时的握手延迟 - 对必须同源的关键 CSS，用
异步加载，不参与初始阻塞队列 - 避免在
里堆砌多个：合并成一个文件，或用@import（更差）——后者是串行阻塞，比并行排队还慢
本地开发时 Network 面板看到 TTFB >100ms，一定是后端问题？
不一定。file:// 协议下，浏览器对相对路径（如 ./css/app.css）的解析本身就有延迟，尤其当目录层级深、存在符号链接或中文路径时，TTFB 显示偏高，但实际不是网络问题。
- 用
python3 -m http.server 8000启一个本地服务器，TTFB 应降到 - Network 面板中右键某个资源 →
Block request URL，屏蔽掉疑似拖慢的非关键 JS（如客服 widget），刷新看 DOMContentLoaded 是否提前 —— 这比猜快得多 - 检查所有
src/href是否含多余空格或不可见 Unicode 字符（比如零宽空格），这类错误会导致静默 404，反复重试占用连接槽位
真正难处理的是那些“看起来正常却悄悄吃掉连接”的资源：比如一个被遗忘的 
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
