竖屏首屏加载慢的主因是响应式CSS被同步阻塞，而非媒体查询本身；应通过media属性（如min-width:768px）延迟非关键CSS解析，或用JS动态加载mobile.css以彻底移出关键路径。
为什么竖屏下首屏仍被CSS阻塞
竖屏设备（如手机）加载慢，往往不是因为写了 @media (max-width: 767px)，而是关键路径上混入了本不该同步加载的响应式 CSS。浏览器对所有 <link rel="stylesheet"> 默认视为渲染阻塞资源，哪怕它只在桌面端生效——只要 HTML 解析时看到它，就会暂停首屏渲染，直到该文件下载并解析完成。
常见错觉是：“我只在 mobile.css 里写竖屏样式，所以它只影响竖屏”。实际上：mobile.css 在桌面端也会被预加载（Chrome Network 面板可见），而在竖屏下，如果它体积大、服务器响应慢，或与 base.css 存在依赖顺序问题，就会直接拖慢 FOCP（First Contentful Paint）。
如何确认非关键 CSS 正在阻塞首屏
打开 Chrome DevTools → Network 面板 → 刷新页面 → 筛选 css 类型，重点关注以下信号：
- 某个 CSS 文件（如
desktop.css或print.css）状态码是200但耗时长，且出现在DOMContentLoaded之前 - 该文件的
Initiator显示为parser（说明被 HTML parser 主动抓取，而非 JS 动态插入） - Coverage 面板显示该文件中大量规则在首屏未命中（
Unused bytes占比 >60%） - 控制台出现警告：「
The resource from “xxx.css” was blocked due to MIME type mismatch」——这说明即使没加载成功，浏览器也已为其预留阻塞时机
用 media 属性延迟非关键 CSS 的真实效果
media 属性不能阻止下载，但能阻止解析和应用，从而解除渲染阻塞。前提是 media 值必须有效且不匹配当前环境。
立即学习“前端免费学习笔记（深入）”；
例如在竖屏手机上：
-
<link rel="stylesheet" href="desktop.css" media="(min-width: 768px)">→ 不解析、不阻塞，但文件仍会预加载（可接受） -
<link rel="stylesheet" href="print.css" media="print">→ 完全不触发下载（Chrome/Edge/Firefox 均支持） -
<link rel="stylesheet" href="legacy.css" media="not all">→ 语法无效，浏览器忽略该标签，样式彻底丢失 -
<link rel="stylesheet" href="theme-dark.css" media="(prefers-color-scheme: dark)">→ 竖屏若系统设为亮色，则不解析
⚠️ 注意：media 值一旦拼错（如 max-wdith）、或写成 screen and (orientation: portrait) 这类始终为真的表达式，就等同于没加——照样阻塞。
真正只加载竖屏所需 CSS 的可行方案
如果 mobile.css 本身很大（>50KB），或你明确知道用户 99% 是竖屏访问，那靠 media 预加载仍不够。必须绕过 HTML parser，改用 JS 控制加载时机：
- 在
中先放一个空的<style id="placeholder"></style>，提供最小骨架样式（如字体、行高、基础间距） - 用
window.matchMedia("(orientation: portrait)").matches立即判断 - 匹配成功后，动态创建
link并设置rel="stylesheet"和href，插入到 - 监听
matchMedia().addEventListener("change")处理横竖屏切换，但仅用于深色模式等低频场景，避免频繁重排
这个方式下，mobile.css 不会在 HTML 解析阶段被发现，彻底退出关键渲染路径。但要注意：IE 不支持 link.onload，需降级用 onreadystatechange；且首次加载延迟约 1–2 个任务队列周期，务必内联足够多的首屏 Critical CSS 来填补空白。
最易被忽略的一点：无论用哪种方式，base.css 必须包含所有断点共用的基础规则（重置、字体族、盒模型、常用工具类）。否则拆分后，竖屏下可能连按钮边框都出不来。
