html解析被阻塞主因是css和js加载顺序不当：link样式表会暂停html解析直至cssom构建完成，同步脚本则阻塞dom构建；应善用media属性异步加载非关键css、defer保序执行关键js，并避免document.write。
HTML解析被阻塞，八成不是因为HTML本身大，而是CSS和JS资源加载顺序不当触发了浏览器的渲染线程锁死。关键不在“怎么写得更短”，而在“让浏览器别卡在半路”。
为什么放在里会卡住DOM构建
浏览器遇到 <link rel="stylesheet" href="main.css"> 时，会立即发起请求，并**暂停HTML解析器**，直到该CSS下载完成、解析出CSSOM，才继续构建DOM树——哪怕样式只用在页脚。这不是“慢”，是“强制等待”。
- 真实影响：一个未压缩的 180KB
main.css在 3G 网络下可能耗时 600ms，期间标签都还没被解析到 - 常见误操作：把所有CSS合并成一个文件丢进
，以为“减少请求数”就赢了，结果首屏白屏时间翻倍 - 兼容性注意：Firefox 会直接阻塞所有脚本；WebKit（Safari/Chrome）则按需阻塞——但只要JS里调用了
getComputedStyle()或offsetHeight，照样卡住
media 属性如何让非关键 CSS “不阻塞”
给 <link> 加上 media 属性（如 media="(min-width: 1024px)"），浏览器就会把它标记为“条件加载”，**异步获取、不参与阻塞链**，直到媒体查询匹配才应用。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 适用场景：
print.css、dark-theme.css、后台管理页专属样式等首屏无关的CSS - 必须避开的坑：
media="screen"和不写media效果一样，都会阻塞；media="all"同理 - 进阶技巧：对必须动态加载的模块CSS（如弹窗组件），可用
media="(min-width: 0px) and (max-width: 0px)"占位，后续用JS切换为"all"，但要注意避免FOUC
defer 脚本为何比 async 更适合业务主逻辑
async 脚本下载时不阻塞，但执行时机不可控——可能在 DOM 还没建完时就跑，也可能在 DOMContentLoaded 之后；而 defer 保证执行时机在 DOM 构建完成后、DOMContentLoaded 事件触发前，且严格按书写顺序执行。
- 典型错误：
<script src="vue.js" defer></script>+<script src="app.js" defer></script>，但app.js依赖vue.js—— 没问题，defer 保序 - 绝对禁用：
document.write()，现代浏览器执行即清空整个文档流，本地双击打开时尤其致命 - 兜底方案：同步脚本（无属性）必须移出
，放到前——这是最朴素、最可靠的 fallback
preload 关键 CSS 的正确姿势
<link rel="preload"> 不是“提前加载所有CSS”的开关，它只对**当前导航中确定马上要用**的资源有效。滥用反而挤占带宽，拖慢真正关键的资源。
- 推荐用法：
<link rel="preload" href="critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">，配合内联关键CSS使用 - 必须显式声明
as="style"，否则浏览器不会提升优先级，甚至可能当成普通 fetch - 不要 preload 非关键CSS（如主题切换、打印样式），它们不该抢占首屏带宽
真正卡住页面的，往往不是体积，而是浏览器对资源依赖关系的判断逻辑。看清哪一步在等哪一步，比压缩几个KB更管用。特别是 media 和 defer 这类原生能力，零成本、高兼容，但容易被当成“可选优化”跳过——其实它们才是首屏加载的底层开关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
