现代浏览器对单域名并发HTTP/1.1请求限制为6～8个，超量请求会排队导致解析卡顿；应通过多子域托管、避免@import、内联关键CSS、异步加载第三方脚本及慎用loading="lazy"优化。
浏览器对同一域名的并发请求数有硬限制
现代浏览器对单个域名的并发 HTTP/1.1 请求通常限制在 6～8 个。当 HTML 中密集引用了大量同源资源（比如 20 个 img、5 个 script、3 个 link[rel="stylesheet"]），超出的部分会被挂起排队，造成解析“看似卡住”——实际是等待空闲连接，而非 JS 或 CSS 阻塞。
这种停顿在 Network 面板中表现为：多个请求的 Waterfall 起始时间明显错开，且状态栏显示 queued 或 stalled，TTFB 正常但下载延迟高。
- 优先将静态资源（图片、字体、CSS、JS）托管到至少 2 个子域名下，例如
static1.example.com和static2.example.com，绕过单域名连接池瓶颈 - 避免把所有
src都写成./assets/...——构建时用工具（如 Webpack 的publicPath或 Vite 的base）自动分发到不同 origin - 慎用
preload：它会抢占连接池，若 preload 了 5 个非首屏资源，可能把关键 CSS 的请求挤到第 7 位，反而延长 FCP - HTTP/2 或 HTTP/3 环境下该限制基本失效，但需确认服务端真正启用了协议（
curl -I https://yoursite.com查看HTTP/2响应头），否则仍走 HTTP/1.1
script 和 link 标签顺序引发的隐式串行阻塞
即使没超并发数，HTML 解析也会因标签语义被强制串行。典型场景：link[rel="stylesheet"] 后紧跟 script，哪怕 script 加了 defer，浏览器仍会等样式表下载完成才开始下载该 script——这是规范要求，不是 bug。
更隐蔽的是 @import：它在 CSS 文件内部触发新请求，且必须等导入完成才能继续解析后续 CSS 规则，形成“CSS → @import → CSS”三级串行链。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 把所有
script移到</body>前，或统一加defer；确保它们不紧挨在link[rel="stylesheet"]后面 - 彻底删除 CSS 文件中的
@import，改用构建时内联或生成多<link>标签并行加载 - 关键 CSS 必须内联在
<head>中，非关键 CSS 用<link rel="stylesheet" media="print" onload="this.media='all'">异步加载，切断阻塞链 - 第三方脚本（如统计、客服）务必用
async，并从 HTML 源码中剥离，改用动态插入：const s = document.createElement('script'); s.src = '...'; s.async = true; document.head.appendChild(s);
图片懒加载与 loading="lazy" 的触发时机陷阱
loading="lazy" 不是“不加载”，而是由 IntersectionObserver 内部机制控制加载时机，默认触发距离是视口下方约 1250px。如果页面滚动极快，或用户直接跳转到页尾，部分 img 可能长期处于 pending 状态，占用连接却未真正发起请求，间接加剧其他资源排队。
尤其在移动端 WebView 或旧版 Safari 中，loading="lazy" 可能被完全忽略，导致本该懒加载的图片全量发起请求，瞬间打满并发连接。
- 首屏关键图片（
.hero img、.logo、按钮图标）绝对禁用loading="lazy"，且显式设置width和height - 对
loading="lazy"失效风险高的环境（如 iOS data-src + 手动IntersectionObserver控制，确保加载可控 - 避免在同一个容器里混用
loading="lazy"和同步src图片——浏览器可能因布局重排反复触发懒加载逻辑，浪费连接 - 大图优先用
decoding="async"，防止解码阻塞主线程，间接缓解渲染线程对网络线程的干扰
本地开发时 file:// 协议放大并发问题
双击打开 HTML 文件走 file:// 协议时，浏览器会禁用大部分优化机制：无 HTTP 缓存头、无 gzip/Brotli 压缩、跨域请求被拦截、甚至某些现代 API（如 fetch() 读取本地 JSON）直接失败。更关键的是，file:// 下并发请求行为不可靠——Chrome 可能限制为 1～2 个连接，导致 10 张图片排队加载，白屏长达数秒。
这不是代码问题，是协议限制。任何基于 file:// 的性能测试都无效。
- 本地开发必须用轻量服务器，如
npx serve、python3 -m http.server 8000或 VS Code Live Server 插件 - 检查 Network 面板中所有请求的 Protocol 列，确认是
http/1.1或h2，而非(blocked)或file - 若必须离线交付（如电子手册），把所有资源内联：CSS 用
<style>、JS 用<script>、小图用data:URI，彻底规避请求并发问题 - 用
curl -w '@format.txt' -o /dev/null -s http://localhost:8000/index.html验证 TTFB 是否稳定在
stalled 条，比压缩 1KB HTML 更管用。 
