标签顺序直接决定首屏渲染速度：未加defer的会阻塞dom构建，会阻塞首次绘制，内联超14kb或preload错用as属性均延长白屏时间。
Head 里放错东西，页面就卡在白屏阶段——不是加载慢，是根本没开始渲染。
为什么
浏览器解析 HTML 是从上到下流式进行的。一旦遇到未加控制的 <script></script> 或阻塞型 <link rel="stylesheet">，就会暂停 DOM 构建，等资源下载、解析、执行完才继续。这意味着：哪怕你只在 顶部放了一个没加 defer 的 JS 文件，整个页面渲染都会被锁死。
-
<script></script>没加async或defer→ 阻塞解析，首屏延迟不可控 -
<link rel="stylesheet">加载慢或体积大 → 渲染线程等待 CSSOM 构建完成，白屏延长 - 多个
<link rel="preload">写错as类型（比如把font写成style）→ 浏览器忽略预加载，还可能触发重复请求 - 内联
<style></style>过大（超过 14KB）→ 延迟首次绘制（FCP），尤其影响移动端
关键 CSS 必须内联，但怎么判断“关键”
“关键 CSS”不是指所有用到的样式，而是首屏可见区域（above-the-fold）渲染所必需的那部分规则。它不包含折叠区、弹窗、懒加载模块的样式。
- 用工具提取：
critical（npm 包）或在线服务如 Sitelocity Critical Path CSS Generator，输入 URL 自动抓取首屏样式 - 手动验证：打开 DevTools → Network → 筛选
css→ 刷新 → 查看哪些样式表在DOMContentLoaded前已加载并生效；再对比 Elements 面板中首屏元素实际用到的规则 - 上线前必须压缩：内联 CSS 要过
cssnano或csso，删空格、注释、冗余选择器；否则体积膨胀抵消内联收益 - 体积红线：控制在 14KB 以内（gzip 前），否则 Chrome 会认为它“太大”，延迟渲染
preload 和 prefetch 别混用，写错就失效
preload 是告诉浏览器“这个资源马上就要用”，必须配合正确的 as 值；prefetch 是“以后可能用”，优先级极低，别指望它加速首屏。
- 字体必须写
as="font"并加crossorigin属性：<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin> - CSS 关键文件用
preload，但紧接着要跟一个普通<link rel="stylesheet">，否则样式不会应用 - 不要对 JS 文件用
preload后又不执行——它只是下载，不解析不执行；想提前加载并执行，用defer更稳妥 -
prefetch只适合下一页资源（如用户大概率点击的详情页 JS），别放在首页里抢带宽
第三方脚本必须沙箱化 + 延迟加载
统计、广告、客服 SDK 这类脚本几乎都带阻塞风险，且无法控制其内部逻辑。不能靠信任，只能靠隔离。
- 一律用
<script async defer></script>，禁用无属性直引；即使文档说“支持异步”，也要亲自验证是否真不阻塞 - 用
iframe加载非核心第三方内容（如评论框、嵌入视频），并设置sandbox属性限制权限 - 动态插入脚本更可控：
const script = document.createElement('script'); script.src = '...'; document.head.appendChild(script);，可结合用户交互或滚动位置触发 - 检查
document.write：任何第三方脚本含此调用，会清空整个 DOM，必须拒绝接入或找替代方案
Head 优化不是堆技巧，是做减法和定优先级。最常被忽略的是：内联 CSS 体积失控、preload 写错类型、第三方脚本没做异步兜底——这三处出问题，其他优化全白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
