<script>和<link rel="stylesheet">会直接卡住渲染树生成：前者阻塞HTML解析并同步执行，后者阻塞JS执行和渲染树合成；内联<style>过大（>4KB）也会拖慢解析。
HTML模板里哪些标签会直接卡住渲染树生成
不是所有标签都一样重。浏览器在构建 DOM 树时，<script> 和 <link rel="stylesheet"> 是唯二能主动中断解析流程的标签——前者暂停 HTML 解析并立即执行，后者虽不阻塞解析，但会阻塞后续 JS 执行和渲染树合成。
常见错误现象：首屏白屏超过 1s，DevTools 的 Network 面板显示 CSS 文件加载慢，而 Performance 面板中 Layout 阶段长时间等待 “CSSOM ready”。
-
<script>放在<head>且没加defer或async：DOM 构建完全停住，哪怕脚本只做 console.log -
<link rel="stylesheet">指向未压缩、未分片的巨型 CSS 文件：CSSOM 构建耗时飙升，尤其含大量@import或深层嵌套选择器 - 模板中混用
<style>内联块 + 外部<link>：内联样式虽快，但若体积过大（>4KB），反而拖慢 TTFB 后的解析速度
如何让 HTML 模板不成为 DOM 深度炸弹
模板引擎（如 EJS、Handlebars）或 SSR 框架（Next.js、Nuxt）默认生成的 wrapper 层，是真实项目里 DOM 深度超 6 层的主因。深度不是语义问题，是布局计算成本问题——Chrome Layout 阶段可直接观测到每 +1 层深度带来 20–40% 耗时增长。
使用场景：卡片列表、表单组、响应式栅格容器，最容易堆出 <div class="container"><div class="row"><div class="col"><div class="card">…</div></div></div></div> 这类结构。
立即学习“前端免费学习笔记（深入）”；
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- 把
class="row"/class="col"对应的布局逻辑，全交给display: grid或flex实现，DOM 层级压到 1–2 层 - 避免为“视觉间距”硬加
<div class="spacer">，改用margin或gap - SSR 模板中禁用自动包裹（如 Next.js 的
<div id="__next">已足够，别再套<main><section><div class="wrapper">） - 用 Chrome DevTools → Elements 面板右键节点 → “Show DOM Tree Depth”（需开启 Rendering → Paint flashing）验证真实深度
preload 在 HTML 模板里写错 as 值的后果
<link rel="preload"> 不是下载开关，而是用途声明。写错 as 值，等于告诉浏览器“这个资源该这么用”，但它实际没法这么用——结果就是请求发了，资源下了，却进不了 CSSOM、不触发字体加载、不参与渲染树合成。
典型错误现象：页面用了自定义字体，但始终 fallback 到系统字体；预加载的 chart.js 在 await import() 时仍要等网络请求。
-
as="font"必须配crossorigin（即使字体同源）：否则字体二进制数据不会注入字体表，@font-face规则无效 -
as="style"仅适用于你后续用 JS 动态插入的 CSS；若同时存在<link rel="stylesheet">，浏览器会发两次请求 -
as="image"对<img>的src无效——它只对<link>生效，且必须匹配实际 MIME 类型（webp不能写as="jpeg"） - 首屏 Hero 图用
<img src="hero.webp">，就别 preload 它；真正该 preload 的是紧随其后、但解析器还没扫到的critical.css或Inter.woff2
服务端模板中内联 critical CSS 的实操边界
内联 CSS 能跳过一次网络请求，但前提是它真“关键”。内联整站 CSS 或打包后的 main.css，只会让 HTML 变大、TTFB 延长、缓存失效——得不偿失。
性能影响：内联体积每增加 1KB，移动端首字节后解析延迟约 3–5ms；若超过 15KB，可能反超一次 HTTP/2 请求的收益。
- 只提取渲染首屏 DOM 节点必需的规则：用
PurgeCSS+html模板路径扫描，或手写critical.css并定期回归 - 内联后必须压缩：删空格、去注释、合并重复声明；Vite/webpack 的
html-minifier-terser插件可自动处理 - 带
media属性的内联<style>仍会被解析（只是不生效），所以<style media="(min-width: 1024px)">在手机上也浪费 CPU - SSR 模板中，内联 CSS 应放在
<head>最顶部，确保解析器第一时间拿到样式，而非被<script>或<meta>挤到后面
复杂点在于：critical CSS 的范围会随首屏内容动态变化（比如登录态 vs 游客态），静态模板很难覆盖全部路径；更稳的做法是服务端根据 UA + 路由动态生成内联块，而不是写死在模板里。
