link rel="stylesheet"的网络耗时来自PerformanceResourceTiming中domainLookupEnd−domainLookupStart（DNS）、connectEnd−connectStart（TCP+TLS）、responseStart−requestStart（TTFB）、responseEnd−responseStart（下载）等阶段差值，需在load事件后调用performance.getEntriesByType("resource")并按initiatorType==="link"和name.endsWith(".css")筛选。
link rel="stylesheet" 的网络耗时从哪来
浏览器对 <link rel="stylesheet"> 的处理不是“发个请求就完事”，它包含多个可测量但常被忽略的阶段：DNS 查询、TCP 连接、TLS 握手（HTTPS）、HTTP 请求发送、服务器响应、资源下载完成（responseEnd），最后才是 CSS 解析与应用。其中前四项（DNS+TCP+TLS+Request）统称「网络开销」，在弱网或高延迟 CDN 下可能占总耗时 30%–70%。
常见错误现象：network 面板里看到 200 OK 很快，但 LCP 或 FOUC 依然明显 → 实际是解析/应用阶段卡住，不是网络慢；反过来，若 responseEnd 比 fetchStart 晚 800ms 以上，大概率是网络链路问题，而非 CSS 本身。
- 路径写成相对路径（如
./css/main.css）且 HTML 在子目录（如/blog/post.html）下，会导致 404 后重试，responseEnd延迟不可控 - 没配
crossorigin却加载跨域字体或图标字体，浏览器会静默降级为匿名模式，部分字段（如transferSize）返回 0，误判为“没走网络” - HTTP/2 下多个
<link rel="stylesheet">仍会串行解析（非串行下载），后加载的 CSS 规则即使体积小，也可能因等待前一个解析完成而延迟生效
如何用 performance.getEntriesByType('resource') 看真实耗时
必须等 document.readyState === 'complete' 或监听 window.addEventListener('load', ...) 后再调用，否则 <link> 对应的 PerformanceResourceTiming 条目可能还没入库——尤其在 CSS 文件较大或网络较慢时，getEntriesByType('resource') 会漏掉首屏关键样式条目。
过滤时别只看 name 字段匹配 href：动态插入的 <link> 和内联 <style> 都不会出现在该列表中；而通过 JS 创建的 <link rel="stylesheet"> 会进列表，但 initiatorType 是 script 而非 link。
立即学习“前端免费学习笔记（深入）”；
- 正确过滤示例：
const entries = performance.getEntriesByType('resource'); const cssEntries = entries.filter(e => e.initiatorType === 'link' && e.name.endsWith('.css') && e.duration > 0 ); - 跨域资源必须同时满足：
<link crossorigin>+ CDN 响应头含Access-Control-Allow-Origin: *，否则duration、encodedBodySize全为 0 - 不要依赖
startTime做绝对时间比对：它的起点是navigationStart，但若页面有重定向，这个值可能失真；推荐用fetchStart到responseEnd的差值
为什么 onload 回调触发时间 ≠ 样式生效时间
<link rel="stylesheet" onload="..."> 的 onload 事件只表示资源已下载并解析完毕，**不保证样式已应用到 DOM**。浏览器可能仍在执行层叠计算、重排或等待其他样式表（比如后面还有另一个 <link>）——尤其当页面存在大量高权重选择器或 @import 时。
- 典型表现：onload 执行了，但
getComputedStyle(document.body).backgroundColor仍是默认值，要等requestAnimationFrame下一帧才变 - 如果用了
<link rel="preload" as="style" onload="this.rel='stylesheet'">，务必在 onload 里先清空this.onload = null，否则重复切换rel可能导致样式闪动或解析中断 - 禁用 JS 时，
onload不触发，但样式仍会加载——所以不能把关键样式逻辑全押在 onload 回调里
HTTP/2 下多个 link 标签是否还拖慢首屏
HTTP/2 多路复用确实消除了“连接数瓶颈”，但多个 <link rel="stylesheet"> 仍会实质性影响首屏性能，原因不在网络层，而在解析与渲染流水线：
- 每个
<link>加载的 CSS 都要单独解析 AST、构建规则树、匹配选择器——CPU 时间线性增长，低端设备上 3 个 200KB 的 CSS 文件可能比 1 个 600KB 文件多花 40% 解析时间 - 浏览器按 HTML 中出现顺序执行 CSS 解析，后加载的文件若含
!important或高特异性规则，会强制重算前面已应用的样式，引发额外 layout - 缓存粒度问题：拆成多个小文件后，改一行按钮颜色就得让全部 CSS 缓存失效；而合并后，只要没动基础 reset 部分，CDN 仍可复用大部分缓存
真正该拆分的，是「非首屏主题样式」或「打印专用样式」，用 media="print" 或 media="(min-width: 768px)" 控制加载时机，而不是靠数量堆叠。
