渐进式渲染效果好不好取决于HTML能否被浏览器“分段消化”，核心是DOMContentLoaded越早触发、首屏文本越早可见就越有效；需避免阻塞解析，内联关键CSS、非关键CSS延迟加载、script加defer/async、首屏HTML必须即插即显且含真实文本节点。
渐进式渲染效果好不好，不取决于你写了多少 JS 或用了多 fancy 的框架，而取决于 HTML 是否能被浏览器“分段消化”——它得在加载过程中就逐步产出可读内容，而不是等全部 DOM 解析完才突然闪出整页。核心判断只有一条：DOMContentLoaded 触发越早、首屏文本节点越早可见，渐进式渲染就越真实有效。
怎么让浏览器边解析边渲染，而不是卡住等 CSS/JS？
浏览器默认会在遇到外部 <link rel="stylesheet"> 或阻塞型 <script> 时暂停 HTML 解析，导致首屏内容延迟呈现。这不是 bug，是规范行为，但可以绕过。
- 把所有非关键 CSS 改用
<link rel="preload" as="style" href="non-critical.css">+<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">，避免阻塞解析 -
<script>标签必须带defer（依赖 DOM）或async（独立脚本），绝对不要留裸<script src="..."></script> - 内联关键 CSS（如首屏文字、按钮、导航栏样式），控制在 14KB 内；超出部分延迟加载
- 避免在
<head>末尾放<script>—— 即使加了defer，它仍会推迟DOMContentLoaded，不如挪到<body>底部
为什么首屏 HTML 必须“即插即显”，不能靠 JS 补？
渐进式渲染的前提是：用户在 500ms 内看到真实文本内容（比如文章标题、摘要、导航链接），而不是 loading 动画或空白区块。一旦依赖 JS 渲染首屏，就等于放弃了渐进式能力 —— JS 下载失败、执行慢、被广告拦截，都会导致首屏白屏或结构错乱。
- 服务端渲染（SSR）或静态预渲染（如
prerender-spa-plugin）输出的 HTML，必须包含可访问的正文文本节点，不能只留一个<div id="app"></div> - 动态路由页面（如 /user/:id）若用 CSR 渲染，至少要在 HTML 中 fallback 出骨架占位符（
<h1>Loading…</h1>），并确保该占位符有语义层级（<h1>而非<div class="title">） - 避免用
display: none隐藏首屏内容再 JS 控制显示 —— 这会让渲染树丢弃该节点，失去渐进意义
语义标签怎么影响渐进式渲染节奏？
不是用了 <header> <main> 就自动变快，而是浏览器和辅助技术会基于语义提前建立内容索引，从而优化解析与绘制顺序。错用反而拖慢。
立即学习“前端免费学习笔记（深入）”；
-
<main>必须出现在首屏可视区域前，且不能嵌套在<article>或<section>内 —— 否则部分浏览器会延迟识别主内容区 -
<section>必须自带<h2>–<h6>，否则会被当作普通容器处理，失去“可分段渲染单元”的语义价值 - 用
<picture>+srcset替代单个<img>，让浏览器根据设备特性选择最轻量图片，减少首屏资源阻塞 - 避免用
<div role="main">模拟语义 —— 它不会触发浏览器的渐进式优先级提升逻辑，只是对辅助技术生效
真正难的不是写对标签，而是在 CMS 输出、组件化开发、SSR 框架模板里守住 HTML 的“即时可读性”底线：哪怕 JS 加载失败，用户也该看到标题、段落、链接 —— 这不是降级，是起点。
